Online Game sync

Http://blog.csdn.net/yxriyin/article/details/23377271

Recently I have read a lot of network synchronization problems because I have only made the conversion and not done the arpg, so let's take a look at how it is implemented. There are basically two problems: Player location synchronization and Combat Command synchronization. Player location synchronization is easier than combat command synchronization, but because of this, you will adopt a complex synchronization strategy for better synchronization. In addition, these two types of synchronization are closely related, and the battle will certainly involve location judgment. So I plan to think about these two issues together.

First, we need to know that the time protocol is required in arpg games, that is, the timestamps of the client and server must be basically consistent. As for the frequency and strategy of this pair, there can be various optimized versions. We only consider the simplest case, that is, the timestamp is synchronized at intervals. Generally, it may be 5Hz or 10Hz. Of course, it will definitely be higher during the battle, but it can be reduced at ordinary times.

Why do we need a timestamp? Whether it is location synchronization or preventing players from using accelerators, including client cheating, it will be much simpler when there is a timestamp.

First, the time protocol can be used to let the client and server know the approximate time of network latency. Although it is rough, it is also relatively accurate.

To better illustrate the problem, we assume that player A has a network latency of 1 s, Player B, and a network latency of 2 s. This is a very large latency, because if it is about ms of latency, you don't have to take any technology, you can run well.

Player A was originally located at Coordinate 5 and issued a command to move to coordinate 10. the player's speed is 1. When the server receives the command, the player has actually reached Coordinate 6 in theory, here, we cannot let player a wait for the server to respond and move again, because no one can afford to move it for 1 s. The server knows that the network latency is 1 s, so it is easy to estimate the location of 6 and notify B of the location of a. B obtains the coordinates of a. In fact, a should have reached 8, of course, B also knows the network latency, so it can also be estimated that the location of a should be 8. Everything seems okay, but it is not difficult to find some problems. First, the network latency is unstable, and its validity needs to be checked based on Timestamp calculation. For example, if the latency is as high as 10 s, and the estimation result is almost instantaneous for players, we can determine that the latency of 10 s is not reasonable, or even discard this package. It is assumed that two seconds of delay will enter the estimation, and more than two seconds, I am afraid it will be treated as two seconds. What if players cheat? Send a variety of strange positions, which also requires detection. The server must have the player's original position. Through comparison with the player's new position, check whether the time difference between the two is possible. If it is not possible, it indicates that there is suspicion of cheating. If it is found multiple times, it will be directly kicked off and handled. This seems to solve this problem. But think again, after Player A gives this command, B synchronizes A to 8. Suddenly the second command of a comes. After a reaches 5.5, it actually runs back. Likewise, when the server receives the information, it finds that the location of a is 5.5, which is 0.5 different from the originally predicted Location 6. It indicates that the prediction has an error. We still believe that the client is used, if you forcibly synchronize position a to position 6, Player A will have a strange experience of going back. At this time, the server estimates that A is at 4.5. of course, a may suddenly stop. We don't want to consider this problem because we only need to add a stopped command or determine the target location to solve it. At this time, the server notifies B, A to 4.5, and B receives the information. It is estimated that a should be at 2.5, and the problem is found. Why should a suddenly go to 2.5 at 8? Of course, because it takes only 0.5 seconds in the middle, a seems to be less than 8 in B, but it is only 7 on the way to 8. If we do not have any estimation, the situation will be changed to a at 6, the server considers it to be 5, and B A is told to be at 5, with a delay of 1. If a goes back to 5.5, in fact, if A is in 4.5, the server regards it as 5, and B receives it as 5, which does not seem so bad. The crux of the problem is that if no estimation is made, there is no doubt that the server receives the data before the client latency, and the client learns that the positions of other players are the superposition of the latency on both sides. This is by no means a good strategy. Then we can also see the estimated risks, which may lead to false positives but increase the error. We found that the error increased because the player suddenly turned back, leading to the opposite speed after a bunch of delays, but the error increased. However, these may not be the problem. Here I copy a big piece of cloud wind:

 

One is that the received information belongs to other players. We predict the status after a period of time (such as the status after one second) from the latest status information, and use a straight line motion to correct it. That is, imagine where the player is after one second, and then reverse push back to the current speed at which the movement can reach that place after one second.

On the other hand, the received information belongs to itself, that is, the server recognizes its own status (and broadcasts it to others ). This deviation is caused by the server's predictive compensation. In order to maintain the user's operation experience, we do not modify the non-extreme deviation, but still send the client's own operation location status to the server. Players on the server side are in a discrete motion. When others see you, they will make predictions and make compensation again. If the difference is too sharp with the server, they will jump directly to the new location recognized by the server.

Almost all of the operations on the client are believed here to get the best operation experience. Preventing client cheating is another topic that cannot be solved, but do not touch it now.

What frequency does the client send location information to the server?

The policy should be as follows:

After a complete location information is sent each time, the prediction server determines where the location information package is located after one second. Each change is accumulated, but it does not need to be sent immediately within one second. However, each small state change is compared with the predicted location. If the location deviation is large, it can be sent in advance. Otherwise, the message will be sent after one second.

The cycle of this second can be adjusted according to the actual test conditions. A second may be too short or too long.

Each time a new gamer location information sent from the server is received, a timestamp will be found in it, indicating the time when the packets are sent from the server. The client can check whether the previous network latency is correct. If the network latency is stable at a fixed value, it indicates no problem. However, if the delay value is negative, it indicates that the network in the current process is unstable (probably because of the large deviation of the upstream and downstream time, or because the server load was large at that time, it causes a large internal delay), causing a time difference calculation error between the local time and the server time. In this case, the process is fine when you re-initiate the peer interface.

The above is the content in the Yunfeng blog. We can see that for Player B, Player A is no longer within the error range and should be directly converted to 2.5 or 4.5, in this case, we just analyzed that B is about 7, and it seems acceptable if it is changed from 7 to 4.5. After all, we changed from 5 to 8. everything is not that bad. Of course, if you want to change it to 2.5, you can only use instant migration. Otherwise, players will always exercise at a faster speed than ordinary people. Therefore, I personally prefer to keep an estimate. Don't say it's too full. I 'd rather delay some places than overhead it.

 

Based on the above conclusions, we can see that if a player is just running, it will undoubtedly feel smooth, because if everyone does not wait, they will see that they are starting to move. Everything seems perfect. However, if it is a battle, let alone PVP, we will have PVE ready. Players will attack monsters. If there is a network delay, we have to wait, this is because it cannot be computed on the client side (of course there are games doing this, and I will write another blog to discuss it ). We can't trust the client, so it seems very painful for players to delay the attack for one second. Then let's look at the monsters. Do gamers initiate attacks on the client or the server? First, we need to synchronize the locations of monsters, because the AI of monsters must be handled directly by the client. If it is initiated by the client, it also has latency issues, but it doesn't matter because it is a monster. However, when we say that the movement is instantaneous, the players will attack and then directly run away. However, they will find that the attack will only respond after one second, and they will clearly go, but suddenly attacked the other party. Here is a technology called client prediction. When you attack a monster, the client executes the code according to the server, so you do see that you have cut down without delay. Of course, the server will also calculate it, but it will be one second later, at this time, you have received the server-side computing results. If the results are the same as those calculated by the client, congratulations. You can do nothing, and the players will end the battle smoothly. But what if the calculation on the server and the client are inconsistent? Yes, because of the existence of the probability of brute-force attacks and dodge probability, it is very likely that your client hits the server but does not. When you find that the status is inconsistent, you will directly synchronize the status. So the question is, what is the significance of my client prediction? Just to play those attacks, and then find that the monster slowly responds after 1 s, and I am still silently attacking. The author of the Unreal Engine said: With the buffer technology, the client storage status and commands, when the server status is sent, it is not a pure synchronization, but an invalid instruction in the buffer is removed first, for example, commands that are outdated. Then insert the status sent from the server to the first one, and use the commands in the Operation cache to continue the prediction and get the latest status for synchronization. But you immediately realized, isn't it a constant repetition of commands? Yes, you will find that you have killed a strange person. Suddenly, this strange person is active and killed again by you. To avoid this problem, we need to ensure that each command is only executed once. That is to say, each prediction synchronization only executes once and then updates the result. If these commands have been executed, so you don't have to execute it. Simply synchronize the results. Of course, there will still be a problem of sudden blood loss of monsters. The biggest problem with this technology is that your client must also have the corresponding logic code of the server. Only a masterpiece can be so domineering. Therefore, we do not plan to adopt this technology.

 

So we can only honestly accept the pitfalls brought about by this delay? There are still some tips. For example, if you shake the image before the attack, you need to shake it first. This Shake may not work, but it does provide a short period of time to wait for the server to return results. This is of course not a technology, but we have to face the fact that poor network experience will definitely get worse, and it cannot beat good players on the Internet. For example, in PVP, players with no latency almost hit you by sending a command. You have no way at all. Be honest and wait. When you attack someone else, you think it's a hit, but when you get to the server, you find that people are too far away. Therefore, if it is PVE, it can still make some compensation for players with poor network performance. After all, it can be used as a hit.

 

This is basically the case and may be messy. For details about other materials, refer to a blog reposted by me. What about network synchronization? How many articles can be written in English.

Online Game sync