Synchronize watches

The game world need to by synchronized so it is the same from the perspective of each player. The peer that owns (or has Authority) of an object in the game need to sync it to all other peers. Three of the main concepts in this is the input, the state and determinism.

    • Input: This is the input from players that try to change the world. It can be from keyboard & mouse, a gamepad or motion control.

    • State: Describe an object such as it's current position, orientation or color.

    • Determinism: Given two worlds with the same initial state and we then feed them the same input do the worlds end up in the same state.


Example: Doom, Age of Empires.

In a Lock-Step system all peers exchange the input or actions they wish to perform with each other. Then they all simulate the world one step forward and then repeat. The game world is like a giant turn based system and for it to work everyone needs to simulate the world to the same state each turn. If not the state of the peers world view will start to differ from each other and sooner or later it will be unplayable.


Low bandwidth

Number of objects does not effect bandwidth


Determinism is hard

Don't scale well for many players.

Hard to support drop in play.


Rewind and replay

Example: Street Fighter III: 3rd Strike Online Edition

This is a lockstep like model where each peer use it's own local input to simulate the world and guess what the other peers input will be. If it guess wrong when a remote peers input arrive it has to rewind the state back to the tick of the failed input and simulate the world forward to the current time again.


Low latency on own actions




Example: Quake, Half-Life.

In this system the simulation is run on the server. Each frame all relevant state is captured in a snapshot and transmitted to each client. Each snapshot created by the server is given a sequence number so it is easy to keep track of them. If the client receive a snapshot older then the one it already have it can be thrown away as it is to old.

The maximum number of snapshots that can be sent is the number of world updates the server do per second. This is known as tickrate in Counter Strike. Common values for tickrate is 20, 30 or 60. Higher values lead to higher bandwidth usage for both the server and the clients. The number of snapshots might be smaller then the tickrate as the server can choose to not send a snapshot to a client each frame. A client can inform a server of how often it prefers to get snapshots so a low bandwidth client can receive less data each second. This is known as updaterate in Counter Strike and the default is 20.

With 20 snapshots per second a new snapshot arrives about every 50 milliseconds. To get a smooth display of the world the rendering time is shifted back. That way we can interpolate between the last received snapshot and the snapshot before that. As our rendering time is progressing towards the last snapshot a new one should hopefully arrive from the server. If we catch up in time to the last snapshot we have to switch over to extrapolation to guess where things should be until the next snapshot arrives. With interpolation we are adding some constant extra latency.

To get the highest possible tickrate each snapshot should be as small as possible. For that we need need to serialize all data to take as little bandwidth as possible.



Lots of work to optimize bandwidth

Bandwidth usage is unpredictable



With State Synchronization the game object is simulated both on the server and the client. Unlike lockstep the client does not wait for the input from the server. If no input has arrived the client updates the object as best it can based on the old input. The server then also sends state updates about the object to the client to make sure it does not get to far out of sync. Guaranteed eventual deliverty of most current state


Possible to select how much bandwidth to use in package


Difficult to get good extrapolation