Why There’s No Lag in God of War: Ascension (or how we subtract approximately 150ms from your latency and make the game fair to both attacker and defender)

In this developer diary, meet the God of War: Ascension multiplayer team and learn about some of our lag hiding tricks :)

The open beta is live on Playstation Plus now, so hop on and try it out!

23 thoughts on “Why There’s No Lag in God of War: Ascension (or how we subtract approximately 150ms from your latency and make the game fair to both attacker and defender)”

  1. The networking strategy must be tailored to the style of game.

    Here, they have weapons that swing or connect ~0.2 seconds after pressing the button. That’s enough time to validate the move across both clients.

    However, it doesn’t “solve” the issue of lag- It works in this specific case, with slow weapons. It can’t be generalized for all games. Most shooter players will want their guns to go off instantly. There is always a compromise somewhere, as long as we are sucking data through very slow, tiny straws.

    Some games will be moving to thin clients, like with OnLive. There, the game client is just a controller and a video feed. EVERYTHING the player does it lagged. I can be generalized to all games, but you always have that lag.

    There is always a compromise in any networked implementation. The God of War team found theirs.

  2. I’m kind of confused.. Player A presses a button, and 200ms later the hit connects. Lets say it takes 100ms for that message to get to player B, on Player B’s machine does the swing animation need to be sped up to account for that lag? I think I’m really missing the point =(

      1. Yep I’m missing the point, or yep the animation is sped up? Sorry to ask so many questions!

        Thanks for all the great stuff you post about networking, this might sound weird but you’ve had quite a big influence on my development as a programmer =)

        1. The trick is that the defender is locked into the hit (eg. cannot block) before the blade actually hits on their machine, eg. at the point of pre-hit 100ms before the hit.

          This is where the lag hiding comes from. It’s subtle, and in some cases we still allow you to evade/magic/recovery out of it, but this comes at the cost of some inconsistency in views. I dislike any potential for inconsistency so it’s being hotly debated exactly how we tune this for the final game. As with many things, it is not magical and you have to make a trade-off.

          Time scaling is only done on the attacker’s machine. Once the attacker commits to a hit, he is locked in and 2/3rds timescales his animation. This gives extra time for the hit reply to return from the defenders machine. This effectively stretches 100ms of pre-hit into 150ms.

          cheers

  3. Hi Glenn Fiedler. I have a question struggling my head for quite some time.
    It is about the lock-step networking model. If you have “frame dependent movement” you can sync frames (and inputs) across the network and you are (almost) good to go. But instead games use the delta time to calculate movement so your move speed is the same on all fps rates.

    Thus, even if you sync frames (they do so in AoE), the delta time will fluctuated across machines. While the sum of delta-times “should” be the same, this fluctuations, I think, are enough to cause desync.

    How it is possible to deal with this issue?

    Thanks in advance.

    1. There are two major types of network models:

      1. Synchronous, where you have deterministic game updates and fixed time step.

      2. Asynchronous, where you synchronize both state and input and you don’t necessarily require determinism or fixed time step.

      So basically, you solve it by using network model #2.

      1. Hi, I think I didn’t put it clear. I talking about the first one as used by most RTS games. The question is basically: how can you have deterministic game updates with varying delta times?

        Thanks!

  4. You mention in the video “imagine a fan in front of the blade” or something to that effect… was that just for illustrative purposes, or is the actual implementation something like that using rays or a sweeptest or something? How would you know the path of the blade for that particular animation clip ahead of time?

    1. We know the animation and how that animation moves the blade, so we just look ahead in time in the animation data and this tells us the future arc of the weapon

      Cheers

      1. Very cool, thanks for the response! Are you allowed to divulge how position/rotation data synchronized in GoW? :) I have to imagine any Valve style interpolated view lag on remote entities would make melee combat really difficult and wonky. Are you doing any extrapolation or other fun stuff?

        1. It’s not interpolated, that would add too much lag. It’s entirely extrapolated with visual smoothing as per halo

          1. Awesome. Is that the same as Tribes? I’ve seen the “I shot you first” Halo Reach GDC powerpoint, but he doesn’t talk much about actual entity smoothing, just tricks and stuff they used for like grenade throws and armor lock (which is actually awesome and I used as inspiration, and sort of similar to what you’re doing here).

            So is melee combat in GoW authoritative at all? Or does the swinging player just say “I hit you” with the pre-hit and that’s it?

          2. Tribes does a combination of interpolation and extrapolation which is different (to my knowledge)

          3. Linear or ballistic is typically fine, or you extrapolate with a simplified version of the physics sim for vehicles etc.

            The trick is to maintain a visual offset for position and rotation error and smooth that out over time so you don’t get pops

    1. Untrue. RTS games like Warcraft use synchronous deterministic networking. God of war ascension was asynchronous p2p. Totally different technique

Leave a Reply