I've done a little game network coding before, but primarily with TCP for games without real-time needs. I am working on a 2D Java game with networked multiplayer. For learning, I want to do this myself, without an existing network API.

How do I efficiently represent the game state 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?

  • 2
    \$\begingroup\$ Try out the full state every frame thing and if it's too slow (for a somewhat simple 2d game, it's probably efficient enough) then try optimizing. If it works fine, then it works fine and you don't have to change it unless you notice your networking being a bottleneck later. \$\endgroup\$ Commented May 9, 2012 at 7:29

3 Answers 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.


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.

  • \$\begingroup\$ Thanks for the advice Matzi. I'm still working on implementing the server and client, but I'll check back in a couple of days and probably accept your answer. \$\endgroup\$
    – Haz
    Commented May 10, 2012 at 2:21
  • \$\begingroup\$ Good luck to you! ;) \$\endgroup\$
    – Matzi
    Commented May 21, 2012 at 18:17

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. :)


You must log in to answer this question.

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