The game predicts the opponent’s input and shows it early, then rewinds and recomputes if the guess was wrong. The higher the ping, the further it rewinds.
Why The opponent changes their input (different from the prediction) → Effect The real input arrives half a ping late, so the game rewinds that far and recomputes → On screen The opponent’s animation skips a few frames or changes suddenly
Mix in 1–3 frames of input delay to shorten rollbacks, cap the rollback length.
Ballpark numbers
At 100 ms ping (50 ms one way), that’s about 3 frames of rollback at 60 FPS. With 2 frames of input delay, it drops to 1 frame.
On the graph
Random spikes · Frames rolled back, RTT (ping)
Where to look
Client log of the frame count for each rollback, the RTT at that time, the input delay setting, and the time spent rolling back and recomputing
Confirmed if
Rollback frame count is large at the moments the opponent’s animation jumped, and the average rollback is roughly (one-way latency − input delay) ÷ frame time, growing with ping
Ruled out if
Stutter even with short rollbacks: a performance problem where recomputation takes longer than one frame. Results still differ between the two screens after rollback: a desync
Check with
Game server or client logs and metrics
Sources
GGPO Rollback Networking SDKGGPO The game predicts the opponent’s input and moves ahead; if the real input differs, it recomputes from the point where they diverged up to the present