In competitive fighting games—such as Street Fighter 6, Tekken 8, Guilty Gear -Strive-, and 2XKO—gameplay logic is locked to a deterministic 60 frames per second (`16.67 milliseconds per frame`). Every attack has fixed startup, active, and recovery frames. When you block an opponent's move that is `-6 frames on block` and punish with a `6-frame medium punch`, a single frame of network hesitation turns a guaranteed combo into a whiffed input.
For years, online fighting games relied on Delay-Based Netcode, which forced both players to wait for each other's inputs to cross the internet before advancing the game clock. Today, Rollback Netcode (pioneered by Tony Cannon's GGPO—Good Game Peace Out—middleware) is the mandatory gold standard. Here is the exact computer science that makes it work.
Title: Delay-Based vs. Rollback Netcode Architecture
Badge: Network Engineering
- Delay-Based Flaw: If ping fluctuates from 40ms to 95ms mid-combo, the game dynamically changes your local input delay from 2 frames to 6 frames—shattering muscle memory.
- Rollback Core Principle: Your local button presses execute with constant, deterministic delay (0 to 1 frame), regardless of whether your opponent is 15 miles or 2,500 miles away.
- Input Prediction Accuracy: Because human players hold directional inputs or stay in attack animations for multiple frames at a time, repeating the opponent's previous frame input (`Input[t] = Input[t - 1]`) is correct ~92% to 95% of the time!
How Deterministic State Rollback Rewinds Time in Under 2 Milliseconds
Unlike an open-world shooter with 100 players, a 1v1 fighting game can be engineered as a 100% deterministic finite state machine: given the exact same starting state and the exact same two controller bitmasks on Frame `N`, both consoles/PCs are mathematically guaranteed to compute the exact same Frame `N + 1`.
When Player A and Player B play with a 66ms round-trip ping (2 frames of one-way transit):
1. Frame 100 (Local Execution): Player A presses Heavy Kick. Instead of waiting 33ms to learn what Player B pressed on Frame 100, Player A's client immediately renders Frame 100 assuming Player B simply continued holding the same buttons they held on Frame 99.
2. Frame 102 (Packet Arrival): Two frames later, Player B's actual Frame 100 input packet arrives over UDP.
3. Case A — Prediction Was Correct (~93% of frames): Player B really did keep holding down-back on Frame 100. Nothing needs to change! Both players just experienced zero-latency local gameplay across the internet.
4. Case B — Prediction Was Wrong (The Rollback): Suppose Player B actually pressed Light Punch on Frame 100. Within a single `16.67ms` render interval, Player A's CPU silently:
- Restores the saved memory snapshot from Frame 100;
- Applies Player B's real Frame 100 input and re-simulates logic for Frame 101 and Frame 102 with rendering disabled (taking less than `1.5ms` of CPU time);
- Draws the corrected Frame 102 to the screen.
Why the First 2 Startup Frames Hide Visual Rollback
Because every fighting game attack has startup animation frames before its hitbox becomes active (typically 4 to 12 frames), rolling back 2 frames simply skips the very first 33 milliseconds of the opponent's wind-up animation. The attack still connects on the exact same historical frame, audio hit-sparks trigger cleanly, and your local combo timing never shifts by a single millisecond. Compare how shooter servers handle latency in our Sub-Tick Netcode & Hit Registration Breakdown.