When dealing with state, synchronization between multiple simulations may become important. For example, with a client-server model network game, or when distributing the simulation processing.
There are two approaches to state synchronization within this model, which ultimately are two sides of the same coin.
Event based state management
We maintain state by sending the same events to every simulation. If events are dropped or lost, or not applied in time, the simulation may become incorrect
- An event signals some sort of state change to the world.
- Applying a single event may change multiple parts of the simulation.
- Events can minimize network traffic as much data can be evaluated on the client.
- Events sent to clients can be filtered programmatically based on proximity or relevance, thus reducing bandwidth even more.
- An example of an event is an encapsulated transmission of the
IWorldEvents
object. This contains a discrete event that changes the state of the world and is applied at a given timestamp.
Event based systems are generally easier to implement but maintaining a consistent simulation across multiple discrete processes can be difficult
Synchronization based state management
We maintain state by keeping track of individual state values, and noting when they change. These changes are then serialised and sent out across the wire. In effect this is a structured event based state management, but with the effect that events may be coalesced or discarded if they are not important.
- Synchronize state between client and server by monitoring changes to key variables.
- Server maintains world state: sets of objects, relationships and state.
- Client needs to know a portion of the world state: subsets of objects, relationships and state.
- State is updated with one of four events: update primitive, update relationship, instantiate object, destroy object.
State synchronization is better for systems where precise step-by-step simulation is not so important, but rather that the final world state needs to be correct regardless of simulation behavior. They are typically used for turn-based games and user-interfaces.