Rollback Netcode vs Client Prediction: 2026 Cost Benchmark

Rollback is not automatically the better answer to multiplayer responsiveness. For most PC games, the practical choice is authoritative servers with client prediction, adding rollback only where deterministic replay is affordable and visibly improves play. At launch, the bigger risks are often less glamorous: a 300 ms shader hitch that looks like network lag, or a storefront margin advantage that disappears because fewer players find the game.

Key Takeaways

• Rollback budget: At 60 Hz, 100 ms RTT requires roughly six history frames; at 120 Hz, it requires about twelve, with replay CPU and memory rising alongside the tick rate.
• Shader hitch reality: A 300 ms PSO compilation stall skips 18 frames at 60 FPS and 36 frames at 120 FPS. Players experience that as input delay, regardless of ping.
• Commercial rule: Epic’s 88/12 split after its first $1 million per title can beat Steam’s economics on paper, but Steam’s audience and multiplayer discovery may generate more net revenue.

Rollback Netcode vs Client Prediction: What You’re Actually Paying For

Client prediction and rollback solve related problems, but they spend engineering budget in different places.

With client prediction, the local machine immediately simulates the player’s input instead of waiting for server confirmation. When an authoritative update arrives, the client compares its current state with the server’s state, corrects the discrepancy, and may replay unacknowledged inputs.

Rollback takes that idea further. The game stores recent simulation states, rewinds to an earlier point when late input or authoritative data arrives, then re-simulates the affected frames. That can produce excellent responsiveness, especially in a fighting game or tightly scoped action game. It also assumes the simulation is deterministic enough to replay consistently.

The CPU cost depends less on the word “rollback” than on what must be replayed.

Rollback CPU cost: replayed frames × simulation cost per frame × number of correction events

A small character controller with deterministic hit detection may replay cheaply. A physics-heavy scene with destructible objects, hundreds of actors, animation-driven gameplay, and expensive collision queries is a different proposition.

At 60 Hz, each server tick has 16.67 milliseconds. At 120 Hz, that falls to 8.33 milliseconds.

Those targets leave 20–30% headroom for replication bursts, garbage collection, matchmaking events, and unusually busy frames. A server that runs at 15.5 ms on a 60 Hz budget may look fine in a quiet test and fall over when several players interact with physics objects at once.

How many rollback frames do you need at 100 ms ping?

At 60 Hz, 100 ms is six simulation frames. At 120 Hz, it is twelve. That is the minimum history window implied by the round-trip time; production systems usually add margin for jitter and scheduling.

The memory formula is simple:

History memory = stored frames × serialized state size × rewindable entities

That last term is where projects get into trouble. Six frames of movement state for four players is cheap. Six frames of complete world state for 200 networked actors is not.

A useful compromise is selective rollback. Rewind player transforms, combat state, hit volumes, and other interaction-critical data. Keep cosmetic particles, audio, broad world streaming, and unrelated AI outside the replay path unless testing proves they must participate.

For shooters and larger action games, authoritative prediction is often the sturdier default. Players still get immediate local movement, while the server remains responsible for validation and final outcomes. Rollback can then be reserved for weapon traces, melee windows, or small competitive interactions rather than the entire world.

60 Hz vs 120 Hz: Responsiveness Has a Server Bill

A higher tick rate can reduce the time between simulation updates, but it doesn't magically remove network latency.

At 60 Hz, a simulation update arrives every 16.67 ms. At 120 Hz, it arrives every 8.33 ms. That can improve hit registration and reduce quantization error, particularly for fast movement. It also doubles server updates, increases bandwidth pressure, and doubles the number of history frames needed for the same RTT.

A 100 ms connection illustrates the trade:

• 60 Hz: approximately six frames of history;
• 120 Hz: approximately twelve frames;
• 120 Hz also provides half the per-tick CPU budget.

If the game’s simulation already consumes 5 ms per tick, 120 Hz leaves little space for replay spikes. A 60 Hz server with stable corrections may feel better than a 120 Hz server that regularly misses its deadline.

Measure these values rather than arguing from feel:

• server tick duration at p50, p95, and p99;
• correction frequency per player-minute;
• average and worst correction distance;
• replayed frames per correction;
• CPU milliseconds spent replaying;
• packet loss behavior at 1%, 3%, and 5%;
• input-to-photon latency on the client.

For network testing, use controlled impairment rather than internet anecdotes. Linux’s tc netem can add latency and loss to a test interface:

sudo tc qdisc add dev eth0 root netem delay 50ms 10ms loss 1%

That creates approximately 100 ms RTT when applied symmetrically through a suitable test setup. Always remove the rule afterward:

sudo tc qdisc del dev eth0 root

The key question is not whether rollback works on a clean 20 ms connection. It is whether the correction path remains visually and computationally stable at 100–200 ms RTT with jitter.

Shader Compilation Can Create Fake Network Lag

A player pressing a button during a shader hitch doesn't care whether the delay came from a packet, the render thread, or a pipeline state object. The screen stopped responding.

At 60 FPS, a normal frame lasts 16.67 ms. At 120 FPS, it lasts 8.33 ms.

This is why average FPS is a poor launch metric for a competitive game. Track p95 and p99 frame time, plus the worst first-use hitch during a cold-cache run.

Unreal Engine’s PSO workflow involves automatic precaching, bundled PSO caches, asynchronous compilation, and driver caches. Each helps, but none is free. Precaching can consume hundreds of megabytes or more, while background compilation competes with the game and render threads. Driver-cache retrieval can also add several milliseconds on some systems.

A proper Unreal PSO test should include:

1. Clear the game, engine, and driver shader caches.
2. Launch from a cold state.
3. Traverse every major map, biome, and combat arena.
4. Trigger first-use effects: explosions, weather, translucent materials, post-processing modes.
5. Repeat with a warm cache.
6. Repeat after a patch that invalidates or changes PSOs.
7. Run on a low-core-count CPU and a handheld PC.

Capture:

• time from launch to menu;
• time from menu to playable state;
• p50, p95, and p99 frame time;
• longest hitch;
• compilation CPU time;
• peak RAM and VRAM;
• runtime PSO misses.

On a development build, add timestamped markers around input receipt, simulation, render submission, and presentation. A frame-time spike with stable packet arrival and server tick timing points toward shader or CPU work, not netcode.

The cost can also move into the loading screen. That is usually a good trade for a competitive match: players tolerate a longer first boot more readily than a hitch during an aim duel. But don't hide the expense in a loading screen and declare victory. Measure launch time, memory pressure, patch behavior, and handheld performance too.

Microsoft’s Advanced Shader Delivery, announced for supported Xbox PC games using DirectX 12 through the Xbox App on PC, reports launch-time reductions of up to 95% on supported configurations. That is a platform-specific upper-bound claim, not a universal result for every Unreal or DirectX title. The general lesson is still useful: hardware-specific precompiled shader data can shift a meaningful cost away from runtime play.

Steam vs Epic Games Store: Margin Is Not Revenue

Epic’s published terms provide 100% of the first $1 million in annual net revenue per title, followed by an 88/12 split. The first-million threshold resets each January 1.

Steam’s familiar baseline is approximately 70/30, with reduced marginal rates of 75/25 above $10 million and 80/20 above $50 million.

For a simplified $100 sale, before taxes, refunds, payment processing, and other deductions:

On $500,000 of eligible revenue, Epic’s nominal advantage over Steam’s 70% share is $150,000. That is real money for a small studio. It can fund server months, a QA contractor, or the next content update.

But storefront choice is a conversion problem, not a percentage problem.

Steam’s audience brings established purchasing habits, wishlists, reviews, community features, controller support expectations, and a large population already looking for PC multiplayer games. Epic offers stronger headline economics and may provide promotional support, but a smaller or less habitual audience can offset the fee advantage.

The useful calculation is:

Storefront-adjusted profit = sales volume × effective developer share − support, distribution, and operating costs

If Steam converts 30% more visitors than Epic, its 70% share beats Epic’s 88% share whenever the audience and conversion gap is large enough. A simple example:

• Epic: 100,000 visitors × 2.0% conversion × $20 × 88% = $35,200
• Steam: 100,000 visitors × 2.6% conversion × $20 × 70% = $36,400

The Steam result wins despite the lower percentage.

Don't treat published user counts as directly comparable. Epic has reported more than 295 million users across 187 countries, while Sony reported more than 125 million monthly active accounts and over 93 million PS5 units as of March 2026. Those are different measurements. What matters for your game is qualified traffic, wishlists, concurrent players, regional pricing, and conversion.

For multiplayer, population has a second-order effect. A store with more relevant players can improve matchmaking times, retention, reviews, and long-term server health. A two-point margin improvement doesn't help if new players sit in empty queues.

A Practical Launch Decision

Use authoritative servers with client prediction when the game has persistent state, many players, significant cheat exposure, or a simulation that isn't reliably deterministic. Add rollback when the responsive interaction is central, the rewind scope is limited, and the team can replay at 100–200 ms RTT without blowing the CPU budget.

Run at 60 Hz by default. Move to 120 Hz only after profiling demonstrates a clear gameplay benefit and enough server margin. Reserve at least one RTT of history, then add room for jitter. At 100 ms RTT, budget six frames at 60 Hz or twelve at 120 Hz.

Treat cold-cache shader testing as part of netcode QA. A p99 hitch that consumes several simulation frames is a responsiveness defect, even if the network graph is clean.

Choose Epic when the title can bring its own traffic and is likely to remain below $1 million in annual eligible revenue. Choose Steam when discovery, population density, reviews, and established PC behavior are likely to produce materially higher conversion. The right storefront is the one that leaves you with more profitable, active players—not simply the one advertising the smaller cut.

Frequently Asked Questions

Q: What is the CPU cost of rollback netcode?

There is no fixed percentage. Cost depends on the number of replayed frames, simulation complexity, correction frequency, and the number of entities included in the rewind. Profile replay CPU milliseconds separately from normal simulation, and scope rollback to interaction-critical state whenever possible.

Q: How many rollback frames do I need at 100 ms ping?

At 60 Hz, plan for at least six frames of history; at 120 Hz, plan for at least twelve. Add margin for jitter and scheduling, and test at higher RTTs if your audience is global.

Q: Does shader compilation increase input latency?

Yes. A PSO or shader compilation stall can block game or render-thread progress, delaying the visible response to an input. A 100 ms hitch skips six frames at 60 FPS, so cold-cache p99 frame time belongs in responsiveness testing.

Q: Is Steam or Epic better for an indie multiplayer game?

Epic’s 100% share on the first $1 million per title and 88/12 rate afterward can produce better margins. Steam may still generate more profit if its discovery, conversion, and multiplayer population are substantially stronger; compare projected net sales, not storefront percentages alone.