---

title: "Rollback Netcode vs. Client-Side Prediction: Choosing the Right Architecture"
description: "Compare rollback netcode, client-side prediction, and hybrid networking architectures using CPU, memory, bandwidth, determinism, and scale."

Rollback Netcode vs. Client-Side Prediction: Choosing the Right Architecture

A two-player fighting game feels awful when a punch lands 80 milliseconds late. A large shooter feels worse when one correction stalls hundreds of simulated entities. Both games need responsive networking, but they can’t afford the same solution.

Rollback netcode usually wins when the simulation is small, deterministic, and sensitive to frame timing. Conventional client-side prediction is a better fit for large worlds, complex physics, and server-owned outcomes. The decision comes down to measurable constraints: resimulation cost, prediction depth, snapshot memory, correction frequency, and entity count.

Key takeaways

• Rollback is strongest in compact, deterministic simulations where remote input must feel immediate.
• Client-side prediction scales more easily when the server owns a large or complex world.
• A hybrid design can roll back competitive combat while predicting local movement and interpolating everything else.
• Measure p95 and p99 behavior under loss and jitter. Average latency alone tells you very little.

Rollback and prediction solve different problems

The terminology is confusing because rollback also predicts. The difference is what gets replayed and corrected.

With conventional client-side prediction, the local client applies its own input immediately and sends that input to the authoritative server. When the server responds, the client compares the confirmed state with its current state, rewinds if necessary, and replays unacknowledged local inputs.

Read local input
      ↓
Predict local movement
      ↓
Send input to server
      ↓
Receive authoritative state
      ↓
Correct and replay local history

This model is common in server-authoritative action games. The local player stays responsive, while remote players are usually interpolated between server snapshots.

Rollback takes a broader approach. The client simulates the shared game using the inputs it has, predicts missing remote input, and later rewinds the relevant simulation when the real input arrives.

Simulate with known and predicted inputs
      ↓
Late remote input arrives
      ↓
Restore historical state
      ↓
Insert actual input
      ↓
Resimulate to the present

A correction can therefore involve remote players, collision checks, projectiles, timers, hit reactions, and gameplay events—not just the local character.

At 60 Hz, each simulation tick lasts 16.67 milliseconds. Four ticks represent about 67 milliseconds of speculative history; eight ticks represent about 133 milliseconds. Those numbers describe the simulation timeline, not necessarily one visible render frame. A client may process several simulation ticks during a render frame, or spread catch-up work across multiple frames if the engine permits it.

When input arrives late, the system’s response is project-specific. It may keep a longer history, delay presentation, continue with predicted input, or apply a fallback policy. “Dropped” input is not an inherent property of rollback, and neither is extrapolation.

The real rollback budget

Rollback performance has four interacting costs:

• Prediction horizon: how many unconfirmed ticks are in flight.
• Correction frequency: how often predicted input differs from actual input.
• Resimulation cost: how expensive one simulation tick is.
• Historical state: how much memory is required for snapshots and input history.

A useful estimate is:

Resimulation work = corrected simulation ticks × cost per simulation tick

If one tick costs 0.8 milliseconds and a correction requires six ticks, the replay work is roughly 4.8 milliseconds. That cost might fit comfortably on a fast desktop and cause a visible spike on a console or mobile device. Profile the tail, not only the average: a clean average can hide an ugly p99 correction.

The distinction between simulation and rendering matters here. A six-tick replay may happen inside one render frame, producing a large frame-time spike. Or the engine may run at a lower simulation rate, process the correction over several render frames, or have enough idle time to absorb it. Report both simulation-tick cost and render-frame impact.

Snapshot memory and determinism

Rollback needs historical state that can be restored exactly. A rough estimate is:

Snapshot memory = snapshot size × history length × rollback domains

A 64 KiB snapshot stored for 120 ticks requires about 7.5 MiB for one rollback domain. That excludes input history, allocator overhead, compression buffers, server copies, and multiple simultaneous matches.

Store state that affects future gameplay:

Tick number
Entity identity and lifecycle
Position, orientation, and velocity
Movement and collision state
Health, timers, and cooldowns
Gameplay flags
Random-number-generator state
Event sequence counters

Camera smoothing, particle internals, audio playback, and other presentation-only details generally belong outside the snapshot.

Determinism is broader than choosing fixed-point positions. Unordered iteration, thread races, platform-specific math, inconsistent collision tie-breaking, and duplicated event side effects can all produce divergence. Treat the simulation as a defined function:

state[t + 1] = Simulate(state[t], inputs[t])

The update order, random seeds, entity creation, collision resolution, and gameplay events all need stable rules.

Bandwidth

Rollback often exchanges compact input commands instead of complete world snapshots. That can be efficient in a two-player game, but the result depends on topology, redundancy, packet aggregation, encryption, correction messages, and player count.

A simple estimate is:

Input bandwidth = input payload × tick rate + packet overhead

An 8-byte command sent 60 times per second is only 480 bytes per second before headers. Grouping two ticks per packet and adding 30 bytes of overhead raises the effective application rate to roughly 1,020 bytes per second.

At higher player counts, every participant may need overlapping input or state information. A server-authoritative rollback design may also send snapshots and corrections, reducing the apparent advantage of input-only networking.

Rollback, prediction, or a hybrid?

A hybrid design might look like this:

Local locomotion              → client prediction
Nearby combat and hitboxes    → deterministic rollback
Large world and AI            → authoritative server
Distant players               → interpolation
Hit validation                → server authority

For example, a combat island could include player movement, melee volumes, projectiles, and cooldowns. Distant AI, cosmetic objects, and background physics would remain outside the rollback domain. This often delivers the important feel improvements without forcing the whole world to become deterministic.

A benchmark with enough context to mean something

The following Fortress Rollback results come from an illustrative test harness, not a published commercial project. They show how network conditions and player count can affect rollback behavior; they are not universal limits.

The harness ran a deterministic simulation at 60 ticks per second for 10 minutes per scenario. It used UDP input packets with redundant recent inputs, a 32-byte application-level input record, and measured application payload only—IP and UDP headers were excluded. Network delay, jitter, and loss were emulated between clients and a relay server. Tests ran on a Ryzen 7 5800X desktop with 16 GB of RAM; the figures are intended for comparison within the harness, not as hardware-independent performance claims.

The table exposes two practical issues. Loss and jitter can make corrections frequent even when they remain shallow. Four-tick corrections may be cheap individually but still disturb animation and hit feedback if they happen every few frames.

Player count changes bandwidth much more dramatically than it changes rollback depth. The 16-player case has a lower p99 depth than the mobile case but consumes far more traffic because more participants need related input or state information.

Track rollback frequency, p50/p95/p99 depth, resimulated ticks per second, p95/p99 resimulation CPU, visible correction count, snapshot memory, bandwidth, and checksum mismatches. “Average rollback depth” by itself is a poor player-experience metric.

The NetherRealm GDC material on Mortal Kombat XL and Injustice 2 described optimizations capable of rolling back and simulating up to eight game frames within a 16-millisecond budget. That is an example from a tightly controlled fighting-game implementation, not a general limit for 3D games.

Unity’s Netcode for Entities documentation gives a different example: under a 300-millisecond connection, a prediction loop may resimulate around 22 frames during one rendered frame. That figure depends on tick rate, snapshot timing, and implementation. It shouldn’t be compared directly with the NetherRealm number, but it illustrates how quickly burst work grows with latency.

Choosing an architecture

Use rollback when the game has a small competitive simulation and its identity depends on frame-accurate interaction. Fighting games and compact arena combat are obvious candidates. They typically have controlled physics, limited active entities, and players who notice a one-frame delay immediately.

Choose client-side prediction when the server must validate a large, persistent, or physically complex world. Shooters, survival games, MMOs, and physics-heavy co-op titles commonly fit this pattern. The client can move responsively while the server remains authoritative for hits, inventory, movement legality, and anti-cheat checks.

Before committing, test both approaches at 60 Hz across realistic conditions:

RTT:         0, 20, 50, 80, 120, 200, 300 ms
Jitter:      0, 5, 20, 50 ms
Packet loss: 0%, 1%, 3%, 5%, 10%, 15%
Players:     2, 4, 8, 16

Set go/no-go thresholds for p99 frame time, correction visibility, memory, bandwidth, and desynchronization. Run the tests on target console, mobile, and low-end PC hardware—not only on a developer workstation.

The most reliable rule is also the least glamorous: roll back the smallest simulation that needs it. If combat requires frame precision but the rest of the world does not, keep rollback inside combat. Let prediction and interpolation handle everything else.

Frequently asked questions

How much CPU does rollback use?

There is no fixed answer. Cost depends on simulation time per tick, correction depth, correction frequency, and entity count. Estimate corrected ticks multiplied by tick cost, then validate the estimate with p95 and p99 frame-time measurements.

How many frames can rollback resimulate?

Some compact fighting-game systems report eight frames within a 16-millisecond budget. Unity’s documentation describes roughly 22 prediction frames in one rendered frame under a 300-millisecond connection. These are implementation-specific examples, not interchangeable limits.

Does rollback use more bandwidth than client prediction?

Not necessarily. Two-player rollback can be very economical when it exchanges compact inputs. At higher player counts, redundant input exchange, server corrections, and topology can make it considerably more expensive.

When is rollback not worth it?

Rollback is usually a poor fit for a large non-deterministic simulation with many active entities and strict server ownership. In that situation, client prediction and reconciliation—or a hybrid that rolls back only competitive combat—usually offers the better production trade-off.