What every programmer needs to know about game networking

[Email protected]

Starting Link: http://blog.csdn.net/rellikt/archive/2010/09/12/5878447.aspx

Original: http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

Introduced

As a program, how do you think about the network multiplayer battle game?

From a layman's point of view multiplayer games are magical: 2 or more players experience similar gameplay at the same time, feeling like they're playing in the same virtual world. But as programmers we know that the truth is not what they think, and the vast majority of what they see is actually an illusion. They believe that many of the events that have been going on between players are actually just a realistic simulation. Different players are more or less out of sync, and programmers are making these different steps in the player's eye. by Rellikt

Round-the-peer communication games

At the very beginning, the network topology model of the game is peer-to structure, all the machines are the equivalent nodes in the peer network, they send each other the required information, do not need any transit. This network topology model is common in many RTS games, and even the first model that many programmers think of when they think about the web is this model, because this model is really similar to the model that we normally communicate with human beings. by Rellikt

The basic idea of this model is to abstract the game into a round round, convert all the inputs into one instruction per turn, and then process the instructions at the beginning of each turn, which will naturally drive the game state machine to run. The most common instructions we have in a SC-like RTS are: Mobile, attack, architecture, etc. With this model, we just need to make sure that all users have the same set of instructions, and that their initial state is the same, there will be no problem.

The above introduction may be a bit too simplistic for a network module like SC1 's RTS game. In fact, I'm just saying a general idea, and if you're interested, you can refer to this article about the Age of Empires.

The network topology model mentioned above does seem to be simple and practical, but the simplicity of the model also introduces some of the following limitations:

This model is very demanding on the repeatability: because we are only responsible for the synchronization of instructions, not responsible for the synchronization of the specific running results, we will probably find that because a infantry in the search for a little bit of a different place, it led to a battle of the result is very different. The butterfly effect of this situation is enough to crash our gaming experience. by Rellikt

The second drawback of this model is that it is important to ensure that all players ' commands are aligned at the beginning of the round, otherwise the order of the round cannot begin to simulate. This means that the delay of all players depends on the delay of the player with the greatest delay. In order to solve this problem, RTS usually set up some pre-shaking pictures and music to let the player think that the instruction has begun to simulate, but in fact the actual command to start the simulation time will certainly and the player input time is delayed. These disguises are a good cover-up for the player.

One of the last drawbacks of this model is that players must join the game from the start. In other words, the mode of the game is usually in the hall open a room, and then players join the game to play, this mode will not allow players to join halfway. Although it is a theoretically feasible solution to save the instructions from the beginning to the halfway, and then the player who wants to join, and then add it, the problem involved in the program is very predictable in the game, the requirements for synchronicity are very high, and the simulation time is also a problem. At least we haven't seen any of these models play a similar attempt. by Rellikt

Although the model we mentioned above has a variety of unsatisfactory shortcomings, but in real-world RTS games (such as StarCraft 1, Red Police 1, Empire 1) in the basic use of this model, because this kind of game we will operate thousands of units, to each one to synchronize the state of each unit is not scientific, We can only synchronize the instructions, and then through the command to synchronize the game, to promote the normal operation of the game state machine.

In fact, in the latest RTS game may have abandoned the peer-to mode, but the concept of turn-class communication will still be preserved, otherwise it is impossible to complete the synchronization of thousands of units.

But the times are progressing and the types of games are different. The primitive turn-to-peer system has largely been abandoned in many other types of modern games. Let's take a look at the network model of FPS Games introduced in Unreal,quake,doom.

Client/server-side model (c/s)

In the initial Quake game, Doom used the turn-based communication model, the results found that in addition to the low latency LAN high bandwidth situation, the other circumstances of the game can not be satisfied. by Rellikt

In fact, the player can actually use the virtual LAN software to simulate the local area network, and then connect through the LAN mode. But the connection situation is very sad. Those who surf the web with cobwebs don't mention it (14.4kbps PPP connection or 28.8kbps cat surfing the Internet). They must be the most powerful. The player with broadband is not necessarily good enough to go there. Because the high latency of the peer model is not well covered in FPS games, the formal simulation of the player input must wait until all the players ' instructions arrive to be processed, which means that your delay depends on the worst delay of the current player, and if your teammates have 300ms delay, Then you click on the shooting button, you have to be over 300ms before you can make a shooting simulation. This situation makes a lot of network bad players can only feel powerless.

In order to make more network bad players can also play normal. In 1996, John Carmack used the C/s architecture to replace the traditional peer-to architecture when launching quake. The C/S architecture and peer-to architecture are different, peer in each client will run the game logic, game display and other complete game, so peer-to-game replay requirements are quite high. The concept of C/s architecture is to run all the game logic and input response on the server side, in the client only run all the game display, so that the client only need to take some of the state of their own needs to synchronize, the user input to the server side, and then display the results can be. by Rellikt

Take the traditional FPS, the ideal c/s structure, the client only need to send their own input such as mobile, turn, open fire to the server side, and then from the server side of their own and the surrounding visible players position, direction, animation State and other information synchronization down, do a reasonable interpolation, so that its various roles appear smooth enough, And then show it. A basic C/s architecture of FPS is complete.

Comparing the above two models, we find that the biggest advantage of C/s architecture is to change the delay from the player of the most card to the delay of the server connection. It is also easy to implement the concept of using this architecture to join the player in the middle. Finally, in the contract above, the bandwidth requirements are also much lower. Just need to send the input to the server side is enough.

But the pure ideal C/s model is still insufficient place, that is the delay, FPS requirements for the delay is quite high, the Internet two endpoints between the 300ms is very normal, if said a turn command to wait 300ms after the response, to 9s/m running speed to calculate, The player has already run out will be nearly 3m, perhaps already fell into the ditch inside.

In order to allow more players using the bad network to join the game, John Carmark introduced a new technology for client-side predictions when quake was introduced. by Rellikt

Client prediction

In fact, in the early FPS game, we do encounter a key to wait half a day to respond to the situation, and this time is related to your network delay, some strong players can even adapt to this situation, advance to make a pre-sentence operation. However, in modern FPS games such as cod and other games, you will no longer have this experience, then our modern FPS game is what means to remove these delays?

This part of the technology is generally divided into two pieces: client prediction and delay compensation. These techniques are described in the network section of the Unreal Engine. Here we focus first on the concept of client-side prediction.

When John Carmack introduced quake, I would introduce the concept of client-side prediction in the new quake, which means that clients do not simply do some synchronization and display. They will also make predictions, that is, before the server-side data is obtained, the client will pre-predict the results of the input and predict the actions of other visible players and display them immediately, which will make the current client require physical and game logic to run locally. The original perfect c/s model here is not so perfect, but let us face the reality, the reality is not perfect. by Rellikt

What we are now is that the client will run a part of the game logic code after accepting the local input, judge the state of the user, then simulate, and then show that the client will not wait until the server-side data arrives and then simulate, so that the delay to the client is no longer there.

But for client-side predictions, the focus is not on predictions, but on synchronization. We just need to use the same code and predict that there will be no problem with nature. But it's a big problem when the server and client are in disagreement about the results.

When it comes to this, you think, if the client has already predicted the process of the game, why not let the server side synchronize the results of the client? Such a scheme seems to be good, but the accompanying cheating problem is very serious, if the server does not simulate, but the simple synchronization player state, then the instantaneous shift, invincible and other plug-ins will be very common. Players just need to simulate these and send out the corresponding package. Many of the popular MMORPG now in the plug-in is the result of this synchronization. In fact, due to server performance considerations, it is often only the simplest synchronization of some state and event information in an MMO. by Rellikt

So in the implementation of Unreal, Tim Sweency decided to allow the server and the client to simulate the game separately to implement the user-side predictions to eliminate the delay. Tim sweency in Unreal Networking Architecture wrote "The Server is the man".

In that case, it is easy to think of an interesting question. Our principle is that the user state is based on the server emulation, the client must synchronize the state on the server immediately, and make its behavior consistent with the server. The problem now is that because the latency is objective, the data on the server is always slower than the client. In fact, the data that the client can synchronize to is only the ping value (the packet is on the client and server side a back-and-forth time) before that point in time.

If the client simply synchronizes the currently obtained server-side data, the result is that the client will synchronize the previous state of the ping value back, and the modification is exactly the part of the client prediction we are going to make, and if we do, then our client predictions will be completely meaningless. by Rellikt

Here Tim Sweency the method is to use two ring buffer, a record client state, we call it a state buffer, a record client operation, we call it the operation buffer, the length of the two buffers should be long enough to accommodate at least the ping value of the time of the state and operation. We write the client state to the state buffer at a fixed time, and each operation is buffered by the write operation. When the server-side data arrives at the client, we extract this server-side data with a point in time, then release the previous data from the client's two buffer buffers, and then extract the closest point-in-time state data from the state buffer. Starting from that state, the operation data in the operation buffer is simulated, and the current state is obtained, then the interpolation is synchronized with the obtained state. In fact, in order to eliminate the delay we have been rolling back and then repeating the process, the larger the ping value, we need to roll back and repeat the more time, and in the new state of the resulting may require interpolation and synchronization of the greater amplitude.

This is how the delay is handled in the unreal, which, if used properly, can effectively cover up the delay. Tim Sweency, in Unreal's white paper, said that if our game is more reusable, we need less interpolation, and even if other clients and environment variables do not change, we hardly need any interpolation or modification. In fact, in unreal, it is often only by hitting the enemy or being fired by rockets to use interpolation changes.

In other words, as long as it does not involve the actions of other players or people cheat, then we use the client prediction is often very accurate. by Rellikt

Conclusion

About client predictions I just want to talk about it now. If there is time for the next period, I will write some more about the concept of deferred compensation or modify it directly in this article. is the existence of delay compensation technology, is the user can sandstorm in the case of delay, experience the feeling of delay.

What every programmer needs to know about game networking