Online Game matching and synchronization problems

In most real-time online games, the consistency between server time and client time can bring convenience to many other systems. In this case, it is not necessary to adjust the clock in the client's OS, but to adjust the logical time in the game client to be consistent with that in the server.

A rough timing scheme can be like this. The client sends a packet to the server, which records the sending time. After the server receives the packet, it immediately adds a message about the current time of the server to the data packet and returns it to the client. In most cases, the game server does not process this package immediately. Therefore, you can add another time when processing the package. The client can calculate the internal delay of packets on the server.

When the client receives the response packet sent from the server, it can obtain the information of the time when it sent the packet and know the current time, so that it can calculate the round-trip time of the packet. Here, we assume that the round-trip time of the data packet is the same, so that the server's notification time, plus half of the travel time, can be consistent with the server's time.

In this process, udp is better than tcp. Because the tcp protocol may cause large teaching errors due to packet loss and re-transmission, while udp is controlled by itself, this error is much smaller. However, the tcp protocol for online games is much more advantageous than udp, and we do not have to start another protocol for udp.

The general solution can be proofread multiple times. If the clock speed of the two sides is the same, the shorter the travel time of the time packet on the network, the smaller the error. This error will not exceed half of the packet's round-trip time. Once we get a very small trip time in the timing process, and within the range allowed by the time error of our game logic, we do not need to proofread it any more.

You can also proofread multiple times to check whether the network is stable (although the network speed is slow. In this case, the potential time error may be large. Fortunately, we usually carry timestamps on time-sensitive packets. When the time difference between the two parties is very small, the timestamp sent by the client should not be earlier than the real time of the server. (When the time calibration is accurate, the timestamp on the packet received by the server plus the time of a single row of data packets should be equal to the current time of the server)

Once the server finds that the client package has been received "in advance", there is only one explanation: the poor network status at the time of verification has brought a lot of time errors, the current network status is much better than that at that time. At this time, the server should force the client to re-pair. Similarly, when the client finds that the server's data packets arrive "in advance", it can also actively re-pair to the server.

A good time protocol setting can avoid client time cheating (such as accelerators or reducers) in the Protocol. Here we will not discuss or analyze more advanced ways to use game logic to cheat on time. The main purpose of timestamps for data packets is not to prevent time cheating.

The general purpose of time verification is to achieve smoother Combat System and location synchronization. This makes the game look more real-time without relying on the unified time reference standard for network transmission.

First, we will talk about location synchronization.

Good location synchronization must consider the impact of network latency. Therefore, it is not a good solution to simply broadcast the entity coordinates to clients. We should synchronize a motion vector and time information. Whether it is a client or a server, the sent and received information should be the position and motion direction of each entity at a certain time point. In this way, the receiver can estimate the real location of the entity based on the received time. For server processing, the client only needs to send location information to the client at a frequency (generally 10Hz during combat, rather than when the combat status or player does not change the motion status. The server can estimate the position where the player is located based on the recently received package when the network status is poor. The player location information sent by the client should be trusted by the server to correct the previous estimation value. The server only needs to perform spot checks, or hand it over to another module to verify the validity of data packets (to prevent cheating ).

On the server side, each entity can be discrete at a frequency of 10Hz.

Because the client involves display problems, players want to see the continuous motion of entity, which makes it a little more difficult to handle. The location synchronization information sent by the server may also be received late due to network delay. The client also makes an estimation based on the recently received package, but when the estimation result of the received package is different from the previous information, it should make a correction of the moving direction and speed, make the next estimation as accurate as possible.

With regard to Combat Command synchronization, I hope to add cool-down time and boot time to all combat commands, which is exactly the design of wow. In this way, trust the client's timestamp to obtain the client's accurate command release time. The boot time (or public cool-down time) can be used as a buffer for network latency. Of course, our current design will be more complex and will not be listed here. For distance-sensitive skills, such as remote attacks and range magic, we designed a fuzzy miss judgment formula to solve the problem of distance boundary determination.

Here, when the server estimates the location of the attack target, it may not estimate the location based on the movement direction of the last packet, but choose to use the direction that is most beneficial to the attacker. This reduces the disadvantage of gamers with poor network conditions.

For PVE battles, you can even make more choices to achieve smooth gameplay. For example, when a player with poor network status attacks the npc, the npc is within the attack range. However, the npc has left when the server receives the packet due to network latency. In this case, the server can use the client logic to pull the npc to the original coordinates.

However, this may lead to different performance on the client of other players (onlookers. However, in many cases, online games do not require strict synchronization. The player feel is more important without affecting the main game logic.