Why a Server Can Miss the Moment You Saw
A multiplayer game does not necessarily evaluate every action continuously. The server processes the shared game state in steps called ticks: it reads incoming player commands, updates movement and combat, then sends out a new state. Tick rate is how often those steps happen. Between updates, the server is effectively working from its last processed snapshot.
That creates a small timing gap. Suppose you move out of the path of an attack just after the server has checked positions. The next check may come only after the attack command has also arrived and been processed. On your screen, the dodge can look complete; in the server’s sequence of events, the hit may have been resolved first.
What Your Screen Shows—and What the Server Decides
Your game client draws frames locally so movement appears smooth, often estimating where other players will be between updates. That visual estimate is not the same as a fresh server decision. Network delay adds another gap: your input takes time to reach the server, and the result takes time to return. Games may compensate with techniques such as lag compensation, but those systems still have to reconcile what players saw with the server’s record of events.
A higher tick rate gives the server more frequent opportunities to process changes, making the timing of actions more finely resolved. It cannot eliminate network delay or guarantee that every visually successful dodge will count. It also requires more frequent processing and communication, so game developers balance responsiveness against server load and connection conditions.
The practical consequence is that a close fight can turn on a sliver of time: the client shows a continuous motion, while the server settles the outcome at particular update steps.
