I'm experimenting with writing a multiplayer game, almost from scratch (I'm using C++, OpenGL, ENet, and platform-specific APIs) with a client/server networking model where the server is authoritative.

The server and clients each run their own deterministic simulation of the game. The server sends periodic snapshots of the entire game state to clients. When a client receives the snapshot, it forgets everything it knows about the game (except for the player's input after the snapshot was taken), loads the snapshot, and replays the player input that was generated after the snapshot was taken.

Now, say I want to send deltas instead of full snapshots. The server needs to remember the previous snapshot it sent, so that it can compare the current snapshot against the previous snapshot. Clients also need to remember the previous snapshot to reverse the delta. Each snapshot is a copy of the complete game state, and the server and clients now need to handle at least two of them (the previous snapshot, and the current game state).

A game state conceptually follows this pseudo-code:

class GameState {
    vector<unique_ptr<GameObject>> objects;
    vector<unique_ptr<Player>> players;
    TerrainTile terrain[TERRAIN_WIDTH][TERRAIN_HEIGHT];

abstract class GameObject {
    vec3 position;
    vec3 velocity;
    abstract void doPhysicsTick();
    abstract void render();

class Player {
    GameObject controlledObject;
    string username;

class HumanCharacter extends GameObject {
    void doPhysicsTick() {...}
    void render() {...}

... etc ...

Is there a pattern to store multiple independent copies of the game state from different times, so that they can be easily compared?

What if I wanted the server to run an identical simulation to each client (delayed by network latency)? The server would then need to manage at least N+1 game states, where N is the number of clients - and they would be active simulations, rather than static copies. (One practical use for such a system might be to only send values that the client has predicted incorrectly, rather than all values that have changed).

  • \$\begingroup\$ For some reason SE reordered the tags - the first tag for this question (that appears in the title) was intended to be "game-state". \$\endgroup\$
    – user253751
    Dec 17, 2014 at 7:35
  • \$\begingroup\$ You do NOT want to send the entire stat of the game every time. Why not keep everyone in sync and just update clients when important events happen? It may seem to work in theory, but there is huge problems with this, such as "lag" which is generated from the fact that the clients are basically terminals listening to the server. \$\endgroup\$
    – Ben
    Dec 17, 2014 at 9:35
  • 2
    \$\begingroup\$ As a matter of fact there is, and it's called (try to contain your surprise) the state pattern. sourcemaking.com/design_patterns/state \$\endgroup\$ Dec 17, 2014 at 10:03
  • 3
    \$\begingroup\$ @TimothyGroote State pattern would be bad if there are a lot of states. Just because the word "state" appears in the problem doesn't mean you'd use the State pattern. As a matter of fact, there is one subclass for each state. Is that what you'd want in a game that can have hundreds of different states? \$\endgroup\$ Dec 17, 2014 at 13:36
  • 1
    \$\begingroup\$ I think i misread the intention behind the words "game state" \$\endgroup\$ Dec 17, 2014 at 13:48

1 Answer 1


As https://gamedev.stackexchange.com/users/30331/ben points out in his comment, this may not be the best way, especially if your state info is big.


Is there a pattern to store multiple independent copies of the game state from different times, so that they can be easily compared?

Have a look at the Memento pattern.

You could have Mementos implement a Comparable interface.


You must log in to answer this question.

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