Dev Notes

How Unity Client-Side Prediction Underpins Unity Multiplayer Networking and Unity Deterministic Physics

Client side prediction Unity implementations are the standard answer to a problem every real-time multiplayer game eventually runs into: network latency makes a game feel sluggish the moment player input has to wait for a round trip to the server. A player presses the accelerator, and if the client waits for server confirmation before moving the vehicle, even a good connection introduces a hitch that reads as bad physics rather than bad networking. Prediction fixes the feel by moving the object immediately on the client and reconciling with the server later, quietly, in the background.

This article covers what that actually means in practice for a Unity project today: how the technique differs from the old assumption of a single authoritative simulation, what Unity's current networking stack gives you for free, and where it still leaves the hard parts to you. It is not a copy-paste solution. Anyone telling you prediction is a checkbox has not shipped it.

Schematic diagram of two offset ghost vehicle outlines, one solid and one dashed, connected by a signal line — FIG. 01 Predicted vs. Confirmed Position — Schematic

Why Real-Time Games Need Unity Client-Side Prediction

Every networked game has to decide who owns the truth. The simplest model puts the server fully in charge, with the client just displaying what it's told, and that's also the model most vulnerable to feeling bad. A round trip of 80-150ms between a player's input and a visible response is well past the point where people notice. Racing games, shooters, and even slower-paced building or crafting titles all lean on the same fix once ping climbs past a few dozen milliseconds: unity client-side prediction, applied to whichever piece of state feels laggiest first, usually movement.

The trade being made is explicit. The client is allowed to be wrong, briefly, in exchange for feeling instant. When the server's authoritative update arrives and disagrees with what the client guessed, the game has to correct itself without the correction being visible as a jump or a stutter. That correction step, not the prediction itself, is usually where a project's networking code lives or dies.

What people usually mean by the term

That pattern is what most engineers mean by client side prediction Unity teams have leaned on for a decade: move first, locally, then reconcile against the server later. Every writeup of client side prediction Unity ships in a shooter or a racer glosses over the same detail: what happens when the server disagrees, and how visible that disagreement is allowed to be.

From UNet to Unity Multiplayer Networking With Netcode for GameObjects

Unity multiplayer networking today runs on Netcode for GameObjects, usually shortened to NGO, which replaced the old UNet and NetworkView-era APIs some years back. NGO gives a project the fundamentals: a NetworkVariable<T> for state that should sync automatically, ServerRpc and ClientRpc calls for one-off commands, and ownership rules for who's allowed to write what. Anyone picking up unity multiplayer networking for the first time should get comfortable with that trio before touching prediction at all. Prediction is a layer built on top of NGO's fundamentals, not a replacement for them.

Detail — What NGO does not hand you

Netcode for GameObjects, by its own documentation, does not ship a complete client-side prediction and reconciliation system. Instead it provides building blocks, AnticipatedNetworkVariable<T> and AnticipatedNetworkTransform, that separate the "anticipated" value shown to the player from the "authoritative" value the server confirms. A variable exposes Anticipate() to set the guess and a Smooth() method to blend toward the corrected value instead of snapping to it; a StaleDataHandling setting controls whether an outdated server update is ignored or triggers a full re-anticipation. Wiring the actual prediction loop around those pieces is left to the developer. Unity has discussed bringing the more complete prediction model used in Netcode for Entities over to GameObject-based projects, but as of this writing that work is still in progress, not a shipped and stable feature, so it's worth checking the current release notes before assuming it exists.

A typical unity multiplayer client prediction setup ends up keeping two copies of state: what the client predicted locally, and what the server later confirms as authoritative. Debugging a unity multiplayer client prediction bug almost always means logging both values side by side and watching where they diverge, rather than trusting either one in isolation.

The Trouble With Unity Deterministic Physics Across a Network

This is the part of unity deterministic physics networking that trips people up. Full unity deterministic physics, meaning the same inputs producing bit-identical results on every machine, is a much bigger ask than it sounds, and Unity's PhysX-based simulation was never built to guarantee it. Floating-point rounding can differ subtly across CPUs and even across frame timing on the same machine, which means a physics-driven prediction can drift out of sync with the server in ways that have nothing to do with your networking code at all.

Teams that lean on unity deterministic physics networking anyway tend to narrow the scope rather than fight PhysX head-on: a custom, simplified simulation running in fixed-point or carefully-controlled floating math on both client and server, reserved for the handful of objects where prediction actually matters, such as a vehicle's chassis or a projectile's arc. Cosmetic physics, debris, particles, anything the player doesn't directly steer, stays purely client-side and never needs to agree with anyone.

When a studio truly needs unity deterministic physics for something like lockstep simulation, the honest answer is that stock Rigidbody physics is the wrong tool, full stop. It's a smaller, harder, more deliberate build than dropping a Rigidbody on a prefab and calling it done.

Building a Minimal Prediction and Reconciliation Loop

Once you understand the shape of unity client-side prediction, the actual loop is almost anticlimactic. Three pieces, repeated every tick:

Apply the player's input locally and immediately, and remember it (input + resulting state) in a short buffer keyed by tick number.
Send the input to the server; the server applies the same logic and returns its resulting state, tagged with the tick it corresponds to.
When the client receives that authoritative state, compare it against what the buffer says it predicted for that same tick. If they match, discard the buffered entry and move on. If they don't, snap or smoothly blend to the server's version and re-simulate any later ticks the client had already predicted past.

// Illustrative only, not a drop-in NGO sample.
// Conceptual shape of a reconciliation check using NGO's anticipation primitives.
public class VehiclePosition : NetworkBehaviour
{
    public AnticipatedNetworkVariable<Vector3> Position;

    void OnInput(Vector3 moveDelta)
    {
        // Client: guess immediately.
        Position.Anticipate(Position.Value + moveDelta);
        SubmitMoveServerRpc(moveDelta);
    }

    [ServerRpc]
    void SubmitMoveServerRpc(Vector3 moveDelta)
    {
        // Server: authoritative move, replicated back down automatically.
        Position.AuthoritativeValue += moveDelta;
    }

    void OnReanticipate(Vector3 previous, Vector3 authoritative)
    {
        // Called when server and prediction disagree; blend instead of snapping.
        Position.Smooth(previous, authoritative, 0.15f, Vector3.Lerp);
    }
}

The hard part is never the happy path. It's deciding how far back to re-simulate on a mismatch, how aggressive the smoothing curve should be before it feels rubber-banded, and how much of your gameplay state actually needs this treatment versus how much can just be told what happened, after the fact, with no complaints from the player.

Frequently Asked Questions

What is client-side prediction in Unity multiplayer?

Unity client-side prediction is a technique where the client applies a player's input immediately, without waiting for the server to confirm it, and then reconciles against the server's authoritative result once it arrives. It removes the perceived lag of a network round trip from movement and other latency-sensitive actions.

Does Unity have built-in client-side prediction?

Not a complete one. Netcode for GameObjects ships two building blocks, AnticipatedNetworkVariable and AnticipatedNetworkTransform, which separate the anticipated value from the authoritative one, but assembling the full predict-and-reconcile loop is left to the developer.

What replaced UNet for Unity multiplayer networking?

Netcode for GameObjects (NGO) is Unity's current multiplayer framework, and it replaced the older UNet and NetworkView APIs. NGO is built around NetworkVariable<T> for synced state and ServerRpc/ClientRpc for remote calls.

Why is deterministic physics hard to achieve over a network?

PhysX, Unity's default physics engine, does not guarantee bit-identical results across different machines or even different frame timings on the same machine. That makes standard Rigidbody simulation unreliable as the basis for prediction that must match exactly between client and server.

How do developers work around non-deterministic physics for prediction?

Most teams narrow the problem instead of solving it in general: they write a small, custom simulation (often fixed-point) for the handful of objects that must be predicted precisely, and leave everything cosmetic (debris, particles, non-player physics) as ordinary client-side simulation that never needs to match the server.

What happens when the client's prediction is wrong?

The server's authoritative update arrives and is compared against the client's buffered prediction for that same tick. If they disagree, the client corrects toward the authoritative value, usually blending over a short duration rather than snapping instantly, and re-simulates any later ticks that were predicted on top of the now-wrong state.

Is client-side prediction only useful for shooters?

No. Any real-time game where input needs to feel instant benefits from it: vehicle and racing games, platformers, and even building or crafting titles with physics-driven pieces all run into the same latency problem the moment they add multiplayer.

What's the difference between client-side prediction and lag compensation?

Client-side prediction hides latency for the local player's own actions by simulating them before the server confirms them. Lag compensation is a related but separate server-side technique that rewinds other players' positions to what the shooter actually saw, usually applied to hit detection rather than movement.

Should every networked object be predicted?

No, and trying to is a common mistake. Prediction adds real complexity, so it's usually reserved for the object the local player directly controls. Other players' avatars are typically just interpolated toward their last known server position, which is far simpler and looks fine at normal latencies.

Where can I read Unity's own documentation on this?

Unity's Netcode for GameObjects manual covers latency handling directly, including the anticipation building blocks referenced above: docs.unity3d.com — Dealing with latency. Unity's own community forum also has an active discussion thread on client-side prediction and reconciliation approaches: discussions.unity.com.

Conclusion

None of this requires exotic tooling. Netcode for GameObjects hands you NetworkVariable and RPCs, plus the anticipation primitives to build on top of; unity client-side prediction is really just the discipline of not waiting on them for anything that has to feel instant. What it does require is being honest about scope: predict the one or two things the player actually feels, keep deterministic physics narrow and deliberate rather than PhysX-wide, and accept that the reconciliation code will end up longer than the prediction code ever was.

A vehicle's steering rarely needs the same treatment as its exhaust particles. Deciding which is which, before writing the network code, saves most of the rework.