One of the most common use-cases for Server Authoritative Gameplay is that of Multiplayer Games. As opposed to single player gameplay, multi-player games need a server-side application to keep track of the state of the game while multiple players effect changes to the game state. The other player's actions depend on the accurate representation of the current state of the game.
Traditionally Game Servers have implemented a couple of different models to achieve this - the most common being bundling of Client & Server capabilities into the client game and then making one of the clients act as the server. In this kind of implementation the server only keeps track of current users & their network addresses while providing basic matchmaking services.
However this creates a number of challenges:
-
a significant advantage for the host player (server role client) besides also opening up the game to client-side exploits & hacks.
-
network addressing issues (can be played on the same network, difficult to traverse NAT/PAT)
This evolved into a model where there is a dedicated server hosting the game and all the clients connect to that server. All the activities of the players get reported to the server synchronously and continuously in the form of small messages and the server broadcasts these messages to all the connected clients.
This model has its own set of challenges:
- limited no. of connections possible to the server - the connections to the clients need to be kept open on the server which consumes resources and hence, each server can host only fixed no. of connections.
- flooding of messages - the server needs to broadcast the messages to all the connected clients in the current session causing a flood of messages on the network.
- latency
The ideal situation is when the Server is the Authoritative source of the game state and clients merely fetch & update state as they play. This is where 3rd Party Platforms usually fail on 2 counts - firstly, because they are unable to handle the scale of modern mobile games (think a million+ DAU) or that they are simply not equipped to provide the complex state management service required for such games.
However lets start out by evaluating the key components of a good server-side multi-player platform.
The Player/s: Obviously this is the start point, the game state is a representation of the original state + atomic changes caused by the activities of each player. The Player/s & their Profile/Attributes/Characters/Inventory/History/../..etc are critical to building a multi-player platform.
The Session/s: Each game has a well defined core-loop that defines the rules for play as well as the actual logic for progression, number of players, the player activities, etc. We can call this the Session Object, which is closely aligned with the core-loop of a game.
The scoring: It's important to track the progress of each user. Each session that the player plays may end up giving some points to the player based on the outcome. These points need to be stored somewhere - the scoring system. Also the accounting of wins/losses (determined either by the client app or the server side logic) is typically done in the scoring system.
The communication/messaging: The players need to be informed of the events in the game - the actions of other players, the resulting change in the state at the server end, other platform level events. Having an underlying communication system is vital for this communication.