I'm working on a game that's going to use GGPO for rollback netcode. I understand the need for a deterministic engine whose state can be saved, restored, advanced from user inputs, etc. I understand that I may need to do this several times in a frame, and that therefore, from a performance point of view, updating the game engine needs to be fast enough to be called more than once in a frame.

My question is.... how many updates in a frame do I realistically need to budget for? If I can identify a realistic worst case, I'll simply run my game engine that many times a frame while I'm developing it.

  • \$\begingroup\$ How many times in a frame do you query for new inputs from the network? \$\endgroup\$
    – DMGregory
    Commented May 5, 2021 at 13:13
  • \$\begingroup\$ Well, I don't - GGPO is handling things at that level. \$\endgroup\$
    – Tom Davies
    Commented May 5, 2021 at 13:41
  • 1
    \$\begingroup\$ re. your recently deleted question, I was writing answer to - look into "Hungarian Algorithm". Given two sets of coordinates it will calculate best pairs (with minimal net length). \$\endgroup\$
    – Kromster
    Commented May 12, 2021 at 11:05
  • \$\begingroup\$ Aha! Thanks. Yes, my search took me there as well, eventually. I decided to delete the question as it's more of a CS/Maths issue, and framing it in its context of controlling AI agents was confusing the fundamental issue. I found this too: cs.stackexchange.com/questions/2082/… It's a great example of a problem that seems intuitively easy to a human but is actually quite tricky (and expensive) to solve \$\endgroup\$
    – Tom Davies
    Commented May 12, 2021 at 11:37

2 Answers 2


Your assumption that you can find a realistic worst case is correct, but you need concrete connection data to know with certainty. Without concrete data, lets approximate one. Caveat: It's been years since I've done GGPO, might be wrong.

NetCode Vars:

  • Simulation rate: 60hz (16.67ms)
  • Forced, always-on input latency: 3 frames (~50ms)
  • Sending 4 previous inputs per packet.
  • Assuming no other input buffering on client/server.

Estimated Worst-Case Network:

  • Worst playable ping: 300±50ms = 350ms (175ms each way)
  • Assume "1 dropped packet" as a common occurrence.
  • Assume "2 or more dropped packets" as rare enough to be excluded.
  • I.e. If we drop 2 packets in a row, we'll probably drop for an extended period of time (1s or more), which will always max out simulation frames during catch-up.

"Catch-up" pro tips:

  • Turn off prediction (and even rendering) during this catch-up as the game is unplayable anyway. If you're already catching up 20 frames in a single frame, adding another 20 for prediction is obviously silly.
  • Rate-limit catch up too to ensure frame rate is stable.

Worst delta between our predicted vs verified state:

  • SUB 3 frames (-50ms) for forced input latency. Nice.
  • ADD 0 to 16ms for input registering.
  • ADD 175ms for attackers input packet delay to server.
  • ADD 1 frame for a dropped packet (which, as assumed, is common).
  • ADD 0 to 16ms for server packet processing.
  • ADD 175ms for victims packet delay from server.
  • ADD 0 to 16ms for packet processing, then triggering rollback.

Total: 350ms

= ~22 frames worst case = Realistically jumping around from 12 to 22 frames almost randomly.

Essentially the 3 frames of forced input latency cancels out the 3 processing times, leaving only the ping + jitter.

22 is obviously a lot, so you can reduce it via:

  • Lower the worst allowed ping. 350ms is extremely bad these days. I.e. Most connections should be far better than this, especially if we've got per-region game servers. You'll need to gather data on this and see what % of the player-base you're excluding by lowering this cap.
  • Increase forced input latency, especially in these cases. E.g. 6 frames (100ms) on connections this poor. Keep this as stable as possible.
  • Lower simulation tick rate.

Side Note on "Forced Input Latency"

It's OP. Because it's fixed, it's consistent, so it just feels like part of the game. Players get used to it much more than a variable latency. Also, it means that on fantastic connections, you predict 0 frames on average. I.e. Both players see exactly the same thing.


I haven't used GGPO but reading through the documentation, it looks like you would just use the amount of updates that your engine needs. I think that's 1 per frame. Looking at the diagram:


It looks like the prediction serves as the remote update for the most part. You would track player input locally, update with predictions, validate with real remote data, rollback when appropriate.

From the docs:

GGPO checks the quality of its prediction for previous frames every time it receives a remote input. As mentioned earlier, GGPO doesn't receive the inputs for player 2's first frame until player 1's fourth. At frame 4, GGPO notices that the inputs received from the network do not match the predicted inputs sent earlier. To resynchronize the two games, GGPO needs to undo the damage caused by running the game with incorrect inputs for 3 frames. It does this by asking the game engine to go back in time to a frame before the erroneously speculated inputs were sent (i.e. to "rollback" to a previous state). Once the previous state has been restored, GGPO asks the engine to move forward one frame at a time with the corrected input stream. These frames are shown in light blue. Your game engine should advance through these frames as quickly as possible with no visible effect to the user. For example, your video renderer should not draw these frames to the screen. Your audio renderer should ideally continue to generate audio, but it should not be rendered until after the rollback, at which point samples should start playing n frames in, where n is the current frame minus the frame where the sample was generated. Once your engine reaches the frame it was on before GGPO discovered the error, GGPO drops out of rollback mode and allows the game to proceed as normal. Frames 5 and 6 in the diagram show what happens when GGPO predicts correctly. Since the game state is correct, there's no reason to rollback.

I would see no reason to update more than once per frame, every frame.

  • \$\begingroup\$ In the situation described above, GGPO tells your game to rollback to its state 3 frames ago, then sequentially apply the corrected 3 frames' worth of input. So in that case, you need to be able to complete a rollback, and 3 engine updates within one frame. \$\endgroup\$
    – Tom Davies
    Commented May 5, 2021 at 17:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .