# Is there a pattern for handling multiple game states?

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;
}

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

• For some reason SE reordered the tags - the first tag for this question (that appears in the title) was intended to be "game-state". – immibis Dec 17 '14 at 7:35
• 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. – Ben Dec 17 '14 at 9:35
• As a matter of fact there is, and it's called (try to contain your surprise) the state pattern. sourcemaking.com/design_patterns/state – Timothy Groote Dec 17 '14 at 10:03
• @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? – Fuhrmanator Dec 17 '14 at 13:36
• I think i misread the intention behind the words "game state" – Timothy Groote Dec 17 '14 at 13:48

You could have Mementos implement a Comparable interface.