Source: https://gameye.com/glossary/interpolation/ --- title: "Interpolation | Gameye" description: "Interpolation smoothly renders other players between server updates so characters move fluidly rather than teleporting each tick." --- # 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](https://gameye.com/glossary/client-side-prediction/) · [Lag Compensation](https://gameye.com/glossary/lag-compensation/) · [Tick Rate](https://gameye.com/glossary/tick-rate/) · [Netcode](https://gameye.com/glossary/netcode/) Building a multiplayer game? Gameye hosts dedicated game servers: ship your server as a Docker container and start one per match with a single API call, in a region near your players. [See how it works →](https://gameye.com/how-it-works/) [Back to Glossary](https://gameye.com/glossary/) ## Related terms - ### Client-Side Prediction Client-side prediction applies player inputs locally without waiting for the server, so movement feels instant even on high-latency connections. [Read more](https://gameye.com/glossary/client-side-prediction/) - ### Lag Compensation Lag compensation rewinds server game state to the moment a player fired, judging shots fairly despite network delay. [Read more](https://gameye.com/glossary/lag-compensation/) - ### Tick rate Tick rate is how many times per second a game server updates the game state, measured in hertz (Hz). A 64-tick server updates 64 times a second; a 128-tick server, 128. [Read more](https://gameye.com/glossary/tick-rate/) - ### Netcode Netcode synchronises game state between players. Poor netcode causes lag, rubber-banding, and hit registration issues in multiplayer games. [Read more](https://gameye.com/glossary/netcode/) - ### Latency Latency is how fast data is moving. How quickly does it get from point A to point B? (And it’s generally measured in milliseconds.) [Read more](https://gameye.com/glossary/latency/)