Why can an online game snap a player back?

A character seems to run through a doorway, then suddenly snaps backward. The game may be reconciling two different accounts of what happened: the immediate movement shown on your device and the result confirmed by a server after messages traveled across the network. Responsive play and shared agreement are not the same problem.

In a server-authoritative game, a server maintains the accepted game state. Your device sends input messages, and the server processes them and returns updates. Signals take time to travel, and network queues and processing add delay. Round-trip time measures a journey out and back; the two directions need not take equal time. Irregular delay and lost messages make updates less predictable.

Waiting for every reply before showing movement would feel sluggish. Some games predict local movement using the player’s inputs, then compare that prediction with a server update. If the results disagree, the client corrects its state and may replay inputs made after the confirmed moment. A small correction can be blended smoothly; a large one can appear as a sudden snap, often called rubber-banding.

Other players create a different challenge because your device does not yet know their newest inputs. A common technique is to display their movement slightly in the past, keeping a small buffer of received positions and interpolating between them. This trades some extra visual delay for smoother motion. Predicting a future position instead may look responsive until the other player suddenly changes direction.

No technique makes information arrive before it is sent. Games choose among responsiveness, smoothness and consistency, and different game types make different choices. A high display frame rate cannot by itself remove network delay: the screen may draw many smooth frames while still waiting for an authoritative update. Online motion is both an animation problem and a problem of coordinating knowledge across distance.