Client-Side Prediction
Client-side prediction runs the simulation locally the moment a player presses a key, instead of waiting for the server to confirm it. Movement feels instant. When the server's authoritative state arrives and disagrees, the client reconciles to match it. That reconciliation is where visible corrections come from.
Also called
prediction
,
What Does Client-Side Prediction Predict?
Mostly, what the player controls. When a key is pressed, the client runs the same game code the server will run and shows the result at once: the character moves, the camera turns, the weapon animation plays. The input still goes to the server, which stays the authority on what happened.
What else gets predicted depends on the game and the netcode. Many libraries predict what the local player controls and draw everyone else between server updates, which is interpolation. Unreal's Character Movement Component works this way, and Unity's Netcode for Entities offers it as an "Owner Predicted" mode, next to fully predicted and fully interpolated objects (Unity documentation). Fighting and sports games often predict every player, and projectiles a player needs to dodge are often predicted too (SnapNet).
Some outcomes are usually left to the server: whether a shot hit someone else, how much damage it did, who reached a contested item first. The client can show a hit marker straight away, but the server decides whether it counts. That is why prediction does not hand authority back to the client. The guess is shown on screen, never accepted as fact.
In Practices - Insights from Edgegap's Blog
Article's key insights
Desync is a disagreement, not a delay: Lag means information arrives late. Desync means two machines hold different versions of the same world, which is a separate failure with separate fixes.
There are two distinct kinds: Replication desync, where an authoritative server corrects a client that guessed wrong, and determinism desync, where peer simulations diverge and the session stops outright.
Rubberbanding has two levers: How often the client mispredicts, which latency drives, and how visible each correction is, which netcode drives. Pull either one and players see less of it.
Tick rate is neither lever: Raising it does not make predictions more accurate, and on a connection already dropping packets it makes the artifacts worse.
"A desync has occurred" is a checksum failing: Lockstep games compare state hashes every turn, so one divergent float or one unsynchronized random call ends the session.
How Does Server Reconciliation Work?
The client's guess and the server's answer are always a round trip apart. By the time the server's result for one input arrives, the player has pressed more keys. Reconciliation brings the two back together without throwing those keys away.
Number every input. The client tags each input with a sequence number and keeps a copy.
The server answers with a number. Its update carries the state and the last input it processed.
Reset and replay. The client resets to the server's state, then re-applies every input the server has not processed yet, which brings it back to the present (Gabriel Gambetta, Fast-Paced Multiplayer).
Unreal's movement system follows the same steps with "saved moves": the server re-runs each move, sends a correction when its result differs, and the client replays its saved moves from that point (Epic documentation). SnapNet describes the same loop by frame: input sent on frame 1, the answer received on frame 4, then "rolling back the client's simulation to the results from frame 1, resimulating frames 2 and 3, and then finally simulating the new frame" (SnapNet).
When the prediction was right, the replay lands where the player already is and nothing visible happens. Without the replay, the character would snap back to the server's older position on every update.
Why Do Predicted Players Get Corrected?
Because the client predicted without something the server knew: another player in the way, a knockback, an input the server never received because a packet was lost. A correction shows up as the character snapping or sliding back, which players call rubberbanding.
The round trip sets how much can go wrong. At 60 simulation steps per second, one step lasts about 16.7 ms, so a 30 ms round trip leaves about two steps waiting on the server, and a 180 ms round trip about eleven. More unconfirmed steps means more chances for the guess to be wrong, and a bigger correction when it is.
Netcode can soften this. Corrections can be smoothed over a few frames instead of snapped, and some libraries add input delay as latency rises so the client has less to predict. With SnapNet's default settings, "as a player's latency rises above 150ms, their controls would become gradually more sluggish but the game would remain playable." Each technique has a cost: smoothing briefly shows a position that is wrong, input delay makes controls less responsive, and replaying more steps "incurs a heavy CPU cost" (SnapNet).
A word from our sponsor (ourselves!)
Most lag comes from distance, not from code. Edgegap's Edge Cloud is a distributed network with up to 615+ locations available on demand, so each match runs at the best available location for its players. Independent replays of live studio traffic measured a 58% drop in average round-trip time compared with public cloud.
Edgegap's Take (just our opinion, take it with a grain of salt!)
Smaller Guesses, Fairer Matches
Prediction works best when it has less to guess. Every millisecond of round trip is time the client runs ahead of the server, and every input in that window is one the server might correct. Shorten the trip and corrections tend to get smaller and rarer, whatever netcode the game uses.
Distance also decides fairness. A player 150 ms from the server is likely to be corrected more often than one 20 ms away, for the same play. Starting each match's server at the best available location for all of its players narrows that gap: dedicated server placement measured a 58% average latency reduction against public-cloud relay placement (platform data, 18 September 2026).
Rivals of Aether 2 pairs SnapNet's prediction and rollback with servers placed close to each match's players, with a ping target below 20 ms. which the case study shows how.
,
