Most competitive multiplayer games run on a client-server model: a dedicated server holds the authoritative copy of the game world, and every player’s client sends it input and receives back a snapshot of what happened. Valve’s own developer documentation for the Source engine describes the arrangement plainly: the server is “authoritative about world simulation, game rules, and player input processing,” while a client “samples data from input devices” and sends those samples to the server for processing, then renders whatever state the server sends back. Clients never talk to each other directly. Every interaction between two players’ actions passes through the server first.
The server doesn’t process that input continuously; it processes it in discrete steps called ticks, and tick rate is simply how many of those steps it runs per second. Source’s documentation puts a number on what that costs and buys: a server running at a default 66 ticks per second, versus a possible 100, generates roughly 1.5 times the CPU load for the higher rate, which is why a studio doesn’t simply set tick rate as high as hardware allows and stop thinking about it. A higher tick rate means the server checks player positions, hit registration and game rules more often per second, which raises precision at the cost of CPU and bandwidth on both ends of the connection. Riot Games’ own account of building VALORANT’s 128-tick servers, double the 64-tick rate common in the genre at the time, frames the tradeoff around a specific gameplay problem: the game’s core loop rewards holding a position, and that only works if a defender has enough reaction time before an attacker rounding a corner can react and win the exchange first, a timing problem the article calls peeker’s advantage. More frequent server updates gave defenders more of that reaction time back.
Tick rate alone doesn’t solve the deeper problem of network delay, since even a server updating instantly is still separated from a player by however long a packet takes to travel each way, the round-trip time commonly called ping. Two techniques compensate for that gap from opposite directions. Client-side prediction has the local client immediately simulate the results of the player’s own input, using the same movement code the server will eventually run, rather than waiting for the server’s response before showing the player anything; if the server’s own result later disagrees, a prediction error, the client corrects position smoothly rather than snapping. Lag compensation runs in the other direction, on the server: when a shot arrives, the server doesn’t check hit detection against where a target is right now, it keeps a short history of recent player positions and rewinds other players back to where they were at the moment the shooter’s client actually fired, before checking for a hit. Riot’s own description of VALORANT’s server confirms the same mechanism by name: the server “rewinds the player positions and animation state using the historical buffer to calculate if the shot hit.”
This is also why hit detection runs on the server at all, rather than trusting a client’s own claim that a shot connected. Valve’s documentation is direct about the reason: a game server “can’t trust the clients on such important decisions,” since even an uncompromised client’s packets could be altered in transit by a machine sitting between it and the server. The consequence both sources describe is the same odd experience competitive players eventually learn to recognize, being hit by an attacker after you’ve already ducked behind cover, because the server rewound your position back to where you stood a fraction of a second earlier, when the shot that hit you was actually fired.