Multiplayer in fast games (Part III: the appearance of the enemy)

1. Parts I, II (single player with authoritarian server)
2. Part III (The appearance of the enemy)
3. Part IV (Headshot!)

Introduction

In the first article I talked about the authoritarian server and its usefulness for protection against cheats. As a result of the second part, we got a set of techniques that allow the player to control the character on a remote server without lag.

In this article we will consider the consequences of simultaneous connection of several players to one server.
')
From the translator: in this and subsequent articles for gifs, a demo written by me and bogotoff from NerfGame is used.

Server update rate

In the previous article, server behavior was extremely simple — it reads client input; updates the state of the game; sends it back to the client. But when there are many customers, they send teams very often. Updating the game world for each team and then notifying all customers about the changed state would weigh heavily on the processor and the network.

A better approach would be to accumulate all the commands without executing. Instead, the world will be updated periodically with a low frequency, for example 10 times per second. During each update, all the accumulated teams are applied (possibly with a few physics steps so that it is more stable) and the new game state is sent to the clients.
Note Trans. In fast games, you most likely want to set the update rate at least 20 times per second (as in Overwatch) and raise it up to 120 (as in CS: GO).

In short, the game world has its own fixed refresh rate, independent of the presence of teams or their number.

We cope with rare updates

While the player is alone, from his point of view, everything works as smoothly and instantly as before, since the prediction on the client side works regardless of the frequency of server responses.

But he receives too rare updates about what is happening on the server with other players. The naive implementation of other players works like this: the client applies another player's status update as soon as it receives it. Naturally, this leads to jerks, since the frequency of updating the enemy players will be 10 frames per second.






Depending on the type of game being developed, there are various ways to deal with this. And the more predictable the game, the easier it is to get out of this situation.

Extrapolation

Suppose you do a race. The cars are quite predictable - if the car travels 100 m / s, in a second it will be about 100 meters ahead of where it was.

Why "about"? During this second the car could accelerate a little, or slow down; turn a little. The key word here is a bit . Machines are designed so that the position mainly depends on the previous position, speed and direction; and to a lesser extent on user action. In other words, a race car cannot instantly turn 180 degrees.

How does this work with server updates every 100 ms? The client receives the speed and direction of each machine; for the next 100 ms, it will not receive new information, but it must show that the cars are going. The simplest thing that can be assumed is that the direction and acceleration will be constant during this time and locally reproduce the physics of the machine with these parameters taken into account. Later, when the update comes, the position of the machine will be adjusted.

This correction may be large or small depending on a variety of parameters. If the player drove the car directly and did not change the speed, the extrapolated position will ideally coincide with the adjusted one. On the other hand, if a player hits something, the predicted position will be absolutely wrong.

This method is suitable only for objects with large inertia: cars, ships.

Interpolation

There are situations when extrapolation cannot be applied at all. Actually, in all scenarios where the direction and speed of the character change quickly. For example, in a 3d shooter, players usually stop and go around obstacles at high speeds, making extrapolation meaningless, since positions cannot be predicted from outdated information.

In this case, you still can not naively apply updates from the server: players will teleport every 100 ms and for each lost / delayed packet .

You have information about the position of enemies every 100 ms. So the trick is to show the player what happened between these updates in the past .

Let you get positions at t = 1000 . You have already received information about t = 900 , so from t = 1000 to t = 1100 , you show what this player did with t = 900 to t = 1000 . So you show the real movement of the enemies, but 100 ms later.



Note that when using this technique, players see a slightly different state of the world, since the player sees himself in the present tense (this is necessary for the absence of lag when entering), and sees enemies in the past (it would be even without interpolation, due to non-zero ping ). But even in fast games, a delay of 100 ms is usually invisible.



But there are exceptions - if you need high spatial and temporal accuracy, for example, when firing one player into another. Since other players are visible in the past, you aim with a delay of 100 ms + ping, that is, where the enemy was more than 100 ms back! We will deal with this in the next article.

Total

In the client-server model with an authoritarian server, rare updates and delays in communication, you still need to give the player the illusion of continuous movement. In the previous section, we looked at ways to instantly respond to user input using client side prediction and server negotiation .

But other players were still a problem for us. In this article, we looked at two ways to deal with them:

Extrapolation - applies when a position can be predicted from previous information - position, velocity and acceleration.

Interpolation - does not predict the future, but uses only real information provided by the server, showing enemy players from the recent past.

As a result, the player sees himself in the present, and the other players in the past. This usually creates a great gaming experience.

But if nothing else is done, the illusion will break when events require high space-time accuracy, for example, when fired.