Rollback netcode is the single most important technical advance in fighting games over the last decade. It is also one of the most misunderstood. Players feel it as “smooth online play” or, when it breaks, as teleporting characters and dropped combos. Behind those symptoms is a prediction-and-correction loop that trades visual smoothness for input integrity — and it has hard limits when the network underneath stops cooperating.

This explainer covers how rollback works at the frame level, how it differs from delay-based netcode, why Street Fighter 6 and Tekken 8 still suffer under packet loss, and what the fighting game community has learned about tuning the system in 2026.

What it covers: How rollback works at the frame level, why it beats delay-based netcode, and where its hard limits bite. Why it matters: Rollback trades visual smoothness for input integrity — its failure symptoms are predictable and often are not the netcode’s fault. Who should pick this: Online players diagnosing teleporting matches, and organizers tuning tournament setups.

How fighting games run — and why networking them is brutal

Fighting games are deterministic simulations that run at a fixed 60 Hz timestep. Each frame, the engine reads both players’ inputs, advances the game state by one tick, and renders the result. Locally, this is trivial: both inputs are available the same frame they’re needed.

Online, the problem is the speed of light. A round-trip between two players on opposite coasts of the US is roughly 60-80 ms; transatlantic is worse. At 60 FPSframerate. How many images (frames) the game shows per second; higher = smoother motion. 60 fps is a common target., one frame is 16.67 ms. That means by the time Player B’s input for frame 5 arrives at Player A’s machine, Player A has already simulated frames 5, 6, 7, and possibly 8 — using a guess for what Player B pressed.

The central tension: fighting games demand frame-perfect determinism, but the internet delivers information late and out of order. Every netcode strategy is a different answer to the question “what do we do when we don’t yet know what the opponent did?”

Delay-based netcode: the old answer

Delay-based netcode solves the late-arrival problem by waiting. Both clients add a fixed number of artificial input-delay frames — typically 2 to 6 — before feeding local inputs into the simulation. That buffer gives the opponent’s packet time to arrive so both machines can simulate the same frame with the same inputs.

The upside is simplicity: no prediction, no rollback, no resimulation. Both clients always agree on the game state because they never simulate a frame until both inputs are confirmed present.

The downside is that input delay is cumulative with latency. On a good connection you might run 2 frames of delay and feel responsive. On a bad one, the engine bumps delay to 5 or 6 frames to keep the simulation in lockstep, and your character feels like it’s moving through mud. Worse, many older implementations fixed the delay at launch and never adjusted it — so a spiky connection produced stutter rather than graceful degradation.

Delay-based netcode dominated fighting games from the arcade era through the mid-2010s. It is the reason “online play” was a punchline in the competitive scene for a decade.

Rollback netcode: predict, then correct

Rollback netcode inverts the contract. Instead of waiting for both inputs, the client simulates forward on prediction. When Player A presses a button on frame 5, the engine assumes Player B’s input for frame 5 is the same as frame 4 (or whatever prediction heuristic it uses) and advances the simulation immediately. No artificial delay. Your character responds the instant you press.

Then, when Player B’s actual frame-5 input arrives a few frames later, the engine checks: was my prediction right?

  • If yes: nothing happens. The predicted state is already correct.
  • If no: the engine rolls back the game state to frame 5, replays the simulation forward using the real inputs, and renders the corrected result. This rollback-and-resimulation happens in the gap between rendered frames, ideally fast enough that the player never sees it.

The “rollback” you see as a player — a character snapping to a different position — is the visible artifact of this correction when the prediction was wrong and the resimulated state differs noticeably from the predicted one.

The prediction loop in detail

A rollback implementation maintains:

  1. A circular buffer of game states going back N frames (the rollback window, typically 6-12 frames).
  2. A buffer of both players’ confirmed inputs, with predicted (placeholder) entries for inputs that haven’t arrived yet.
  3. A fast save/restore mechanism so the engine can snapshot state and resimulate from any frame in the window.

Each frame, the local client:

  • Reads local input.
  • Fills any missing remote inputs with a prediction (usually “same as last frame”).
  • Advances the simulation one tick and renders.
  • Checks for newly arrived remote inputs; if any differ from the prediction, it restores the oldest affected state and resimulates forward to the current frame.

The key engineering constraint: resimulation must be fast. If rolling back 8 frames and resimulating takes more than ~16 ms, you blow the frame budget and the game hitches. This is why rollback-friendly engines are built to serialize and restore state cheaply, and why some older games that retrofitted rollback (notably the GGPO-powered re-releases) run fine while others struggle.

GGPO and the open-source lineage

The reference implementation is GGPO (Good Game Peace Out), created by Tony Cannon and released in 2009. GGPO popularized the rollback model and proved it viable for fighting games. Its design — state sync, input prediction, rollback window — became the template. Capcom, SNK, Arc System Works, and others have either licensed GGPO-derived code or built in-house implementations following the same architecture.

Important nuance: “rollback netcode” is an architecture, not a single library. Street Fighter 6, Tekken 8, Guilty Gear -Strive-, and Mortal Kombat all use rollback, but each implementation is bespoke to its engine. Quality varies substantially based on how well the host engine supports fast state save/restore and how aggressively the developers tune the rollback window.

Why rollback feels better — and where it breaks

Rollback’s core win is input integrity: your local inputs are never delayed to compensate for the opponent’s latency. Your combo timing matches offline. This is why top players, who measure success in single frames, generally prefer rollback over delay-based — even on mediocre connections.

But rollback has a failure mode that delay-based doesn’t: bad prediction under packet loss.

Latency vs. packet loss — the critical distinction

Rollback handles consistent latency well. If the opponent’s packets arrive reliably but 80 ms late, the rollback window simply extends to cover the late frames, and resimulation only triggers when the opponent does something unexpected (prediction miss). The visual result is smooth, with occasional micro-corrections.

Packet loss is different. When packets are dropped, the client stops receiving confirmation of what the opponent did. Every frame of lost input is a frame where prediction must stand in for truth — and the longer the gap, the more frames the engine must eventually roll back and resimulate when the missing data finally arrives (or times out). With sustained packet loss:

  • The rollback window fills with unconfirmed predictions.
  • Corrections arrive in bursts, producing visible teleporting.
  • The resimulation cost spikes (correcting 10+ frames at once), risking frame drops.
  • In severe cases the clients desync — their states diverge enough that rollback can no longer reconcile them, and the match must be paused or terminated.

This is the scenario the title references: Street Fighter 6 and Tekken 8 both ship solid rollback implementations that play smoothly on stable connections, but neither is immune to the physics of packet loss. When 5-10% of packets drop over a sustained window, the prediction model degrades and the match becomes unplayable regardless of how good the netcode is. No client-side algorithm can recover inputs that the network never delivered.

Desync mechanics

True desync in a rollback system happens when the two clients’ states have diverged beyond the rollback window’s ability to reconcile. Concretely:

  • Client A has simulated up to frame 30 using a prediction for B’s frame-20 input.
  • Client B’s frame-20 packet is lost entirely and never retransmitted (UDP, no recovery layer).
  • Client B simulates frame 20 with its real local input; Client A simulated it with a prediction.
  • If the divergence is within the rollback window, A corrects on receipt of a later input. If the window has already scrolled past frame 20, A’s state is permanently wrong relative to B’s.

Most production rollback stacks add a reliability layer (input acknowledgment, occasional full-state sync) to bound this risk, but under heavy loss the correction traffic itself can lag, extending the divergence window. The result is the classic “rollback storm” — rapid, large corrections that make the match unplayable.

Rollback in Street Fighter 6 and Tekken 8

Street Fighter 6

Capcom built a custom rollback implementation for SF6 rather than shipping GGPO directly. The system launched with rollback at release and has been iterated on via patches. Community consensus is that SF6’s netcode is strong on stable connections — matches within a region feel close to offline — but exhibits the standard rollback failure pattern under packet loss and on intercontinental routes where the latency window stretches the prediction horizon. Capcom has not published detailed netcode documentation, so community testing remains the primary source on its behavior.

SF6 exposes limited netcode tuning to players. The matchmaker prioritizes connection quality, and there is no user-facing rollback-window or delay-frame adjustment, which means players cannot manually compensate for a bad route — they can only reject the match.

Tekken 8

Tekken 8 launched with rollback netcode — a meaningful shift for the Tekken series, whose prior online implementations were delay-based and widely criticized. Bandai Namco’s implementation has been praised for feel on good connections but has drawn community complaints about consistency under variable network conditions, particularly on cross-region matches and routes with lossy ISPs. As with other titles, official netcode patch detail is sparse and community reporting fills most of the gap.

A persistent issue across both titles: Wi-Fi players. Rollback assumes a relatively stable packet delivery rate. Consumer Wi-Fi — especially 2.4 GHz or congested 5 GHz — introduces intermittent packet loss and jitter that hits rollback far harder than it hits delay-based netcode. Both SF6 and Tekken 8 now display connection type (wired vs wireless) in matchmaking, a direct response to this problem, though neither forces wired-only lobbies.

Rollback vs. delay-based: a comparison

DimensionDelay-basedRollback
Local input feelArtificially delayed (2-6 frames)Immediate, matches offline
Behavior under stable latencySluggish but consistentSmooth, occasional micro-corrections
Behavior under packet lossInput delay increases; may stutterPrediction misses accumulate; teleporting, possible desync
Frame budget cost per frameLow (no resimulation)Higher (resimulation on correction)
Implementation complexityLowHigh (state save/restore, prediction, sync)
Engine requirementsMinimalFast deterministic state serialization
Community preference (2026)Legacy / fallbackDefault for competitive fighters

The practical takeaway: rollback wins on the dimension that matters most to competitive play — local input fidelity — and loses on the dimension that matters most to casual play on bad connections — graceful degradation under loss. Most modern fighters accept this trade because the competitive scene drives netcode expectations, and rollback is what that scene demands.

Tuning the rollback window

The single most important configuration parameter in a rollback stack is the rollback window size — how many frames of history the engine keeps for potential resimulation. A larger window tolerates more latency (it can correct inputs that arrive later) at the cost of higher peak resimulation cost and more memory. A smaller window is cheaper but breaks sooner on high-latency routes.

Production implementations typically set this dynamically based on measured round-trip time, with a floor and ceiling. The trade-off:

  • Too small: corrections can’t reach back far enough; late inputs are dropped or force a desync.
  • Too large: a single bad prediction triggers a long resimulation that may exceed the frame budget, causing a visible hitch even on otherwise smooth play.

Arc System Works titles (Guilty Gear -Strive-, Granblue Fantasy Versus: Rising) have been noted for relatively conservative window tuning that favors visual smoothness over maximum latency tolerance. Capcom and Bandai Namco implementations lean toward larger windows to extend the playable latency range, accepting more frequent corrections as the cost.

What still needs solving in 2026

Rollback is mature, but the open problems are real:

  1. Packet loss recovery. No rollback stack has a clean answer for sustained loss. The standard response is to extend the prediction window and hope the loss is transient; under persistent loss the match degrades regardless. Reliable-transport overlays (retransmitting dropped inputs) help but add latency to the correction path, partially defeating rollback’s responsiveness advantage.

  2. Cross-region play. Intercontinental latency of 150+ ms pushes the rollback window to 9+ frames, making prediction misses visually severe. Most competitive scenes still enforce regional lobbies. There is no netcode fix for the speed of light.

  3. Wi-Fi and mobile networks. As long as a meaningful fraction of the player base connects over lossy wireless, rollback’s worst case will be a common experience. Wired-only lobbies are a community norm, not a platform-enforced rule.

  4. State sync cost. Engines not designed for rollback from the start pay a constant resimulation tax. Retrofits (older titles patched to rollback) often run fine but can struggle on lower-end hardware where the frame budget for resimulation is tight.

The next frontier is hybrid approaches — rollback for the fast path, with periodic full-state checksums and selective reliable retransmission for the correction path — but no shipped fighting game has yet demonstrated a system that eliminates the packet-loss failure mode. Until the underlying transport problem is solved, “good rollback” will remain a story about stable connections, and the desync-under-loss problem will remain the genre’s unsolved networking question.

Sources & further reading

Next read