One of the key features in the upcoming Manstein build is the complete opposite of the Matrix: you cannot see it for yourself — you have to be told what it is ;-) I am talking about a very useful, yet invisible, improvement in the way the action game client interacts with the server hosting the battle: the partial game state update.
What is it and how does it affect you? I’m glad you asked, because I was going to tell you anyway. As the name implies, a game state update is a chunk of information that the game server sends to your client application (hng.exe, the action game) to “tell” it what’s going on: where the players are, what they’re shooting at, which way they’re running, how much health they have left, and so on.
This information, the game state, is renewed several times per second on the server by first gathering input from all the players in the same battle. The server then simulates the world (making dead guys officially dead, blowing things up, etc), puts all the info together in a “package” and sends it back to each player’s computer.
The server does not wait for input from the clients, so it’s up to the clients to make sure their input (keyboard/mouse) gets to the server in time. If no new input reaches the server, it will assume that you are doing the same thing you were doing at the time of the last world update. The client handles the synchronization by being ahead in game-time in relation to the server; that way the game is still responsive on your machine even if you’re lagging… but any update from the server will have to be advanced to the client’s local time (prediction). This is the classic client/server network model.
So what happens if you have a crappy connection and the input you send gets delayed? Our software works in such a way as to make sure that Jim-Bob Jr, who suffers from a terrible network connection (packet loss, for example) is not affecting everybody else’s ping. Instead of waiting for him, the game keeps on predicting where he’s going. So from Jim-Bob Jr’s perspective, when the connection gets really bad, the character may appear slow to respond to commands, or he may suddenly “bounce back” to his previous location. This is called rubber-banding. It’s a side-effect of the client updating its game state after failing to send a few packets to the server. This model allows the game to keep providing the best possible experience to everyone, given the limitations of each player’s individual internet connection.
Where the partial update comes in, is that instead of always sending/receiving all of the game state info to/from everybody every single time, the new system that we will introduce in Manstein will refresh as much information as possible in every update without exceeding the bandwidth limitations. In addition, the partial state is based on the last confirmed received state from the server (received by the client, confirmed to the server). Instead of sending the data uncompressed, we now only send the difference between state subsets, between the client and server. It works a bit like the key frames in compressed video, except this will still work even if we skip a key frame.
- help the game handle packet loss and bandwidth usage spikes better;
- allow us to add more synchronized physics (i.e. more different kinds of action can now happen);
- allow us to increase the number of players in a single battle;
- solve the initial spikes in traffic when connecting;
- allow us to handle connections with low MTU‘s (low maximum data size per UDP packet)
Sounds good, doesn’t it? Class dismissed! Now grab your rifle and go be a hero!