What's an efficient way to represent game state for networked games?

Question

I've done a little bit of network coding for games before, but primarily with TCP for games that don't really need to simulate real-time interaction. I am working on a (somewhat) simple 2D Java game which I would like to have networked multiplayer. I would rather not use any robust network APIs as I would like this to be a more involved learning process.

In your game networking experience, what is an efficient way to represent the game state which is sent to clients from a server? There is the most obvious but probably least efficient way, which would be to create some sort of game state context object with each player's location, animation state, etc., and send that out to each player every update. That doesn't seem terribly difficult to implement, but would probably be too large to achieve anything close to real-time interaction (of course my experience with this is limited so I may be incorrect).

Is there a solid way any of you have used before to only transmit changes in state, and is there even a large enough disparity in performance that it is worth the extra work?

Answer 1

The synchronization is usually split into two part: incremental and absolute.

Sometimes you must transmit everything, it is large, but if you pack it the right way you can do this once every few seconds. It is good to put everithing in place, correcting the faults of incremental refreshes.

To achieve real-time experience, you must transmit some changes fast, but only the attributes that can change. For example if a rocket flies in a straight line, you needn't to update the position, each client can calculate it from the starting point. But when it hits, you may generate a message about it, so each client can explode the rocket in the right place. Minor glitches can be ignored.

Of course you only update stuff, when they can influence the client! Something far off the screen is not worth it. Some values can be updated less frequently. For example the positions are important to be more or less precise, events (death, shot fired, explosion, etc) must be sent instantly, while not directly important values can have lower refresh periods, for example scoreboard, chat.

The packing of data is also important. You can transmit approximately 1400 bytes (configuration dependent, this is the default) in one UDP package, usually there is a few bytes of header. So you can update 50-100 unit positions in one package easily.

Answer 2

Depending on your game, you might consider a "synchronized execution" model where each client happens to play the same game by simply sharing non-deterministic inputs like keyboard/joystick inputs and timer events. (As compared to a model where each client runs local simulations and expects to integrate results from remote simulations). Your game engine generally needs to be fully deterministic for this to work, which can be a heavy burden depending on the game. But if the game is already deterministic, this may be an easier approach.

This #AltDevBlogADay post covers some aspects of this approach in a modern RTS (specifically how to detect when your clients start running "different" games.)

Remember to keep it simple until proven otherwise, though. :)

Answer 3

Transmitting the full game state regularly is usually not feasible, though it does depend a lot on the complexity of you game. For a simple game with a small world model it may work.

I've personally had much more success with the following model:

• Game state stored in a well defined object model in a spatial data structure (e.g. an octree)
• All changes to game state (whether on the client or the server) are described as events. An event might be a property change on a game object, a change to a map tile, the movement of a game object etc.
• The game engine on the server produces a stream of events as the game proceeds. These are directly applied to the server's game state.
• The events are also sent to players, but only if the event is relevant to that player (e.g. is the event visible from the current position?)
• Changes in player visibility may also result in events to "reveal" new parts of the map etc when the player moves. This can also be used to ensure that the player gets an accurate initial view of the relevant game state when they first join the game.
• The game state for the player is updated with whatever events it receives. As such it only has a partial model of the game state, but it should stay in sync with the server assuming all events are correctly processed

This has provided good performance for me with even quite large game worlds.

Another tip, let the client take care of animation, particle effects etc. without reference to the server. There's no point transmitting these - they just need to be "triggered" by the appropriate game events.