A multiplayer game played over the network can be implemented using several different approaches, which can be categorized into two groups:authoritative and non-authoritative.
In the authoritative group, the most common approach is the client-server architecture, where a central entity (the authoritative server) controls the whole game. Every client connected to the server constantly receives data, locally creating a representation of the game state. It's a bit like watching TV.
If a client performs an action, such as moving from one point to another, that information is sent to the server. The server checks whether the information is correct, then updates its game state. After that it propagates the information to all clients, so they can update their game state accordingly.
In the non-authoritative group, there is no central entity and every peer (game) controls its game state. In a peer-to-peer (P2P) approach, a peer sends data to all other peers and receives data from them, assuming that information is reliable and correct (cheating-free):
In this subject, it will present the implementation of a multiplayer game played over the network using a non-authoritative P2P approach. The game is a deathmatch arena where each player controls a ship able to shoot and drop bombs.
This subject focuses on the communication and synchronization of peer states. The game and the networking code are abstracted as much as possible for the sake of simplification.
A non-authoritative multiplayer game has no central entity to control the game state, so every peer must control its own game state, communicating any changes and important actions to the others. As a consequence, the player sees two scenarios simultaneously: his ship moving according to his input and a simulation of all other ships controlled by the opponents:
The player's ship's movement and actions are
guided by local input, so the player's game state is updated almost instantly. For the movement of all the other ships, the player must receive a network message from every opponent informing where their ships are.
Player's ship is controlled locally.
Those messages take time to travel over the network from one computer to another, so when the player receives an information saying an opponent's ship is at (x, y), it's probably not there any more - that's why it's a simulation:
In order to keep the simulation accurate, every
peer is responsible for propagating only the information about its ship, not the others. This means that, if the game has four players -say A, B, C and D - player A is the only one able to inform where ship A is, if it got hit, if it fired a bullet or dropped a bomb, and so on. All other players will receive messages from A informing about his actions and they will react accordingly, so if A's bullet got C's ship, then C will broadcast a message informing it was destroyed.
As a consequence, each player will see all other ships (and their
actions) according to the received messages. In a perfect world,
there would be no network latency, so messages would come and go
instantly and the simulation would be extremely accurate.
As
the
latency
increases, however, the
simulation
becomes
An important step in implementing the game and ensuring that every player will be able to see the same simulation accurately is the identification of relevant actions. Those actions change the current game state, such as moving from one point to another, dropping a bomb, etc.
In our game, the important actions are:
shoot (player's ship fired a bullet or a bomb)
move (player's ship moved)
die (player's ship was destroyed)
Every action must be sent over the network, so it's important to find a balance between the amount of actions and the size of the network messages they will generate. The bigger the message is (that is, the more data it contains), the longer it will take to be transported, because it might need more than one network package.
After the relevant actions are mapped, it's time to make them reproducible without user input. Even though that's a principle of good software engineering, it might not be obvious from a multiplayer game point of view.
Using the shooting action of our game as an example, if it's deeply interconnected with the input logic, it's not possible to re-use that same shooting code in different situations:
When the shooting code is decoupled from the input logic, for instance, it's possible to use the same code to shoot the player's bullets and the opponent's bullets (when such a network message arrives). It avoids code replication and prevents a lot of headache.
The Ship class in our game, for instance, has no multiplayer code; it is completely decoupled. It describes a ship, be it local or not. The class, however, has several methods for manipulating the ship, such as rotate() and a setter for changing its position. As a consequence, the multiplayer code can rotate a ship the same way the user input code does - the difference is that one is based on local input, while the other is based on network messages.
Now that all relevant actions are mapped, it's time to exchange messages among the peers to create the simulation. Before exchanging any data, a communication protocol must be formulated. Regarding a multiplayer game communication, a protocol can be defined as a set of rules that describe how a message is structured, so everyone can send, read, and understand those messages.
The OP_DIE message states that a ship was destroyed. Its x and yproperties contain the ship's location when it was destroyed.
The OP_POSITION message contains the current location of a peer's ship. Its x and y properties contain the ship's coordinates on the screen, while angle is the ship's current rotation angle.
In order to organize the multiplayer code, we create a Multiplayer class. It is responsible for sending and receiving messages, as well as updating the local ships according to the received messages to reflect the current state of the game simulation.
Its initial structure, containing only
For every relevant action mapped previously, a network message must be sent, so all peers will be informed about that action.
The OP_DIE action should be sent when the player is hit by a bullet or a
The OP_POSITION action should be sent every time the player changes its current position. The multiplayer code is injected into the game code to propagate that
Finally, the OP_SHOT action must be sent every time the player fires something. The sent
At this point, each player is able to control and see their ship. Under the hood, the network messages are sent based on relevant actions. The only missing piece is the addition of the opponents, so that each player can see the other ships and interact with them.
When a new message arrives, the handleGetObject() method is invoked with two parameters: the author ID (unique identifier) and the message data. Analyzing the message data, the operation code is extracted and, based on that, all other properties are extracted as well.
Using the extracted data, the multiplayer code reproduces all actions that were received over the network. Taking the OP_SHOT message as an example, these are the steps performed to update the current game state:
Look up the local ship identified by userId.
Update Ship's position and angle according to received data.
Update Ship's direction according to received data.
Invoke the game method responsible for firing projectiles, firing a bullet or a bomb.
If the game exclusively moves entities based on network updates, any lost or delayed message will cause the entity to "teleport" from one point to another. That can be mitigated with local predictions.
Using interpolation, for instance, the entity movement is locally interpolated from one point
to another (both received by network updates). As a result, the entity will smoothly move between those points. Ideally, the latency should not exceed the time an entity takes to be interpolated from one point to another.
Another trick is extrapolation, which locally moves entities based on its current state. It assumes that the entity will not change its current route, so it's safe to make it move according to its current direction and velocity, for instance. If the latency is not too high, the extrapolation accurately reproduces the entity expected movement until a new network update arrives, resulting in a smooth movement pattern.
Making a multiplayer game played over the network is a challenging and exciting task. It requires a different way of seeing things since all relevant actions must be sent and reproduced by all peers. As a consequence, all players see a simulation of what is happening, except for the local ship, which has no network latency.
