Rollback Netcode and Ping: Why Fighting Games Feel Different (2026)
Why Fighting Games Play by Different Rules
In most online games, higher ping means a slightly delayed world and worse duels. In a fighting game with rollback netcode, steady ping barely changes how the game feels at all — your inputs execute locally with zero added delay, and the netcode quietly repairs any mismatch afterwards. What rollback cannot hide is inconsistency. Jitter and packet loss turn into visible corrections: characters snapping to new positions, animations restarting, moves appearing to come out of nowhere. That is why a stable 70ms connection is usually a better fighting game experience than a 40ms connection that swings.
Delay-Based Netcode: Waiting for the Opponent
The older approach is straightforward and, for its era, correct. Fighting games are deterministic lockstep simulations: both machines run identical game logic, and given identical inputs they produce identical outcomes. To stay synchronized, both clients must have both players' inputs before advancing a frame.
Since your opponent's input takes half a round-trip to arrive, delay-based netcode solves the problem by making your own input wait too. The game buffers your input for a few frames so that it executes at the same moment the opponent's arrives. Synchronization is preserved perfectly, and the simulation never has to be corrected.
The cost is direct and unavoidable: input delay proportional to ping, applied to everything you do. On a 100ms connection you are playing with roughly three extra frames of delay on every button press, including in neutral, including on wake-up, including on reaction confirms. Combos with tight links become inconsistent. Reaction-based defense becomes guesswork. And when a packet arrives late, the entire game freezes for both players until it turns up — the classic delay-based stutter where both characters simply stop.
Rollback Netcode: Predict, Then Correct
Rollback flips the priority. Instead of delaying your input to stay in sync, it runs the game immediately and fixes desyncs after the fact. The loop looks like this:
- You press a button. The game executes it locally on the very next frame — no added delay, ever.
- The opponent's input for that frame has not arrived yet, so the game predicts it, usually by assuming they continue doing what they were doing.
- The game continues simulating forward on that prediction while saving a snapshot of each recent frame's state.
- The opponent's real input arrives a few frames later. If the prediction was right — which it usually is, because inputs are held for multiple frames far more often than they change — nothing happens at all.
- If the prediction was wrong, the game rolls back to the last known-correct frame, reapplies the true inputs, and resimulates every frame since then in a single video frame. It then draws the corrected present.
The consequence is the defining property of rollback: your own character always responds instantly, at any ping. Your execution, your combo timing, your reaction windows are identical online and offline. What changes with ping is only how far ahead the game has to predict, and therefore how large a correction it may have to draw when it guesses wrong.
Frames and Milliseconds
Fighting games think in frames, not milliseconds. At 60 fps one frame is approximately 16.7ms, and rollback is usually described in frames of prediction. Converting between the two is the key to reading your own ping.
| Ping | Approximate Rollback Frames at 60 fps | What It Feels Like |
|---|---|---|
| 0-16ms | Under 1 frame | Indistinguishable from local play. Rollbacks are essentially never visible. |
| 16-33ms | 1-2 frames | Excellent. Occasional corrections, none of them perceptible in normal play. |
| 33-67ms | 2-4 frames | Very good. This is the realistic target for regional online play. Corrections appear during scrambles but rarely affect outcomes. |
| 67-100ms | 4-6 frames | Playable and competitive if stable. You will see occasional visual snapping when both players change plans at once. |
| 100-150ms | 6-9 frames | Noticeably rough. Frequent visible rollbacks, mispredicted throw techs, and reversals that appear late. |
| 150ms+ | 9+ frames | Prediction breaks down. Heavy teleporting and unreliable interactions in any fast exchange. |
To do the conversion yourself: divide your ping by 16.7 to get the approximate one-way prediction window in frames, remembering that ping is a round-trip figure and implementations differ in how many frames they buffer. It is a rule of thumb, not a specification.
Why Jitter Hurts So Much More Than Ping Here
This is the part that separates fighting games from every other genre. Rollback is engineered to absorb a known, constant delay. A steady 70ms connection means the system always predicts about the same number of frames ahead, and the prediction logic operates in a stable regime.
Jitter destroys that. When arrival times swing, the number of frames the engine must predict changes constantly, and every time an input arrives later than expected the resimulation window grows. The visible result is what players describe as teleporting: a character who was walking forward suddenly appears mid-attack three steps away, because the engine resimulated several frames at once and the corrected outcome differs sharply from what you were shown.
Packet loss is worse still, because a missing input is not late — it is absent. The engine keeps predicting on stale information for as long as the gap lasts, and the eventual correction spans more frames. This is the origin of the most frustrating moment in online fighting games: you blocked, you saw yourself block, and then the game rewrote history and you were hit.
Two connections with an identical 50ms average therefore play completely differently:
| Connection | Average Ping | Jitter | Experience |
|---|---|---|---|
| Wired, quiet network | 70ms | 2ms | Smooth. Predictable rollback depth, corrections rarely visible. Fully competitive. |
| Wi-Fi, busy household | 40ms | 35ms | Choppy. Constant visible teleporting, unreliable blocks and drops. Lower number, worse match. |
This is why the fighting game community has been openly hostile toward wireless play for years, and why lobby etiquette in many titles includes checking whether an opponent is wired. It is not superstition. It is the direct consequence of how rollback works. Our jitter vs ping guide covers the general case; fighting games are simply where the effect is most visible.
Which Games Use Rollback
Rollback originated in the community-made GGPO middleware and has since become the expected standard for new fighting games. Major modern entries in the Street Fighter, Tekken, Guilty Gear, Mortal Kombat and King of Fighters lines have shipped with or added rollback-based netcode, and several older titles received rollback in later updates or community patches. Implementation quality varies significantly between engines, and specific games have changed their netcode across patches — so treat "this series uses rollback" as a general statement rather than a guarantee about any particular version you are running.
Rollback also appears well outside the genre. Several platform fighters, retro-arcade rereleases and some indie multiplayer titles use it, and the same predict-and-resimulate concept underlies client-side prediction in shooters — though shooters apply it to your own character only, rather than resimulating the whole match state.
How to Get the Best Rollback Experience
- Wire the machine. This is not optional. Ethernet removes radio retransmissions, which are the dominant source of jitter in most homes. It is the single largest improvement available to a fighting game player, and it usually matters more than anything else on this list. See Wi-Fi vs Ethernet for gaming.
- Measure jitter, not just ping. Run our browser ping and jitter test several times and watch the variance column. The test measures warm HTTPS round-trip time to nearby cloud endpoints rather than sending packets to a game lobby, so read it as a proxy for path quality — but the method is identical across runs, which makes before-and-after comparison fair. Jitter under 5ms is what you are aiming for.
- Kill background traffic before a session. Cloud sync, game updates, another household member streaming in 4K — all of these queue ahead of your input packets. Enable Smart Queue Management on your router so bulk transfers cannot starve real-time traffic.
- Chase stability over region hopping. If a slightly closer lobby costs you consistency, take the further, steadier one. Rollback rewards predictability far more than raw distance.
- Rule out loss before blaming the game. Persistent teleporting on a wired connection points at packet loss somewhere in the path. Work through how to fix packet loss to isolate whether the fault is in your home, your ISP, or the route.
- Set expectations by distance. Cross-continental matches will show visible rollback no matter what you do — that is physics, not a fault.
The Short Version
Rollback netcode made online fighting games viable by refusing to delay your inputs and repairing desync after the fact instead. The trade it makes is visibility: instead of feeling latency as sluggish controls, you see it as occasional visual corrections. That trade is overwhelmingly worth it, and it means the metric you should optimize is not the lowest possible ping but the steadiest one. Get wired, keep jitter in the low single digits, and a 70ms opponent will feel closer than a 40ms one on Wi-Fi ever does. If you want the general background on what these numbers mean, start with what is ping.