Talk about online game Synchronization is very important in online games, which guarantees that every player is generally the same on the screen. In fact, the easiest way to solve synchronization problems is to broadcast every player's movement to other players. In fact, there are two problems: 1. Which players broadcast, which news is broadcast which news. 2. What if the network is delayed. In fact, the first question is a very simple question, but the reason why I put this question is to remind everyone that this factor needs to take this factor when designing your message structure. For the second question, it is a very troublesome problem. You can come to see such examples: For example, there is a player A sent a command to the server, saying that I am in P1, go to P2 point. The time issued by the command is T0. The time of the server receives the command is T1, and then broadcasts the message to the surrounding player. The content of the message is "player A from P1 to P2" has a player B near A. Receive the server The time of this broadcast message is T2 and then starts on the client, A from P1 to P2 points. At this time there is an unacceptable problem, and the screen displayed on the screen of the player A and the player B differs from T2-T1. What should I do at this time? There is a solution, I gave it a prediction to pull, although it is a bit weird, but basically everyone can understand it from the literal. To solve this problem, first define a value called: predict error. Then you need to add an attribute in the class, called Timemodified, and then compare the client time and server time when the player is logged in, and then compares the difference in TimeModified. Or the above example, when the server broadcasts the message, calculates a client's currenttime based on the TimemodifiedIfiedIfIED to broadcast the object, and then contains this CurrentTime in the message header, and then broadcast. At the same time, it is also a queue in the client A client to save the message, and only the server authentication will be deleted from the unauthenticated message queue. If the verification fails, it will be pulled back to P1 points. Then when the player b received the message "player a from P1 to P2", check the time and local time to check the server in the server. If it is greater than the prediction error, even if it is in T2, players A location P3 walking on the screen, then pull the player A on the player B directly to P3, then continue to go, so you can guarantee synchronization. Further, in order to ensure that the client runs more Smooth, I don't recommend pulling the players directly, but calculates a point P4 after the P3 is biased, and then uses (P4-P1) / T (P4-P3) to calculate a very Fast speed S, then let the player A quickly move to P4 with speed S, this processing method is reasonable, the original shape of this solution is internationally called (of course, the original shape is tampered with Many to adapt to the synchronization of online games, so becoming a so-called: predict pull. Another solution, I gave it name to verify synchronization, listen to the name, the general meaning is that each instruction has passed the server verification. The specific idea is as follows: First, you need to define a Timemodified in each player connection type, and then on the client response to the player's mouse, the client will not walk first, but send a walk to the server, then wait Verification of the server.
After the server accepts this message, the verification of the logical layer is performed, and then calculates the range of broadcasts, including player A, and generates different news heads according to different TimeModified, which is different from each client, start broadcasting, this time this player walks Information is completely synchronized. The advantage of this method is to ensure absolute synchronization between the clients. The disadvantage is that when the network delay is relatively large, the player's client's behavior will become less smooth, bringing a very unpleasant feeling to the player. The prototype of this solution is internationally called Hierarchical Master-Slave Synchronization. After the 1980s, it is widely used in various areas of the network. The last solution is an ideal solution that is known as Mutual Synchronization, a good predicted solution for future network prospects. The reason why we have to mention this scheme is not to achieve this approach, but is just some of the ideas of this program in some ways in the field of online games. I named this scheme: half server synchronization. The general design idea is as follows: First, the client needs to establish a lot of broadcast list when landing the world. These lists are not timely synchronization in the client, and to build multiple lists because the type to be broadcast is More than one, for example, there is local message, there is Remote Message, and Global Message, etc., these lists need to be established based on the messages sent by the server when they log in. At the same time as the list is created, you will also need to get the TimemodifiedIfiedIfied in each list, and to maintain a full user status list in the background, it is not timely and the server to synchronize. According to the local user status table, you can do it. Some decisions are determined by the client. When the client sends this part of the decision, send the final decision to the client inside each broadcast list, and the time is correct, ensuring that each client is received. The time of the message is related to the school according to the local time. Then use the calculated advance amount mentioned in the predictive pulling, improve the speed of the process, will make the synchronous SMOoth. The advantage of this program is not to synchronize between the client, which greatly reduces the error due to network delay, and because most of the decisions can be done by the client, it is also greatly reduced by the server. Resource. The resulting drawback is that the information and decision rights are placed locally locally, so they provide a lot of machines that can be multiplied. Comprehensive three more than three advantages and disadvantages of the network synchronization faction, combine a more complete solution for online game transmission synchronization, I call it a colligate synchronization. The general design idea is as follows: First, all messages that need to be synchronized from divide a priority level, then divide important messages and non-important messages according to the 3/4 proportion, for non-important news, put decision rights on the client, in customers Established relevant decision means and various message cache, and related message cache management agencies, as shown below: The above figure shows the general processing flow for non-important messages, including one client. Passive behavior is worth noting that in which certain verification code sent by the server is returned to ensure that the messages in the message cache are consistent, thereby effectively preventing extensions from tampering up the local message cache. The source of the message is the message including the local client response to the player's message and the remote server passed.
For important messages, such as fighting or some of the more sensitive data that involves some sensitive data, the program first needs to create a set of ping system between the server and the client, then the server is saved and the user Timely ping value, when ping is relatively small, the response to the player message does not perform actions, but first feed back the message to the server, and blocks the server, the server receives the message, after logic verification, to all this detail The valid object of the broadcast is broadcast (including the message initiator), and then the client receives the verification of the message to start performing the action. When Ping is relatively large, the client responds to the player's message, and simultaneously feeds back the message to the server, it is worth noting that this time needs to establish a queue without verified messages locally, put the message into The team, performing the operation of the server, etc., but also saves the current state. After receiving the request from the client, the server is logically verified, and the message is fed back to each client, bringing local time to each client. If the verification passes, the notification message initiator, the message verification fails, and then the client automatically cancels the action already in progress and restores the original state. If verified, the broadcast to each client pulls the time to pull it from the server to ensure synchronization before the behavior is completed. At this point, a more mature online game synchronization mechanism has been initially established, and the next logic code is written according to the different game style and side focus. Synchronization is the most important issue of online games. How to synchronize and involve all aspects, such as the size of the game, the type of game, and a variety of aspects, for a relatively large game, can be more Work, divide the news very delicate, using different synchronization mechanisms for different messages, and for games with small scale, can use substantially the same synchronization mechanism, how to synchronize, no pose, it is necessary Different cases of different synchronous decisions, the navigation of the online game synchronization algorithm: DEAD RECKONING algorithm: Before understanding the algorithm, let's talk about some background information of the algorithm. Everyone knows that when the network is transmitted, the delay is very common, and the synchronization of online games based on the Server / Client structure has become a headache, and the client responds to the smoother local directive. Under, it is impossible to effectively guarantee the timeliness of synchronization. Similarly, there are similar things in the military, even if the machine inside the same lan, it will also lead to the mistakes of the transmissions, and the US Department of Defense has put a large amount of funding to study a comparison. Good solution to solve the latency problem in a distributed system, especially a system called Distributed Interactive Simulation, this system, which presents a set of programs named Latency Hiding & Bandwidth Reduction Named to dead reccking. Oh, it is very big, Well, then let's take a look at some of the views of this system, and how we use it to our online game synchronization.
First, this synchronization scheme is based on the Mutual Synchronization synchronization scheme in the article "Synchronization of online games", that is, it is not a Server / Client structure, but based on the synchronization between the client. Let's first speaking some nouns concepts in this article: Net network: network node composed of clients: Each client limit error in the mesh network: the polarity that may generate when synchronized Before you discuss the principle, let's take a look at what we need. First, need a mesh network, how does the mesh network make up? When there is a new node to enter, inform the network all nodes, each node creates a copy of the client locally, when logging out, notifying all nodes to destroy the local copy of the node. Then each node saves some data? First, there is a very important package that needs to be saved, called the Protocol Packet (PDU Protocol Data Unit), PDU contains some related motion information of nodes, such as current position, speed, motion direction, or acceleration, etc. In addition to the PDU, there are other information to be saved, such as the HP, MP of the Node Client Character. Then, ensure that each node broadcasts a PDU information to other nodes within a minimum of 8 seconds. Finally, set an ultimate error value. At this point, its environment is completed. Below, let's take a look at the relevant specific algorithm: assume that there is a small person (passers-by) in the node A, starting to run, this time, like all the nodes broadcast his PDU information, including: speed (s ), Direction (O), acceleration (a). Then all nodes began to simulate the movement tracks and routes of the road human armor, including the node A itself (this is very important), and the passers-by under the control of a certain player, will change the direction from time to time, let it run The route is not so regular. During the running road, the node A has a value that is constantly recording its real coordinates and the difference between the coordinates of the simulated motion in the background, when the difference is greater than the limit error, calculates the current speed S, direction O and speed a (algorithm will be introduced later) and broadcast to all other nodes in the network. Other nodes after receiving this message, you can use some very smooth mobile to pull the passers-by, then re-adjust the data of the simulated running road, let it continue to simulate the running road in the background. Obviously, if the limit error is defined, the deviation seen by other nodes will be too large. If the limit deviation is defined, the network bandwidth will increase. If this ultimate error is defined, it is designed according to the importance of various data. If it is a returned online game, then the limit error is defined on the road, it doesn't matter, it can reduce bandwidth. But if it is a timely fighting online game, you have to define a small limit error, otherwise someone will see someone to hack itself. There are 9 main algorithms of dead recons, but only two are to solve the main problems, others are only a different algorithm for different coordinate systems, this is not one of them.
Ok, then we look at the legendary two algors: first: target point = origin speed * time difference second: target point = original point speed * time difference 1/2 * acceleration * time difference, legend The algorithms are very classic, although we have learned when we have physically physically physically. The advantage of this algorithm, as it starts, Latency Hiding & BandWidth Reduction, from principle solves the problem of disagreement caused by network delays, and effectively reduces bandwidth, bad places is basically only Can be used in the movement of the movement, of course, the synchronization of the mobile is the biggest problem in synchronization in the online game. This method combines the composite synchronization of the synthetic method of "online game synchronization", which can basically solve the problem of walking synchronization in the online game. Related questions are welcome to discuss together. Smooth processing in the navigation estimation algorithm: According to my last article, when Node A receives a new PDU package, if the coordinates of the local simulation of B, if the coordinates of the analog motion of B, How to put B to the point of the new PDU package on a on the screen. Only "very smooth mobile" put B "pulled" in the past, then how should it be operated in actual? ? Here, four methods are introduced. The first method, I named the name directly, everyone listened to the name, just directly put B hardbound to the coordinates described in the new PDU package, the advantage of this method is: Simple. The disadvantage is: After reading the following three methods, you will not use this method. The second method is called straight linear, that is, let B take straight from its current coordinates to the coordinates described in the new PDU package, walking speed with the classic algorithm described above: Target point = origin speed * Time difference 1/2 * Acceleration * Time difference calculation: First calculate the time required from the coordinates described in the current coordinates to the PDU package: t = dest (targetb - originb) / speed then according to the new PDU package The coordinate information simulation calculates after time t, according to the location of the motion information in the new PDU package, the position of the motion information in the new PDU package should be reached: _targetb = newpdu.speed * T and then calculate one according to the current simulation operation B and _TARGETB Corrected speed _s: _s = dest (_targetb - originb) / t then let B get B with speed _s to Target_B, and adjust its speed, direction, acceleration, etc. after walking to the new PDU The package is described. This method, very soil will make the object moved very unreal on the screen, often appear very hard corners, and for the speed _s that often want to modify, on the screen of player A, players B action will become very strange. The benefit is: better than the first method.
