In a typical multiplayer game, each player runs a copy of the application on his own device (PC, Console, mobile phone etc.)
Naturally, there is a need to synchronize the state of the game among all these players' devices.
There are 2 models followed:
- server authoritative state
- client authoritative state
The main difference between the 1st and 2nd case is where the initial state is stored.
In the 1st case, the game state is completely maintained on some server and each client fetches the initial state from the server when it joins into the game.
Each client then updates only its own state by sending the corresponding update messages to the server. The server manages the game state and pushes these updates back to all the connected client applications.
In the 2nd case, the client side state is taken as authoritative overriding the state on the server. So, if one of the clients crashes and re-initializes the state, there is no way to recover the original state of the player.
Moreover, the communication between individual client applications needs to be based on peer-to-peer system adding substantial burden on network processing.
We have now established the importance of communication/messaging in a multiplayer game.
The message delivery can happen in 2 ways:
- pull - where the client application pulls the messages from the server at periodic intervals
- push - where the server pushes the messages to the target client application as and when they arrive.
To implement the pull system, the server needs to maintain the queue of messages for each player. As the no. of players grows, the no. of queues also grows.
In contrast, to implement the push system, the client needs to have a persistent open connection to the server and the server needs to be able to identify this connection given the client identity.
Mobile OS vendors (Apple, Google, Microsoft, Amazon) have their own push services. However, there are limitations on how much data can be carried in the payload of these messages.
Playblazer platform provides both the push and pull channels for the notification messages. It uses the push services from respective mobile OS vendors as well as maintains per-user queues for pull configuration.
Given the limitation on size of payload of push messages (for example, Apple allows only 256 bytes of payload), it may not be possible to carry the full context in the message payload.
This is the reason why we also maintain the pull-based system where each individual message can carry sufficient contextual data in the payload of the message (depending on the type of the message).