Online Game real-time action synchronization solution note

Unlike MMORPG,Real-time action-type online gamesThe response requirements for operations are extremely high (<150 ms ).
Producers of action-type online games want to experience stand-alone games and provide online game services.

The synchronization algorithm of network commands between multiple clients depends on the two features in principle:
*Sacrifice local Timeliness: Mutual waiting to ensure that the instruction sets of each client are consistent within the specified time range.
*Sacrifice local consistency: Allow the client to simulate it first, and wait for subsequent instructions to be corrected. (DR)

The existence of the network makes it impossible for both fish and bear's paw. Therefore, action network games on the market now have
The following compromise and compromise are achieved:
*Calculate a large number of key operations on the client's local machine to ensure touch
*In terms of gameplay, the requirement for direct decisive interaction is not high.
*Maintain complicated and precise gameplay by accepting the disadvantages of waiting due to network latency from time to time
*Lower requirements for consistency under the bottom line of planning to maintain playability

Online games with high real-time requirements are a key art.
To some extent, FPS, racing cars, RTS, bubble Hall/QQ Hall, simulator networking, and other types of online games
There are one or more options.

---------------------------------------------------------------------

In many real-time synchronous online games, UDP is used instead of TCP in MMORPG.
Non-key message synchronization (more racing games may use P2P networks ):
Non-critical messages allow packet loss, and client-side prediction and compensation can be made for the object status; UDP can even easily penetrate the wall;
Therefore, UDP is more suitable than TCP in this case. Dead Reckoning is a common client.
Prediction Technology, while client-side predictions with more details have different extensions for different types of games.
This technology was used in previous UDP centers such as halflife, quake3, and counterstrike.
FPS games with server action authentication have mature applications.

Although the real P2P Mesh interconnection action synchronization is not suitable for online games (consistency and anti-plug-ins ),
However, after observing a few games, I found some games, such as bubble bubbles, running karting cars, QQ speeding cars, and famous Three Kingdoms.
It is true that mesh P2P is used to varying degrees (some teams enable P2P for location synchronization in public scenarios ),
In addition, some of the sending and receiving packages respectively reach 20 per second, almost half of the rendering frame rate.

Intuitive conjecture is that the actions between players are displayed in real time, but the key interaction results are not real-time.
Most of the use of items is promoted.Range-basedAndLatencyTo reduce the impact of network latency.
In this way, you can increase the UDP packet sending frequency and quantity, and pull the Client After simulation:
If you do not cheat, if you receive enough packets per second on average, simple interpolation and prediction are naturally smooth.
Key Attribute changes, battlefield items drop, death, victory, and so on, are non-real-time central servers.
Information to ensure the uniqueness of the results.

Even so, I still feel that the P2P system should have a certain degree of synchronization rules between peers.
I have never understood the synchronization knowledge of the P2P system before, so I checked some relatively easy-to-find paper first,
The following describes the Distributed State synchronization algorithms.

---------------------------------------------------------------------

Lockstep Synchronization

The most intuitive synchronization scheme: Any peer action can be initiated only with the consent of all other peers.
See:



If a non-mesh P2P model is used, the peer master is provided for unified state calculation,
Then the lockstep model becomes a strict Frame Synchronization Model. Most of these models are connected to the Internet of RTS and simulators,
And some synchronous models used by casual action games that provide connection after host creation.
In this case, you can synchronize multiple peer event commands just like writing a serial single-host command.

Lockstep was originally a term used by the prison. It refers to the simultaneous chained movement of prisoners during walking.
Initially, it was not designed to be used in games, but military interactive simulation programs. According to the ieee dis standard:
-Ms of two-way total latency, which is acceptable for military interactive simulation. According to some statistics,
The two-way latency of first-person shooting players is generally within 50-MS.
However, if all players perform P2P connection within a LAN, the two-way delay may be controlled within 20 ms.

Advantage: it is simple and easy to implement without any inconsistency.
It is suitable in a stable environment with a low latency (less than 100 ms.
It is also suitable for games with low real-time requirements (such as the turn-based gameplay.
Disadvantage: the pace of the game is greatly affected by the slowest peer. One person gets stuck and all people are affected.
Malicious peer can gain benefits by forging large latency, undermining the game's fairness.

---------------------------------------------------------------------

Bucket Synchronization

See:
 

The original paper is very long. Here we only follow the steps for personal understanding:
(The original article is a completely distributed mesh P2P. To facilitate understanding, we will refer to Player B as a peer master,
Assuming that it is responsible for the time task to save NTP's understanding of the Time System)

1. Set the maximum latency toplayoutdelay (for example, 120 ms ).
Playoutdelay: the time when the peer master executes command N-the start time of the bucket period corresponding to the time when the remote peer's command N is issued
2. Set a new bucket to store action commands at intervals of bucketfrequency (such as 40 ms) on the game timeline.
3. Before starting the game, the peer master sends a pair command to all peer.
4. Because the peer master knows the avglag latency of all peers, after performing step 3,
After avglag delay, start the game logic.
5. Although the operation commands issued by the peer master do not need to pass through the network, they also need to be forcibly delayed.
Deliver to the bucket corresponding to Ti, where:
Ti = start time of the bucket time range to which the current time belongs + playoutdelay
6. If the peer master receives an Action Command,:
Current Time of peer master-sending time carried by Action commands> playoutdelay
Then the peer master will directly discard this Action Command (that is, the command to arrive at timeout is considered invalid)
7. If the action commands received by the peer master do not exceed the range described in table 6 above
Put it in the bucket corresponding to Ti, where:
Ti = start time of the bucket with the sending timestamp carried by the command package + playoutdelay
8. At the end of each bucket's corresponding time period, the peer master executes all the commands in the bucket,
Update the result status to the screen.
9. Because of the existence of a network, some buckets may have no commands. The original mimaze game implementation will not be processed.
However, paper provides the dead reckoning-based method for displaying the predicted status.
10. During the game, when the peer master pairs each peer at a certain interval,
Ensure that the time error of each peer machine is controlled within an acceptable range.

Advantage: it does not rely on the slowest peer to determine the smoothness of the game. Smoothness is maintained at the average predefined level.
Disadvantage: discard commands that exceed maxlag. In addition to the original paper 3D douman maze game
After a specially tailored game, it seems hard to imagine that an action game discards operations that delay players.

---------------------------------------------------------------------

Timewrap Synchronization

It is a synchronization algorithm that supports rollback based on certain States. Similar to HL's practice.
In short, a snapshot is saved after each operation command is executed ),
Each peer is displayed based on its own predictions, but in the case of consistency conflicts,
Roll back to the previous status, and re-run the command sequence on the basis of the rollback snapshot.
Run the command once to obtain the correct current status.

---------------------------------------------------------------------

Trailing state Synchronization

An Improvement on timewrap synchronization. In the timewrap solution, set snapshot
The Unit is separated by the number of commands (1 or a few instructions), while the TSS scheme uses a certain delay value (100 ms)
Set the interval to snapshot The Game (for example, one before Ms and one before ms ...).
When a consistency conflict occurs, find the snapshot that needs to be computed as far as possible and
Run the command again in the current time to get the correct Latest status.

---------------------------------------------------------------------

References:
<Minimization of latency in cheat-proof real-time gaming by trusting time-stamp servers>
<End-to-End transmission control mechanisms for multiparty interactive applicatins on the Internet>
<Dead reckoning: latency hiding for networked games>
<An efficient synchronization mechanic for mirrored game ubuntures>

---------------------------------------------------------------------

ZZ: http://blog.csdn.net/akara/article/details/5885037

(Switch) Notes on real-time action synchronization solution for online games