Rollback or Delay-Based Netcode: Which Fits Your Game?

When choosing a netcode model, you are weighing immediate input response against simpler simulation and lower engineering cost. Rollback and delay-based netcode are often discussed through fighting games and indie multiplayer, but those examples assume particular player counts, input models, and latency limits. Evaluate what each method does first, then check whether that context matches your genre.

How Delay-Based Netcode Works

Delay-based netcode is the easier model to describe. When latencies differ, it adds artificial input delay to the lower-latency player so both inputs are handled on the same tick. If Player A is at 10ms and Player B is at 80ms, Player A's inputs receive several frames of delay, keeping the simulation synchronized without prediction.

Its benefit is simplicity. The simulation runs once with every input present, and each client receives the same state. Nothing needs to be predicted, rewound, or resimulated. The cost is noticeable delay for everyone, including the player with the stronger connection. Where input latency drives competition, the experience suffers in proportion to the match's worst connection.

Delay-based is a good fit when every player's latency stays low, responsiveness does not define the game's feel, and rollback's implementation cost is not warranted by the competitive needs. It suits co-operative games, turn-based games with fast turns, and multiplayer where input-to-result feedback is not the central part of play.

How Rollback Netcode Works

Rollback addresses network input latency differently. Rather than wait for every input, the client immediately simulates ahead using predicted inputs from remote players. Once the real inputs arrive, if they differ, the client returns to the last confirmed state and simulates forward again with those inputs.

The local player's controls feel immediate: pressing a button makes the character respond in the same frame. The screen shows the local simulation's current prediction rather than a delayed synchronized state. A correction can cause a short resimulation and visible stutter when it is large, but small corrections from nearby latencies have little visual effect.

Rollback costs more computation than delay-based netcode because corrections can require multiple simulation runs per frame. The concern grows with expensive physics or large player counts. Two-player fighting games suit rollback: player count is low, physics are bounded, and input latency matters greatly. Using it for a 32-player battle royale adds resimulation complexity that most indie teams cannot take on without significant engineering investment.

The Input Model Limitation

Rollback depends on a simulation that can be replayed deterministically from any earlier state. Given the same state at tick N and the same inputs from tick N through tick N+K, it must reach exactly the same state at tick N+K every time. Non-determinism, platform-specific floating-point divergence, unseeded random number generation, or entity-collection operations whose order matters can make corrections diverge. That creates bugs harder to debug than delay artifacts.

This is rollback's hidden engineering bill, often missed in fighting game discussions. Determinism is much easier in a 2D fighting game than in a 3D open-world game using complex physics. With a physics engine you did not write, its determinism guarantees are outside your control. Platform-native floating-point math can also produce different hardware results. Rollback means auditing and correcting each issue.

Player Count and the Practical Ceiling

Rollback scales with player count because every correction resimulates the complete game state using all players' inputs since that point. In a 2-player game, a 5-frame rollback runs 10 player-frames again. In a 16-player game, it runs 80 player-frames again. Eventually, rollback's per-frame computation becomes too expensive for consumer hardware.

The ceiling depends on game complexity, but production rollback systems commonly begin degrading above 4 to 8 players when the simulation is non-trivial. Past that point, hybrid designs are common: predict the local player's input with rollback, while using authoritative server state instead of full peer resimulation for the wider world.

Choosing for Your Game

Our netcode architecture discussions with studios start with three questions. First, how many players share a session? Above 8 players, rollback needs a deliberate engineering case. Second, how strongly does input shape the game's feel? A platformer where jump timing matters needs less input latency than a strategy game with a 2 to 5 second feedback loop. Third, is the simulation deterministic, and what work would making it deterministic require?

If the answers are more than 8 players, moderate input sensitivity, and a simulation that is not yet deterministic, delay-based is probably the better starting point. If they are 2 to 4 players, extremely input-sensitive play, and a simulation that can become deterministic with reasonable effort, rollback merits the investment.

We are not claiming either model is always superior. Both have shipped hundreds of well-received titles. Fighting games favor rollback because their constraints are specific: 2 players, extreme input sensitivity, and relatively simple simulations that developers can control. Bringing that preference to a 20-player co-op shooter means choosing architecture for the wrong reasons.

Tashi's adaptive netcode layer uses a hybrid model: client-side prediction plus server-authoritative correction. This keeps most of rollback's responsiveness while staying manageable at higher player counts. For 2 to 4 player titles with high input sensitivity, we also support full rollback configurations. Your netcode profile configuration determines the choice, not the infrastructure stack.