Now that we have a working game that allows the presence of multiple players in the same or multiple game rooms, we will iterate and take care of a very important issue in online games, namely, network latency. Given the fact that you will need to think about this problem for many years to come, we will be very focused on the topics covered in this chapter.
In this chapter, we will discuss the following principles and concepts:
- Dealing with network latency in multiplayer games
- Implementing a local game server in the client
- Client-side prediction
- Interpolating real positions to correct bad predictions
Although you may well be one of the happy citizens out there with a gigabit internet connection, you should know that most of the world is certainly not as fortunate. Thus, some of the most important things to keep in mind when developing online multiplayer games are that not all players will have the same network speed and not all players will have high-speed connections.
The main takeaway point that you need to remember from this section is that, as long as there is a network between your players and the game server (or between two players connected directly to each other), there will be latency.
It is true that not all games need near instantaneous response times over the network, for example, turn-based games such as Chess, or our implementation of Snake, since the game tick is much slower than most action games. However, for a real-time, fast-paced game, even a small latency of, say, 50 ms, can make the game very jerky and annoying to play.
Imagine this for a moment. You press the right arrow key on the keyboard. Your game client tells the server that your intent is to move to the right. The server finally gets your message 50 ms later, runs its update cycle, and tells you to place your character at the position (23, 42). Finally, another 50 ms later, your client receives the message from the server, and a whole tenth of a second after you pressed the key on the keyboard, your player begins to move to your desired location.
As mentioned in the previous chapters, the most commonly used solution to the network latency problem is to change the client logic so that it can respond to user input immediately, while updating the server about its input at the same time. The authoritative server then updates its own game state based on the input from each client and finally sends out its version of the current state of the game world to all of the clients. These clients can then update themselves so that they are in sync with the server and the process continues.
Thus, as you may have realized, the goal is not at all to get rid of latency since this is physically impossible, but merely to hide it behind a constantly updating game so that the player has the illusion that the game is being updated by the server in real time.
As long as the player feels that the game is responsive and behaves as the player expects it to, for all practical purposes, you have solved the network latency issue. With every communication with the server (or from the server to the client), ask yourself where the latency is and how you can hide it by keeping the game going while the packets travel across the wire.
So far, we've discussed the client-server structure where the server is the ultimate authority on the game, and clients have little or no authority over the game's logic. In other words, clients simply take in any input from the player and pass it along to the server. Once the server sends out updated positions to the clients, the game state is rendered by the clients.
One other model that is commonly used in online multiplayer games is the lockstep method. In this method, a client tells the server about any input received from the player as often as it can. The server then broadcasts this input to all other clients. The clients in turn use the input state for each participant in the next update cycle, and in theory, everyone ends up with the same game state. Each time the server takes a lockstep (runs physics update from the input data from each client), we call it a turn.
In order for the server to remain as the ultimate authority over the game, an update cycle is also run in the server's simulation, and the output of the simulation is also broadcasted to the clients. If a client's updated state differs from the one sent by the server, the client takes the server's data to be correct and updates itself accordingly.