Master your own destiny! Command a nation!

Developer’s Corner: Partial State Update

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.

Partial Law

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!

  1. westwickwestwick10-07-2013

    Can you divulge what info gets left out when the bandwith limits are reached?

    • reto.letoreto.leto10-14-2013

      We prioritize new state (like shots fires/spawns). Stuff you control like heroes and vehicles. Most of the time you will get a full state (for 18vs18) because the state update is smaller than the bandwidth limit (20 Kb/s). In the future we will add more networked synchronized physics (barrels/destroyed vehicle parts) witch will generate quite a lot of traffic when activated (a tank driving into 20 stacked barrels) and the partial state update will favor updating objects closer to you first. We do however have some technical issues with physx that we need to resolve first to get proper client side prediction of rigid body physics. We might add some decoy characters as well just to make wallhackers feel like they are being stalked from behind every corner :)

      • westwickwestwick10-14-2013

        Nothing finer than putting some fear into the ones that see too much. A good jump scare might be in order!

        I can imagine dropping some explosives onto the fences might cause a heck of a data headache. Nice to see that these details can be treated similarly to model LOD.

        Thanks for the response. Look forward to driving my Harley through a pyramid stack of cardboard boxes!

  2. BlaineUKBlaineUK10-07-2013

    Good to hear, and Reto.Leto, I love your name. Keep it up with the updates, I really like reading stuff like this from you guys!

  3. patton1995patton199510-08-2013

    I always hated the networking stuff XP
    Aside from that, sounds good to me, and keep up the work guys :D

  4. MasterTankerMasterTanker10-08-2013

    I hope.

  5. djopadjopa10-08-2013

    some new looks for the panzer crew, cool.
    i hope that this partial state update will eliminate my lag.
    good work.

  6. k120k12010-09-2013

    I hope this will make it playable again and not making it worse like Leeb did.

  7. CYNICCYNIC10-10-2013

    “allow us to increase the number of players in a single battle;”
    This is thing we need badly. I missing more epic battles, great job Reto improving your net code!
    32×32 battles that what we're demanding! :^)

What are you waiting for soldier? We need heroes on the battlefield and generals to lead them!