How Rollback Netcode Works in Fighting Games (October 2026)

Rollback netcode keeps your game running at full speed even when your opponent’s inputs are late: it guesses the missing inputs, saves a snapshot of the game each frame, then rewinds a few frames and replays them with the real inputs the moment they arrive. That is how fighting games feel responsive on a 150ms connection instead of freezing. Understanding how rollback netcode works in fighting games is mostly about understanding one idea: prediction plus correction.

The rest of this guide walks through that cycle frame by frame, explains why rollback games still ship with a few frames of input delay, and covers what you can actually do when your matches stutter or roll back constantly.

Table of Contents

1. 1How Rollback Netcode Works in Fighting Games
2. 2Why Fighting-Game Players Need Rollback
3. 3What Happens During a Fighting-Game Rollback?</
4. 4How Rollback Netcode Works in Fighting Games, Step by Step
5. 5What Are Rollback Frames and the Rollback Window?
6. 6How Does Input Prediction Affect Match Outcomes?
7. 7What Happens to Hitboxes, Blocking, and Frame Advantage?
8. 8How Does Rollback Differ from Delay-Based Netcode?
9. 9Why Can Rollback Games Roll Back Too Much?
10. 10How Can Players Tell if Rollback Netcode Is Working Well?
11. 11Does Rollback Make Fighting Games Cheat-Free?
12. 12Frequently Asked Questions
13. 13Does rollback netcode change frame advantage?
14. 14Why do I sometimes roll back more on one side of a fighting game?
15. 15Is a rollback always a sign of cheating?
16. 16How many rollback frames are enough for online fighting games?
17. 17Why does rollback cause stutter even when my internet speed is high?
18. 18Conclusion

How Rollback Netcode Works in Fighting Games

Rollback netcode is an online networking method where each client simulates the opponent’s inputs immediately rather than waiting for them, then rewinds a few frames and re-simulates the match with the correct inputs as soon as they arrive. The game keeps running smoothly at the cost of a small amount of built-in input delay.

Three things have to be true for that trick to work. The simulation has to be deterministic, meaning the same inputs always produce the same result. The whole game state has to be serializable, so it can be written to memory and restored later. And the client has to receive its opponent’s inputs with a frame number attached, so it knows exactly which frame the packet belongs to.

Every rollback system you play today depends on those same three properties, whether it runs on a modern engine or on a library like GGPO bolted onto a decade-old arcade game.

Why Fighting-Game Players Need Rollback

A fighting game runs at 60 frames per second, which means every frame lasts about 16.7 milliseconds. A single frame is the difference between a blocked hit and a clean punish, so any inconsistency between two screens changes the result of an exchange.

Frame data does not tolerate drift. If a move has five frames of startup and your opponent’s game thinks it has six, the same button press produces a different outcome on each screen, and one of you is going to lose a round over a bug rather than over skill.

Delay-based networking handles this by slowing everyone down. It adds a fixed delay, usually a few frames, so both players operate on inputs that arrived in time. The problem is that your inputs also get delayed, and a match that feels crisp at two frames of delay feels sluggish at eight or ten.

On a 150ms connection, roughly nine frames each way, a delay-based game has to hold your inputs long enough to cover the worst case. That is a long, floaty feeling where inputs feel disconnected from what you see on screen. Rollback exists to break that tradeoff between consistency and responsiveness.

Players on high-latency connections report the same thing repeatedly in community threads: a rollback match at 150ms ping is playable, while the same connection running delay-based netcode is not. That difference is why rollback became the expected default in competitive fighting games.

What Happens During a Fighting-Game Rollback?</

A rollback happens whenever the real inputs for a frame show up after the game has already simulated past that frame. Here is the sequence, repeated sixty times a second, under normal conditions.

How Rollback Netcode Works in Fighting Games, Step by Step

1. You press a button. On the current frame, your game records the input, applies it to the simulation, and keeps a copy of the resulting game state in a ring buffer of recent frames.
2. The input goes out. Your game serializes that input with a frame number and sends it over the network. This packet is tiny, often just a few bytes plus overhead.
3. Your game simulates immediately. There is no waiting. The next frame is simulated the instant it starts, using your real input.
4. The opponent’s input is predicted. If their packet for that frame has not arrived yet, the game repeats their previous input and continues simulating. This is the guess.
5. Late packets arrive. Somewhere around a sixth of a second later, the opponent’s real inputs for the earlier frames show up.
6. The state is restored. For each late frame, the game reloads the saved state from that frame, discarding the predicted result.
7. Frames are re-simulated. The game replays every input up to the present frame using the real data instead of the guess, then shows you the corrected result.

Here is a concrete version with numbers. Assume a one-way delay of about 65 milliseconds, which is roughly four frames, and a move with twenty frames of startup.

At frame 100 you throw a heavy attack. Your game saves the state, applies the input, sends it out, and moves on. At frame 104 your opponent’s game receives it — but your game is already four frames past frame 100, simulating with a guess about what they did at frame 100.

Frame 104 on your screen is predicted. If your opponent was actually blocking at frame 100 and your guess said they were not, your screen shows the heavy connecting. When their real packet lands, your game restores the state from frame 100, replays 100 through 104 with the correct inputs, and the heavy whiffs instead. What you watched for four frames was not what happened.

That visual snap is the artifact players complain about most. What it actually represents is the game being honest about a correction it could not avoid.

What Are Rollback Frames and the Rollback Window?

A rollback frame is one simulated frame that gets thrown away and re-simulated. The rollback window is the maximum number of frames a game is allowed to rewind, sometimes called the max rollback or resimulation depth.

Every game picks a number, and the number matters because your ping has to fit inside it. A game with a four-frame window handles up to about 66ms of one-way delay without rolling back at all. With a seven-frame window, the same connection stays prediction-only up to roughly 116ms.

More is not automatically better. A larger window means more saved states in memory and more frames to re-simulate when a correction lands, which costs CPU time during exactly the moment the machine is already busy.

That is why some titles add frames of input delay by default. If a game delays your inputs by three frames and the connection typically takes fewer than three frames each way, no rollback happens at all. Killer Instinct used this approach with a fixed three-frame delay, which covers a round-trip ping up to about 90ms without a single correction.

Community discussion often treats a higher window as a quality setting. It is more accurately a tolerance setting. What matters is whether the window comfortably exceeds your actual delay with room for jitter.

How Does Input Prediction Affect Match Outcomes?

Prediction is the guess step from the list above, and the default method is simple: repeat the opponent’s last known input until the real one arrives.

It works because fighting game inputs are bursty. Players hold directions for stretches, repeat the same button presses during a combo, and idle in neutral. Repeat-last-input is correct the large majority of the time, and once the real inputs arrive the mistake is corrected anyway.

Where it hurts is the gap between prediction and confirmation. A wrong guess can produce a hit that never happened, a whiff that actually connected, or a reversal that looked like it beat an opponent’s attack when the truth is the other way around. This is the hit-confirm flip players describe as the most infuriating rollback artifact, since you get a clear visual confirmation followed by a death.

Your own inputs are never predicted, which is why rollback feels unfair when it does happen. The player who is behind on the connection sees more corrections than the player who is ahead, so a rough match looks rough to exactly one person. Players who changed their input delay setting to zero often do not realise they are handing that side of the match to their opponent.

Iron Galaxy engineers have said that smarter prediction, such as guessing a full motion input, was rejected because it was wrong more often than it was right. The simple method stayed.

What Happens to Hitboxes, Blocking, and Frame Advantage?

Rollback does not change any of it. A move keeps the same startup, the same active frames, the same hitbox, the same recovery, and the same frame advantage whether the match is on a wired 20ms connection or a 150ms one.

The reason is determinism. Re-simulation replays the same rules from the same starting state with the correct inputs, so it reaches the same answer that a delay-based game would have reached had it waited. Rollback changes when the game computes an answer, not what the answer is.

The practical consequence is that matchup knowledge transfers cleanly between offline and online play. A blockstring that works in training works on Wi-Fi in a different region.

The caveat worth knowing: if a game is not fully deterministic, rollback will not fix it. Divergence from a non-deterministic element such as an unseeded random call or a frame-rate-dependent calculation can produce a desync, which is a genuine desynchronisation rather than a normal correction.

How Does Rollback Differ from Delay-Based Netcode?

Factor	Rollback netcode	Delay-based netcode
Input response	Immediate, plus whatever input delay the game sets	Always delayed by the sync buffer
Latency tolerance	High, limited by the rollback window	Low, delay has to grow with ping
Visual behaviour	Occasional snaps, teleports, corrected hits	Consistent, smoothly delayed match
CPU demand	Higher, re-simulation costs frames	Lower, each frame simulated once
Spike behaviour	Harder, a large spike forces many corrections	Forces a freeze or a waiting screen
Main tradeoff	Visual instability and occasional missed reads	Input feels disconnected from the screen

Neither column is wrong. Delay-based gives a stable picture at the cost of sluggish inputs, which is why it survives in genres where the camera and the timing of an engagement matter more than a single frame of advantage.

Hybrid approaches combine the two, and tournaments often add extra delay on top of rollback for large online brackets so that every participant sees a similarly delayed match rather than relying on their own connection.

Why Can Rollback Games Roll Back Too Much?

Occasional rollback is normal. Constant rollback means the corrections are no longer rare events, and the usual causes sit on your side of the connection rather than in the game.

• Wi-Fi. A wireless connection shares airtime with everything else nearby, which produces jitter even when the average speed looks excellent.
• Background uploads. One large upload can fill the pipe for a few seconds and trigger a burst of corrections.
• Packet loss. A dropped packet means a real input arrives late or never, and both force a rollback.
• Frame drops on your side. If your machine misses a frame, the opponent must re-simulate through the gap. This is the classic cause of one player having a great match while the other one suffers.
• A rollback window that is too small. If your delay regularly exceeds the window, you are correcting constantly by design.
• Congestion at peak hours. Local internet traffic and routing paths get busier in the evening.

A 500ms spike is a different animal. The game may have to predict dozens of frames ahead and then correct all of them, which is the scenario community critics cite when they argue that delay-based systems degrade more gracefully.

How Can Players Tell if Rollback Netcode Is Working Well?

Nearly every current fighting game prints network statistics after a match or in a practice overlay. They are worth reading, with one caveat about which side the indicator refers to.

On many titles the rollback indicator shows corrections from the perspective of the player being ahead on the connection. That means the person with worse ping sees the count climb while their opponent sees a clean match. If your matches feel fine but your friend says theirs stutters constantly, check their side before deciding the connection is fine.

A few practical checks, in the order I would run them:

1. Use a wired connection for ranked play, even a basic ethernet cable, and keep the router free of large downloads.
2. Compare the same match on two connections to see whether the problem travels with you or with the opponent.
3. Watch your frame rate during a match, since a machine that cannot hold a stable frame rate causes corrections for the other player.
4. Leave the input delay at the game’s default unless you have a specific reason, because zero delay is a trap for your opponent’s experience, not yours.
5. Check the title’s official netcode settings or support notes before changing anything, since the defaults are usually tuned for a wide range of connections.

If a match genuinely desynchronises rather than merely rolls back, most titles let you save a netplay log. That file is what support teams need to investigate, and it is far more useful than a description of the problem.

Does Rollback Make Fighting Games Cheat-Free?

No. Rollback describes how a network model corrects predictions, and it has nothing to say about what inputs a client sends. A prediction that gets corrected is not evidence of anything except ordinary latency.

The distinction worth drawing is between what the system does to you and what another person does deliberately. A snap-back or a whiffed heavy is the system correcting itself. Lag switching, where a player deliberately manipulates their connection to freeze the opponent during a hit confirm, is a person creating unfair conditions and can affect delay-based games too.

The genuine fairness problems in rollback are mostly about information players cannot see. Settings such as your input delay are typically hidden from the opponent, so a match cannot be judged unfair on netcode grounds from the outside. Community consensus treats hidden netcode settings as a dealbreaker for that reason.

Frequently Asked Questions

Conclusion

Rollback keeps a fighting game at full speed by guessing the opponent’s inputs, saving each frame’s state, and replaying those frames with the real inputs once they arrive. It does not change frame data, and it does not cheat on anyone’s behalf.

If your matches stutter, work through this order: go wired, close anything uploading in the background, hold a steady frame rate, and keep the input delay setting at its default. Then check the title’s official rollback settings or support guidance before changing anything further.