[Reprinted] synchronization of online games

[Cnblogs transferred from margincc. If any infringement is involved, please contact us immediately. Once confirmed, the domain name will be deleted immediately ~ However, for the purpose of study, I am the only one of the six people in the group that can beat soy sauce. I would like to ask you to raise your hand!]

I recently completed a game that involves a little network synchronization, and made a summary based on some information I found on the network and my own experiences.

Game Description: The figure is summarized as five players in the map send messages at 5 different locations. The map contains 20 items. The player selects the departure time, the starting angle and the starting speed go to a certain item. Now Player 1 sends a message to the server, preparing to start from the current currposition. The corresponding currtime, currangle, and currspeed are all determined. Assuming there is prop1 in front, the server now receives the message currservertime, then broadcast player 1's departure, then player 2, player 3, player 4, and Player 5 may receive messages for network reasons at time2, time3, time4, and time5. If the drawing starts when player 1 sends a message, and the drawing is triggered when the player receives the message from players 2, 3, 4, 5, there is an out-of-sync problem. Player 1 and player 2, 3, 4, 5 correspond to a time2, 3, 4, 5-currtime time error. In addition, there may be 5 players with different local time.

First, you can solve the problem by sending a group verification via the server: when player 1 sends a message, it does not draw, but waits until the server receives the message from player 1 and broadcasts it to five players before drawing together. Considering the different local time and network latency of five players, we can compare the difference between the local time and server time of a player before the player starts the game, on the server and five clients, record the time error motifytime1, 2, 3, 4, and 5 for each player and server. When the server receives the departure message, it determines the drawing time for each player to receive the departure message from player 1 based on motifytime1, 2, 3, 4, 5. Players with high network latency will feel extremely bad about this solution. Many games that do not require timely communication use this method.

If player 1 draws when a message is sent, it can also be synchronized in the motifytime mode. When the server receives the message of player 1, it calculates the start time of player 1 on the server through motifytime1, after the broadcast, players 2, 3, 4, 5 determine whether the time when the message is received and the time when the server sends the message is within the range of motifytime2, 3, 4, and 5, if the range is exceeded, the excess time is calculated. * After speed, the actual position positon1 can be obtained. Of course, we can use a slightly faster speed to reach the position next to position1.

There is also a mainstream solution that I have not copied network materials:

First, the client needs to create many broadcast lists when logging on to the world. These lists are not synchronized in a timely manner on the backend of the client and the server. The reason for this is to create multiple lists, it is because there are more than one broadcast type, such as local message, remote message, and global message, these lists must be created based on the messages sent from the server during client login. When creating a list, you also need to obtain the TimeModified of the broadcast object in each list, and maintain a complete user status list in the background, which is not synchronized with the server in a timely manner, according to the local user status table, some decisions can be decided by the client itself. When the client sends this decision, the final decision is directly sent to the client in each broadcast list, and the time is proofread to ensure that each client proofreads the received message based on the local time. Then, the method that uses the advance computing volume mentioned in the prediction pull to increase the speed of walking will make the synchronization very smooth. The advantage of this solution is that the synchronization between clients is not implemented through the server, which greatly reduces the errors caused by network latency, and most decisions can be made by the client, it also greatly reduces server resources. The drawback is that because both the message and decision-making power are placed on the client, the plug-in provides a great opportunity.
Navigation based on this solutionDead ReckoningAlgorithm:

As we all know, latency is common during network transmission, and synchronization of online games based on the Server/Client structure becomes a headache, when the client responds to the user's local commands smoothly, the synchronization timeliness cannot be effectively guaranteed. First, this synchronization scheme is based on the synchronization between clients. The following are some concepts of nouns that will be used in this article:
Mesh network: a network composed of clients
Node: each client in the mesh network
Limit Error: The extreme value of the error that may occur during synchronization
Well, before discussing its principles, let's take a look at the environment we need. First, we need a mesh network. How do we create a mesh network? When a new node enters, it notifies all nodes in the network that each node creates a local copy for the client and logs out, all nodes are notified to destroy local copies of the node. What data should each node save? First, a very important package needs to be saved, which is called the Protocol Data packet (PDU Protocol Data Unit). The PDU contains some motion information about the node, such as the current position, speed, and direction of motion, or there are some information such as acceleration. In addition to PDUs, other information needs to be saved, such as HP and MP of node client characters. Then, ensure that each node broadcasts the PDU information to other nodes within 8 seconds. Finally, set a limit error value. At this point, the environment is complete. Next, let's look at the specific algorithms:
Assume that there is A villain (passer-by) in node A and the road begins to run. At this time, it is like all the nodes broadcast their PDU information once, including: Speed (S ), direction (O), acceleration (). Then all the nodes start to simulate the motion tracks and routes of passer-by A, including node A itself (which is very important). At the same time, passer-by A is under the control of A certain player, it will change its direction from time to make its route not so formal. During the running process, node A records the difference between its real coordinates and the coordinates of the simulated motion on the background without stopping. When the difference is greater than the limit error, calculate the current speed S, direction O, and speed A (the algorithm will be introduced later) and broadcast it to all other nodes in the network. After receiving this message, other nodes can use some smooth moves to pull the passer-by, and then re-adjust the simulated data so that they can continue to simulate the running on the background.
Obviously, if the limit error is defined as large, the deviation seen by other nodes will be too large. If the limit deviation is defined as small, the network bandwidth will increase. If this limit error is defined, it should be designed based on the importance of various data. If it is a turn-based online game, it doesn't matter if the limit error is defined to be greater on the walking side, and the bandwidth can be reduced. However, if it is an online game that fights in time, you have to define the limit error a little. Otherwise, someone may see someone cutting themselves down.

 

Synchronization is a very important issue for online games. How to synchronize is also related to various aspects, such as the game scale, game type, and various aspects. For games with large scales, in terms of synchronization, we can make a lot of effort to differentiate messages very delicate. Different synchronization mechanisms are used for different messages, while for games with relatively small sizes, you can adopt the same synchronization mechanism in general. There is no definite pattern for how to synchronize, so you need to make different synchronization decisions based on your own situations.

The author completed a casual game, using the second method to complete the prediction pull mode, the player operation using the first drawing, other players receive the message after the prediction pull. At the same time, the server also creates a map resource and player operation scenario. Similar to the scenario where the server and client are updated at the same location under a map, the server will regularly refine the player coordinates, it is determined by the server to process messages such as key items.

 

Finally, I copied a summary of the online prawns:

 

The following six points will help you identify what we can work on and what we are not worth doing. It will help you understand the key to the synchronization problem in real-time games, and cleverly resolve and circumvent the game, finally, in a network environment suitable for common users (200 ms), real-time and fast interactive games are achieved:

1. Basic information:
(A) network performance indicator 1: bandwidth, limits the number of real-time games
(B) network performance indicator 2: latency determines the minimum response time of real-time games

2. Two basic principles:
(A) there is no problem in making all the user screens show completely different appearances.
(B) it is no problem to soften these completely different appearances in a unified logic.

3. The twelve basic strategies for synchronization:
(A) data transmission in the game is minimized
(B) put blocking communication in the thread pool for implementation
(C) never let the game go without waiting for data
(D) use prediction and interpolation to improve game performance
(E) when using predictive interpolation, the transmitted data not only includes coordinates, but also requires speed and acceleration.
(F) bind or queue the input data (such as the keyboard message queue) until the next time the data is sent, the traditional method is to detect the keyboard at a fixed time (before sending the data, hiding latency in the principle of the game
(G) use the event scheduling table to broadcast events that need to occur simultaneously on all user clients to all users in advance.
(H) multiple attacks are used to kill an Genie and minimize one-time, deterministic, and delayed sensitive events.
(I) extend the time for a bullet or rocket to fly in the air (prediction and interpolation at all clients while flying)
(J) it takes time for all objects to move from one place to another, avoiding design such as "instant movement".
(K) try to make all the Genie, spacecraft, or other objects in the game run according to predictable tracks, such as adding inertia to the movement.
(L) make full use of creativity, merge events in the game to the maximum extent possible, and merge latencies in the game, we also need to plan and pay attention to the technical improvement while avoiding some designs with great impact and cleverly hiding "latency"

4. Synchronization status quo:
(A) insufficient attention: Many people have not yet realized the existence of this problem. Some companies have spent half A year planning to create an online version of "Squirrel wars.
(B) no technical solutions: for most programmers, stand-alone games are in a hurry to enter the Internet era if they are not mature.
(C) research on this technology requires the ability of a competent company to provide, without which, even competent programmers cannot succeed.

5. Three major technical difficulties of online games:
(A) server response question: how to make the server provide the highest response when more and more people are supported
(B) synchronization problem: as shown above, in the case of limited network response, quick real-time games are achieved to provide the most perfect interaction
(C) distributed server: how to unify the scattered "world" into a "world" by means of dividing user data.
Who can really solve the above three problems, combined with the planning breakthrough in design, will make other people within at least two years.
   
6. Supplement:
(A) The Grid technology is still being copied and used in games. There are still many technical difficulties to break through (for example, the current unit computing time of the grid is calculated in seconds ).
(B) In fact, contrary to the ideas of many people, 3D technology is no longer the main contradiction. At present, the above three problems can be said to be on the same starting line at home and abroad, and there is a full opportunity to take the lead.
(C) now it is very urgent to solve the synchronization problem, and the required environment is also mature. As long as you pay attention to it, you can draw more mature conclusions within half a year.

 

 

The lower part of the text author blog http://blog.csdn.net/skywind/

[Reprinted] synchronization of online games