Real-time multiplayer online game Research (synchronization and latency)

This article discusses the server and client technologies of real-time multiplayer online games.

Real-time multiplayer online games mainly include two categories: FPS (quake series, ut series, CF series, etc.), Act (DNF, Dragon Valley)

 

The common feature is that user operations need to be reflected as soon as possible. And the results of all clients must be consistent.

The number of players in the same world is small (this is for some reason, as discussed below), and there is a more realistic physical effect simulation.

 

General C/S practices:

A. Client sampling input data-> server processing data-> distribution result.

Other unreliable implementation methods:

B. Client sampling calculation result-> Notification Server (verification)-> distribution result

Or P2P->>>>>>>>> distribute to other clients

 

The input data here is the user's operation, such as opening fire/skill and moving.

 

A. All data is processed on the server. Because the client cannot directly modify the server data, the data is credible (except for bugs)

Because the data is processed on the server, the result will be delayed (transmission time)

B. The approach is unreliable because data processing is performed by the client, because the client hack may have a lot of cheating space (DNF/Rocky full screen second blame or something ). Server-side verification can reduce cheating to some extent.

The advantage is that all results are obtained locally immediately and the client experience is good.

In addition, when the client interacts with each other, there may be a strange synchronization effect due to the delay (running a kart is hit by a shadow ).

 

The following only describes the implementation of.

========================================================== ==============================================

The sampling method is divided into fixed sampling and message sampling.

1. Fixed Sampling uses a certain interval to sample all input states. It is mainly used for FPS games. Generally 20-40Hz.

2. Message Type Sampling: Send changed data only when the input status changes. (Like keydown and keyup) Act games are suitable for this type.

FPS games only support fixed sampling because mouse input is continuous data. If a message is used, moving the mouse once may produce many sampling requests.

In addition, hybrid sampling can be combined for 1, 2, and fixed sampling for the mouse, while message sampling can be used for other keys.

 

To reduce latency, the client can immediately simulate the calculation result after sending out the sample, and then start to make predictions.

After the server receives the sample data, it computes the real and reliable results based on the timestamp and distributes them to each client.

After receiving the result, the client calculates the error between the prediction result and the actual value. If the error exceeds a certain range, the client makes an error correction.

After the client receives the results from other clients, the interpolation shows the status of other clients.

 

 

Latency impact:

Assume that the sampling speed is 1 unit.

If the ping latency From Client A/B to server s is set to 2 units, a-> S = s-> A = 1, B is the same in case of symmetric routing.

Server time: 0 1 2 3 4

S sending: S0 AR1 + br1 AR2 + Br2

Receiving: AS1 + BS1 as2 + bs2

Send a: AS1 as2

Receiving: S0 AR1 + br1

Sent by B: BS1 bs2

Receiving: S0 AR2 + br1

 

The above S0 is the initialization message of the server, AS/BS is the sample package of a/B, and Ar/BR is the result of the sample.

As shown in the preceding table:

For A, his action will be displayed on the server after 1/2 Ping, and he can see that B is the status on the server before 1/2 Ping.

That is to say, if the ping time is 2 seconds, you can see a person. When the target is fired, it is basically not a hit.

(We do not care about the actual location of B, because the actual location of B at this time is the result simulated by client B itself. We only care about the differences between local and server)

 

Tick that reduces the latency impact.

1. Historical snapshots

Cs source retains the latest snapshots of the client. for High-latency players, select the latest snapshot in the History snapshot to determine when shooting.

In the CSS document, the snapshot is retained for less than 0.5 seconds (configurable)

Introduced problems:

Assuming a trench or something else, it is impossible for a role to squat in it.

After a player is down, it may still be hit by a high-ping player (because the history snapshot may still be in the starting status ).

2. Another method is to forecast other clients locally:

Because the action is executed after 1/2 Ping, B is now in the position before 1/2 Ping, if you can accurately calculate the status of B after time = Time + Ping, a. The predicted B should be consistent with the server result.

However, inaccurate prediction results may lead to poor player experience (interpolation prediction results can slightly improve this situation ).

3. Server latency calculation (server simulates client status)

Make T = min (ping for all players)

After the server receives the input, it uses the server status before the input time-T/2 for shooting judgment, generating the next frame, sending and caching.

After a certain period of time, all players are updated to the next frame.

 

For the above table

At time 2, the server calculates the 1-hour shooting detection and generates 3 snapshots.

At time 3, the server calculates 2-hour shooting detection and generates 4 snapshots.

It looks perfect. The only latency lies in the lag of hit effects.

Unlike 1, this algorithm is equivalent to ping all players minus (T/2 + sample rate ). In example 1, the problem basically does not occur (unless everyone has a high Ping, but it can still be said to be completely fair)

 

The problem now is that if a client has a low Ping and others have a high Ping, this algorithm will basically be ineffective.

Fortunately, it is difficult to simulate low Ping with high Ping, but it is easier to simulate high Ping with low ping.

A simple method is to buffer low-ping player Input and Output packets and change them to the effect of Ping> = T. In this way, t can be set to a fixed value, such as 100 ms.

 

Because of the misplacement of the client sampling frames/results, in fact, all lag reduction algorithms cannot completely solve the latency impact, but can only improve the advantages and disadvantages between different Ping players.