Multiplayer client prediction reconciliation design is about making local input feel instant while the server stays in charge. The hard part is not predicting movement. The hard part is correcting the player without making them feel cheated by their own screen.
I used to explain prediction like a bar trick. Press right, move right now, wait for the server later. Clean. Cute. Then you watch a player slide into cover in their client, snap back into the open, die, and type the most predictable Spanish insult in chat. The trick is over.
Prediction is a UX contract. You are telling the player, "Act now, I will sort out the paperwork." Reconciliation is where that paperwork comes back stamped, rejected, delayed, or quietly adjusted. If that moment is invisible in your design, players will invent their own explanation, and it will usually be worse than the truth.
This article uses Unity Netcode latency and client anticipation docs, Valve's Source Multiplayer Networking notes, and Gabriel Gambetta's client-side prediction walkthrough. I am treating them as design material, not just implementation recipes, because the visible correction is what players remember.
Unity Netcode Latency Guidance
Unity discusses latency handling patterns, including client anticipation and controlled desyncs, for multiplayer games.
Unity Client Anticipation
Unity documents anticipated values, stale data handling, reanticipation, and smoothing as tools for responsive client behavior.
Valve Source Multiplayer Networking
Valve explains how prediction and lag compensation reduce the advantage and frustration created by network delay.
Gabriel Gambetta
Gambetta's fast-paced multiplayer series gives a clear model for client-side prediction and server reconciliation.
Chatforce
An AI game studio for making a browser-playable first version quickly, useful when testing how a predicted action should read before you build the whole netcode stack.
Prediction Is Not Permission
The oldest mistake is letting the client predict something the server is not willing to approve. Movement is the usual example, but the same problem appears in dashes, reload cancels, pickups, doors, ledge grabs, melee lunges, and every tiny input that feels better when it happens now.
The client can show the hopeful version. The server owns the accepted version. That split is fine as long as the hopeful version lives inside rules the player can understand. A half-step correction feels like network dust. A full-body teleport feels like the game changed its mind.
Prediction Choices That Change Player Trust
| Predicted action | Server check | Correction players can accept |
|---|---|---|
| Basic movement | Velocity, collision, stamina, and input sequence | Small smoothing, foot shuffle, or camera-stable adjustment |
| Short dash | Cooldown, available resource, obstacle hit, and start tick | Abort animation early with a clear failed dash beat |
| Item pickup | Distance, ownership, spawn state, and race order | Show a pending pickup flash until the server confirms |
| Door or switch use | Interaction range, lock state, and authority owner | Delay the world change but play local hand or sound feedback |
| Melee hit | Windup tick, range, target state, and server rewind policy | Let the swing complete, then reconcile damage, stagger, or whiff |
Correction Needs a Vocabulary
A bad reconciliation system has one word: snap. The server disagrees, so the client jumps to the server position. That is honest in the same way a brick through a window is honest. It tells the truth, but it ruins the room.
A better system has several words. Smooth. Blend. Cancel. Replay. Deny. Ghost. Confirm. You use different correction language for different promises. I can forgive a pickup icon that waits for confirmation. I am much less forgiving when my character rewinds through a wall after I already saw the safe side.
Predict actions that are cheap to correct. Delay or stage actions that are expensive to take back. The player should never pay full price for optimism the client invented.
The Input Sequence Is Part of the UI
Engineers think of input sequence numbers as protocol bookkeeping. Players experience them as rhythm. When reconciliation replays unacknowledged inputs cleanly, the character keeps the beat. When it drops or double-applies an input, the character suddenly has a different memory than the player.
That is why prediction bugs feel so personal. You did press jump. You did stop moving. You did turn left before the corner. The protocol might know what happened, but the screen has to respect the order your hands remember.
- Every predicted input has a sequence number and the client keeps enough unacknowledged inputs to replay after a server update.
- Corrections use distance and action type thresholds instead of one universal snap rule.
- Server-denied actions have visible denial states, especially for pickups, doors, dashes, and high-cost attacks.
- Camera smoothing is tested separately from character smoothing, because camera snaps feel louder than body snaps.
- Prediction is disabled or staged for actions that grant inventory, score, damage, or irreversible world changes.
- QA can force bad latency, jitter, packet loss, and reordered inputs without changing production code.
Prototype the Feeling Before You Build the Stack
You do not need the final server stack to test the shape of a correction. Fake 120 ms latency. Fake a rejected dash. Fake a contested pickup. Watch whether players notice the correction or notice the betrayal.
This is one place where Chatforce fits nicely as an AI game studio, not as a replacement for production netcode. Use it to get a 2D browser-playable first version of the input loop and correction language fast. Then rebuild the actual networking in Unity, Godot, Unreal, or your own stack when the feel is worth protecting.
Predict immediately
The action changes local feel and can be corrected without changing the match outcome.
Walking, aiming, camera response, short animation anticipation, and harmless local feedback.Predict with a pending state
The action feels bad if delayed, but the server might reject ownership or timing.
Pickups, interactables, reload cancels, ability starts, and contested objectives.Wait for authority
The action awards resources, kills a player, changes score, or creates permanent world state.
Damage confirmation, economy changes, match results, loot ownership, and ranked penalties.Smoothing Can Hide the Bug Too Well
There is a trap in making corrections beautiful. If every disagreement turns into a soft glide, your testers stop reporting the problem. The game looks fine until two players compare what happened and realize their screens told different stories.
During development, I like ugly debug overlays. Draw the predicted path. Draw the authoritative path. Show the correction size. Show the oldest unacknowledged input. The final build can be elegant. The dev build should be a little rude.
Prediction FAQ
Should every multiplayer game use client prediction?
No. Fast movement games usually need it. Turn-based games, slower co-op games, and some party games can often use simpler confirmation patterns without hurting feel.
Is client prediction the same as cheating risk?
Prediction can increase risk if the server trusts the client. Keep the server authoritative, validate inputs, and treat the client prediction as a visual guess.
What should I test first?
Test the worst correction your normal game can create. If that correction feels fair, the smaller ones usually survive.
Client prediction is not about pretending latency is gone. It is about choosing which parts of latency the player should feel. Good reconciliation does not erase the server. It teaches the client how to be wrong without embarrassing the player.