Interpolation
Interpolation is how a game client smoothly renders other players between server updates — filling in the gaps between received positions so characters move fluidly rather than teleporting tick by tick.
A server running at 64 ticks sends position updates every 15.6ms. Your screen renders at 144fps, updating every 7ms. Without interpolation, other players would stutter visibly at every server tick boundary. Interpolation solves this by rendering players slightly in the past — smoothly blending between the last two confirmed server positions.
Interpolation vs. extrapolation
These two approaches solve the same problem differently.
Interpolation renders the player between two known positions — the last update received and the one before it. You are always rendering slightly in the past (by one to two tick intervals), but the result is smooth because both endpoints are real data from the server. This is the standard approach in most competitive multiplayer games.
Extrapolation (sometimes called dead reckoning) tries to predict where a player will be rather than where they were. The client takes the last known position and velocity and projects forward. When the prediction is correct, movement looks smooth. When it is wrong — the player changes direction, stops, or the packet is delayed — you see snapping or rubber-banding as the client corrects to the real position.
Extrapolation is generally avoided for player characters in fast-paced games because prediction errors are visually jarring and can create hit-registration inconsistencies. It is more commonly used for physics objects and projectiles.
The interpolation delay tradeoff
The deliberate lag introduced by interpolation is real and worth understanding. If your interpolation buffer is 50ms, other players appear where they were 50ms ago. Combined with your own round-trip latency to the server, the enemy you are shooting at may be 100–150ms behind where they actually are on the server.
This is why lag compensation exists: without it, interpolation would make hit registration nearly impossible for high-latency players. The two systems are designed together — interpolation makes visuals smooth, lag compensation makes hit registration fair.
Packet loss and interpolation
When packets are lost or arrive out of order, interpolation has to handle the gap. If a single update is missing, most clients extrapolate briefly for one frame and then resume interpolating when the next packet arrives. If multiple consecutive packets are lost, the character may freeze, stutter, or rubber-band. This is the most visible symptom of packet loss in a well-implemented multiplayer game — not raw latency, but the irregular delivery that breaks interpolation’s assumptions.
Tuning interpolation delay
The interpolation delay (how far back in time to render other players) is a tunable parameter. Too short and you risk running out of buffer when packets are slightly delayed, causing stutter. Too long and the visual gap between what players see and what is true on the server grows, making the game feel sluggish and making lag compensation corrections more significant.
Most competitive games use an interpolation delay of one to two server tick intervals — enough buffer to absorb normal network jitter while keeping the visual delay small.
See also: Client-Side Prediction · Lag Compensation · Tick Rate · Netcode