multiplayer game dev
Rollback Netcode: How Fighting Games Solved Online Multiplayer
Back to Multiplay Guide
Netcode11 min read3 frames

Rollback Netcode: How Fighting Games Solved Online Multiplayer

TR
Tomás Reyes
#rollback#fighting games#GGPO#netcode

For decades, fighting games were essentially unplayable online. The genre's core promise (frame-precise combat where a single frame (16.67ms at 60fps) determines whether you block or eat a combo) is fundamentally at odds with network latency. A 100ms ping means six frames of uncertainty. In a game where three-frame moves exist, that's an eternity. Then rollback netcode arrived and changed everything.

The Problem: Delay-Based Netcode

Before rollback, fighting games used delay-based netcode. The concept is simple: wait until you have inputs from both players before advancing the simulation. If your opponent is 80ms away, the game adds 5 frames of input delay to keep both sides synchronized.

This technically works, both players see the same thing at the same time. But it feels terrible. Those 5 frames of input delay mean your character doesn't respond to your button press for ~83ms. For competitive players accustomed to 1-2 frames of native input lag, this makes the game feel underwater. And if the connection degrades, the delay increases dynamically, creating stuttery, inconsistent gameplay.

Delay-based netcode turned competitive fighting games into casual-only experiences online. Serious players refused to play ranked because the input lag made it a fundamentally different game.

Rollback: Predicting the Future

Rollback netcode (pioneered by Tony Cannon's GGPO library) takes a radically different approach. Instead of waiting for the remote player's input, the game predicts it and advances immediately. The local player experiences zero additional input delay.

When the remote player's actual input arrives, the game compares the prediction to reality. If the prediction was correct (which it is ~90% of the time, since players hold directions and repeat actions frequently), nothing happens, the game continues seamlessly.

If the prediction was wrong, the game rolls back to the last confirmed state, applies the correct inputs, and re-simulates forward to the current frame. This all happens in a single frame, the player sees a brief visual correction, but it's usually minor (a character facing a different direction, an attack starting a frame or two late).

// Simplified rollback loop
function gameLoop() {
  // 1. Predict remote player will repeat last input
  const predictedInput = lastKnownRemoteInput;
  
  // 2. Advance simulation with local + predicted input
  simulate(localInput, predictedInput);
  render();
  
  // 3. When actual remote input arrives...
  onRemoteInputReceived(actualInput, frameNumber) {
    if (actualInput !== predictedInputForFrame[frameNumber]) {
      // 4. ROLLBACK, re-simulate from last confirmed state
      restoreState(confirmedState);
      for (let f = confirmedFrame; f <= currentFrame; f++) {
        simulate(savedLocalInputs[f], correctedRemoteInputs[f]);
      }
      render(); // Show corrected state
    }
  }
}

Why Rollback Works So Well

The key insight is that most predictions are correct. In a fighting game, a player holding "forward" will probably still be holding "forward" next frame. A player in the middle of a combo will execute the next move in the sequence. Neutral states (standing, walking) are especially predictable.

When predictions are wrong, the visual corrections are usually subtle. A character might snap into a slightly different position or animation. This is noticeable if you're looking for it, but it's far less disruptive than the constant input lag of delay-based netcode. Players universally prefer occasional rollback artifacts over permanent input delay.

The numbers support this. In a typical match at 80ms ping, delay-based netcode adds 5 frames of constant input delay. Rollback adds 0 frames of input delay and produces visible corrections maybe once every few seconds, usually minor ones. It's not even close.

The Technical Challenges

Implementing rollback is significantly harder than delay-based netcode. You need:

  • Deterministic simulation: Given the same inputs, the game must produce the exact same state. No randomness, no floating-point inconsistencies, no frame-rate-dependent behavior.
  • State serialization: You need to save and restore the entire game state every frame. This includes positions, animations, hitboxes, timers, and all game logic state. It needs to be fast: under 1ms per save/restore.
  • Re-simulation speed: When a rollback occurs, you might need to re-simulate several frames in a single frame's time budget (~16ms). If your simulation takes 4ms per frame, you can handle up to 4 frames of rollback within budget.
  • Input prediction: While "repeat last input" works well for fighting games, other genres might need smarter prediction strategies.

Rollback Beyond Fighting Games

The rollback technique isn't limited to fighting games. Any game that requires low-latency input response can benefit. Rocket League uses rollback-like prediction for car physics. Some racing games use it for tight steering response. Even some action games are adopting rollback principles for their combat systems.

The main requirement is a deterministic, fast simulation that can be serialized and re-simulated quickly. If your game fits that profile, rollback is almost certainly better than delay-based alternatives.

The fighting game community's hard-won knowledge about rollback has become a gift to the entire industry. Every developer building competitive multiplayer experiences should study GGPO's approach, even if they don't use it directly, the principles of prediction, rollback, and reconciliation apply broadly.

The Community Impact

Rollback didn't just fix the technical problem, it transformed the fighting game community. Before rollback, competitive play required being physically present at locals and tournaments. Online was a watered-down experience. After rollback became standard (Guilty Gear Strive, Street Fighter 6, Mortal Kombat 1 all ship with it), online competition became legitimate. Player counts exploded. Scenes that couldn't support local meetups suddenly had thriving online communities.

The lesson for multiplayer developers: good netcode isn't just a technical feature. It's a community feature. The better your online experience feels, the more people will play, compete, and stick around. Netcode quality directly impacts retention, and retention is everything in multiplayer.