9
\$\begingroup\$

Are there any resources and documentation on how current MMOs handle the action and movement data from the compression to the handling on the client? Any resources for movement prediction algorithms?

I'm especially interested in those that have wsad movement and focus on keeping latency low Also what is the packet rate and size for different types of MMOs(network wise)?

Is there a way to scale the packet rate or outright disable some packets if the player can't reach or in the later case see them?

\$\endgroup\$

2 Answers 2

9
\$\begingroup\$

Well, there's this book -- which is a bit old now, and I've never really read it, but it's from a reputable publisher. I also found this one, which is newer, but I've never heard of before. Both claim to cover MMO (or at least online) game development issues; that said, client-side prediction is more or less the same regardless of the scale of your concurrent player base, and Google has plenty of information about it.

It's important to realize that from a practical perspective it's rather hard for an indie/hobby developer to put together a game that will be popular enough to even garner enough players to achieve a theoretical peak concurrency high enough to be considered "massive." But the techniques can still be educational to research.

There are two major classifications of things you can do:

  • Be aggressive about sending only the minimal amount of data to the minimal set of clients that need it.
  • Design a game that doesn't give players incentive to clump up too much, helping you keep the "set of clients that need" things small in general.

The second one is really a game design and social manipulation problem -- it's especially tricky because multiplayer games are naturally social, that's part of their appeal, so you don't want to discourage clusters of players too much. On the other hand, a game where everybody in the world is spawn-camping the one guy who drops the best loot in the game is going to be hard to scale.

For the first option you could consider doing tiered messaging -- there are some things about other players that are always important to know, such as positions. But other things, such as health, may not be as important for objects that the current player cannot see yet, so you gate what you send to that player based on the relative distance of all other entities in his vicinity -- this is essentially throttling the data you send, as you mentioned in the last bit of your question, as well as filtering it.

Very large scale multiplayer architectures will also buffer reports that don't need to have immediate action taken on them. Character save messages sent to the server can be done in deltas, with full updates only at critical points, and these updates can be buffered up on a throttling server so that they are send to the server that actually holds the character data in a steady, periodic fashion -- as your player base scales, you have to worry about optimizing disk IO as well as network traffic. You don't want to cause your character database to thrash.

The packet rate and size differs widely from game to game, just as it would for non-MMO games. It's really a very requirements-specific thing and there aren't generalized standards.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ There is also a sequel to the first book (Massively Multiplayer Game Development 2). It's not a terribly useful book series in my opinion (it is definitely not a start-to-finish make-a-MMO-in-x-hours book like most game dev books are), but it does discuss some of the theoretical problems asked in this question. And maybe it'd be more useful to someone who already has a MMO partly developed. \$\endgroup\$
    – Ricket
    Mar 25, 2011 at 16:52
5
\$\begingroup\$

In addition to the above answer, read up on TCP_NODELAY and how window scaling operates. Understanding the details of TCP (and yes, you want to use TCP not UDP unless the prospect of handling differential updates arriving out of order sounds fun to you) and retransmission is critical for latency control.

\$\endgroup\$
12
  • 4
    \$\begingroup\$ I will repeat that if you are using differential updates (usually binary diffs of in-game structures) and you use anything with out-of-order delivery (reliable or not) you will regret it. People that dislike TCP in gaming generally just don't know enough about it (such as knowing what NODELAY does). UDP makes sense for stuff like voice data, where out-of-order packets can simply be dropped, this is rarely the case in a game. \$\endgroup\$
    – coderanger
    Mar 25, 2011 at 17:44
  • 1
    \$\begingroup\$ "rarely the case in a game"? Provided that the server is giving me authoritative game states every frame, I don't care what happened in the past. A simple monotonically-increasing frame number from UDP packets is perfect for this. How much data do you really need to transmit reliably? \$\endgroup\$
    – ChrisE
    Mar 25, 2011 at 19:18
  • 3
    \$\begingroup\$ "Provided that the server is giving me authoritative game states every frame" Sure, if you treat that as a given. Note that I said "if you are using differential updates" which would be the opposite of strobing the full state every frame. In an MMO with any level of complexity to the world it will rapidly become impossible to ship full updates that frequently. \$\endgroup\$
    – coderanger
    Mar 25, 2011 at 19:29
  • 1
    \$\begingroup\$ Even if send the full state of things that change, you end up with issues of out-of-order delivery where merging things together can become infeasible. Think of the updates "x=1,y=2" and then "y=1,z=2". If those arrive backwards you want to drop the "first" one so that the value of y is correct, but then you lose the change to x. \$\endgroup\$
    – coderanger
    Mar 25, 2011 at 20:25
  • 1
    \$\begingroup\$ @Adam Which is why I said you should go read the TCP spec and understand how window scaling works and how it interacts with retransmission ;-) Rewriting TCP is basically always wrong, the chances of screwing it up are near 100%. If you want reliable, in-order delivery you shouldn't be using UDP. \$\endgroup\$
    – coderanger
    Mar 25, 2011 at 21:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .