In online games, there are generally two ways to synchronize data, state synchronization and frame synchronization.
In state synchronization, the battle logic is mainly placed on the server side. The client uploads the player operations to the server. According to the operation, the server checks the battle logic. Then the server periodically sends logical data such as the player’s coordinates, orientation, attribute values and other data to the client. The client is equivalent to a player. Compared with frame synchronization, the transmission frequency of state synchronization data is low. Frame synchronization, and the amount of data sent in a single time is larger than frame synchronization. Because the backend of the combat core computing logic is responsible for calculation, the server pressure is relatively high, but the requirements for the network are lower than frame synchronization. .
The advantage of this state synchronization is that there is no data inconsistency problem, the disconnection and reconnection recovery is faster, because the logic is on the server side, it is more difficult to cheat, but the disadvantage is that the data consumption is large, and for games with higher real-time requirements, the feel is also It will be worse.
In frame synchronization, the battle logic is placed on the client, and the server divides the time into fixed and extremely short time slices. Each time slice is a logical frame. In a time slice, the server will collect the player's operations, and when the time slice is over, send the collected player operations to all clients, continue to collect the next operation, wait until the next time is up, and send the collected operation For all clients, the client will check the battle logic according to the player operations sent by the server. Through the random number seed, frame sequence number, and the server to synchronize data with the client in the same frame, the same input and the same timing ensure that the client's verification of the battle logic is the same.
For games with high real-time requirements, frame synchronization is required, and the user experience is relatively smooth. Since only the player's operation data is sent, the amount of data is relatively low. But because the logic is easy to cheat on the client, and each client performs the battle logic verification, it is impossible to verify each other, and data inconsistency is prone to occur. Since the server does not have player status information, the disconnection and reconnection recovery needs The client quickly checks all the previous logical frames.
The two synchronization methods have their own advantages and disadvantages, and we need to decide which method to use for data synchronization according to different game types. For example, MMO, Xianxia, or legendary games do not have high requirements for player operations, mainly for spelling numbers. There are more players on the other map, and it is necessary to synchronize the combat data of the combat units in the player's field of vision. Because there are more players, if you use frame synchronization, the client can't handle it. In addition, this type of game does not have that high requirement on the player's operating feel, mainly for spelling numbers, so it is more suitable to use state synchronization. For moba and shooting games, this type of room has higher requirements for the player's hand feel. For games that require low latency, frame synchronization is required, and state synchronization cannot meet the demand.
The server battle logic for state synchronization is all on the server, how to implement it according to your own needs, and the frame synchronization is relatively simple compared to the server logic, and the practices are roughly similar. As for the time of each frame, if it is too long, the player will feel stuck, and if it is too short, the client computing pressure will be greater. At present, the general frame synchronization is 15 frames per second, that is, the time of each frame is 66ms. The client collects the player's last operation every 66ms and sends it to the server, regardless of whether the player has an operation or not. The server broadcasts the player operation data received in this frame to all clients, and the client calculates logic based on the player operation data. Generally, protoBuf is used in the communication protocol between the two parties, because the compression ratio is relatively high, so the data packet will be relatively small. Frame synchronization also requires a random number seed, so that the number randomly generated by each client is guaranteed to be the same, and the output result of the same operation is the same.
Frame synchronization uses UDP for communication. In fact, when the network is in good condition, the time delay of TCP can also be used for frame synchronization, mainly to deal with network fluctuations. Because TCP is packet loss retransmission and data transmission in order, when the network fluctuates, When packet 1 fails to be sent, it will block the sending of packet 2, and UDP will not affect the sending of packet 2. TCP has flow control and will limit the rate of packet sending. The timeout retransmission mechanism prevents packet loss, and then group packets according to the sequence number. The transmission of UDP is controlled by the protocol stack, and UDP is completely controlled by us. In addition, UDP transmission is relatively fast, and we can deal with packet loss and disorder in frame synchronization.