So, there's a couple of things going on right now with me that are suggesting to me that I should make a MMOG: 1. My development team and me are finishing up our first large game project (check it out at http://gcsociety.sp.cs.cmu.edu/~arbarlith/ :)) 2. When the Arbarlith project is completed, the team will mostly dissolve. But a few of us are planning to make a new game in the Spring. I won't be heading that team, but they want me to code the game engine. 3. My friends down the hall from my dorm have have decided to write the design document for the "Best MMORPG evar!!" because they know how to "do it right." I expect they'll fail, but they also want me to code the game engine. 4. I'm building a cluster of old Pentium 2 computers running under Gentoo with the the OpenMosix kernel. Its connected to the internet by a *very* fat pipe. But I have no programs worthy of its power. I went through Beej's networking tutorials a few months ago and I am fairly proficient at basic socket communications. What's the next step? I really don't know. But I'm enthusiastic, have realistic expectations, and feel that I pretty much have covered the prerequisites. Any thoughts? As for the actual MMO part, I'm thinking of having the server pass messages to the client that instruct the client to create or destroy objects. The server also sends messages updating the position, velocity, animation, etc of the models every so often. The client renders these models and also sends raw input to the server. But I don't really know how to do this or if this is a decent way to do it at all. The game specific stuff will be on the server only, so come to think of it, with this setup, I can use the same client for both games... -Andrew

Before you go down that path, ask yourself: where is the content coming from? You may be able to buy a few meshes for player characters on the internet, but you will have to get artists to create the full set you'll ultimately need. You'll need tons of different monster types, and levels, and quests, and weapons, and magic, and ...

If you just want to make games, stay away from MMO, because it's just a pit of despair for all but the most talented, most hard-working teams (teams which must include good artists). Much game-making fun can be had elsewhere, with less pain.

If you absolutely want to make an MMO, whatever the cost, first look at joining an existing project (such as PlaneShift), or at least start out using some existing middleware (such as RealmCrafter) to see whether it's REALLY what you want to do. If and when, by some feat of unimaginable effort, you manage to make something that's worth keeping online, then you can go back and re-implement the game technology for real, and re-use all the art -- that'll be MUCH easier than doing it all from scratch in the beginning.

Oh, and I assume you read question 0 in the Forum FAQ :-)

Originally, there were two groups of people who asked me to code their game engines. The first group is made up of artists I have worked with in the past. I talked with them about their game at some length and it looks like they really just want some kind of multiplayer with larger numbers of players.

The other group was made up of a few artist friends of mine. Their idea is for a full-fledged MMOG, but they are very unrealistic. If I do any for them, it will be to write the basic game engine and let them continue on their own. But I'm not even sure that I want to get tangled in that mess.

So, I have narrowed down my requirements:

* The game will be online only
* Clients can only play if they connect to our server.
* The game will be persistent
* The server should expect to support between 16 and 100 players. Personally, I expect it might be closer to 16, maybe :)
* The game engine should include enough tools and documentation so that other people can deal with the nasty details of making content for it.

MMO is a bit of a misstatement, it implies a ceratain amount of service that I can tell you right up front I have no intention of supplying. It also implies a certain level of content in the game, but that's not my concern.

However, I really don't know what goes into writing network code. I can send packets of data, but I don't know what to do with them. Can anyone point me in the direction of some resources for writing a networked game? Not merely connecting sockets, but how a game can be written at the higher level to allow networked play.

Thanks.

There are some pointers in the Forum FAQ. The Quake, Counter-strike, Torque and Unreal papers could actually work fine for a game with up to 100 players, if you drop down the send rate a bit (e g, send 3 packets a second, instead of 20 :-) which would be quite allright for an RPG-style game.

For getting the networking up sooner rather than later, I suggest using a pre-made networking packet; a lot of people are using raknet, but there are others -- also listed in the Forum FAQ.

The basic client loop for this kind of game consists of:

forever:  read user input  update simulation control from user input  if enough time passed since last send    send copy of user position and simulation control  read network inputs  foreach entity with networking input this step:    update network entity simulation controls based on network inputs  evolve simulation  render simulation results

The basic server loop looks something like:

forever:  read networking input  check whether received packet is credible  if not credible    send correction based on current state to user  else    update user state based on packet  foreach player    if time since last packet sent is enough      foreach other player        if within visible range          if not visible for this player            send initial entity visible packet          else            send state update          mark as visible for this player        else if visible for this player          send "make invisible" packet

Note that when I say "simulation" and "physics" I really mean all the rules that you have for what happens in the world -- from walking, to magic, to fighting.

There are many variables in how you actually implement this. The specific timing and algorithms used to determine when to send (and what is visible) come to mind. The validation of "credible" user data may vary wildly. The method by which you simulate remote entities may vary. You may want to update the simulation on the server as well as the clients, to have a slightly fresher snapshot of the world each time you send an update (at the expense of more server load). You may want to actually send all control input to everyone, so they can run all the simulations exactly in sync. Etc, etc.

We're slowly building up a development team to work on a multiplayer game.

In our case, we have been playing/adminning/studying the internals of Ultima Online (both client and server). What I found most helpful when designing the network layer for our own game, was reading and understanding UO client <-> server packet communication.

It might be helpful in your cause to find a similar game that is somewhat old/has a good "hobbyist developer" userbase, and find out what systems they use.

For the most part, I found a "mother may I" system to be the most useful when designing our own network layer. In simplest terms which are generally useful for many situations, the client makes a request, and the server responds with either a negative "denied" packet, or a followup packet instructing the client what to do. E.g. if a player wishes to move his character one unit in a given direction:

1. client sends request "move <direction>" packet to server
2. server checks the game map, verifies the destination is not blocked, empty, or otherwise inaccessible
3. if blocked, send to client "movement denied" packet
4. if unblocked, send to client "move client to X,Y location" packet

As for the network-layer software itself, we're using RakNet. We decided upon this due to the features it has which we require (streaming, packet encryption, tcp overhead avoidance, simple/fast integration, availability on multiple platforms, completely free distribution). You might want to take a look at it if you haven't heard of it. http://www.rakkarsoft.com/

Best of luck!
- m³

I think a better model is to check locally whether it looks OK to do the action, and then go ahead and start the action, and send it to the server. The server then validates the action, and if it's not actually allowed, sends back a "denied; here's where you should be" packet. This way, you don't have to wait for an actual request to the server for each action -- round trips add latency! As long as you're in sync with the world, and not cheating, your request will always be allowed, because you pre-verified it.