Why LAN events still change how professionals play
Players packing into a hall for a LAN final rarely get the zero-lag experience they imagine. Local networking eliminates the most obvious source of delay—the time packets spend crossing the internet—but it does nothing to the other stages that make up end-to-end latency. The rest of the chain, from the moment a key is pressed to the instant a pixel flips on the screen, stays in place, and it still shapes how professionals move, aim and trade hits.
The delay a player feels is built from several separate stages
What a competitor registers as lag is not a single number. It is the sum of input-processing time on the peripheral, a network leg that shuttles commands to the server, the simulation step the server runs before replying, and the display’s own rendering pipeline. Valve’s Source engine documentation makes one part of that explicit: the server simulates the world in discrete time steps called ticks, and a higher tickrate increases precision while demanding more CPU and bandwidth from both server and client. Unity’s Netcode for GameObjects documentation describes the same mechanism from a different angle, noting that tick rate—also called the simulation rate—is how frequently the server updates the game state, and that higher tick rates produce a more responsive experience at the cost of increased load on the simulating server. In both frameworks, the simulation already runs on a clock. Even if information could travel instantly, the server would still wait for the next tick boundary to process the latest usercmd and send out an updated world. That gap, a fraction of the tick interval on average, is built into the architecture.
Input delay compounds the problem. A USB controller, the operating system’s polling loop and the game engine’s own input stack all add time before the command ever leaves the machine. At the far end, a monitor’s panel electronics turn a finished frame into visible light after its own processing lag. The network is only one link in a chain that starts on the desk and ends at the cornea.
How online play hides the gaps it cannot close
Because competitive play rarely happens on a frictionless LAN, engines have developed a stack of compensations that work together. Client-side prediction runs a player’s own movement immediately, without waiting for the server to confirm it, so the local view stays sharp. For remote opponents, the client buffers a small window of server updates and plays them back with smooth interpolation between the received positions. Valve’s interpolation documentation states plainly that this buffering prevents jittery motion and can protect against glitches caused by packet loss. The server, meanwhile, knows how much interpolation each client has and adjusts its lag compensation to match.
Lag compensation handles the hit-registration problem. When a usercmd arrives, the server rewinds the game state by the player’s measured latency to reconstruct what that player was seeing at the moment the command was sent. Valve’s own lag-compensation documentation explains that, in combination with prediction, this can help combat network latency from the attacker’s perspective. Photon Engine’s Fusion documentation underscores why the mechanism is needed in the first place: what the player actually sees on screen is usually an interpolation between two ticks, not a discrete simulation step, so the visual snapshot a shooter reacts to does not align with any exact server tick. The rewind bridges that gap.
What each compensation mechanism does to the feel of the game
The artefacts these systems create are the texture of online play. Interpolation makes remote motion fluid but also introduces a deliberate delay; the client is always showing a version of the opponent that is a few ticks behind the server’s true state. Valve’s documentation notes that interpolation can mask packet loss, so the display remains stable even when updates go missing. Lag compensation rewinds hit tests, which means a bullet that connected on your screen is checked against where the target was at that earlier instant—good for the shooter, disorienting for a moving target who thought they had already reached cover. The Photon documentation captures the perpetual offset: because the screen image is not at a discrete tick, the server has to work backwards from the interpolated view.
Tick rate governs how fine that rewind can be. Valve’s Source networking page specifies that mods can set their own tickrate, but in tournament play the rate is chosen to balance responsiveness against server and client load. Unity’s documentation makes the same trade-off explicit: a higher tick rate yields a tighter simulation loop and faster reaction to player commands, at the cost of heavier processor and bandwidth demands. Lower tick rates enlarge the bucket into which commands fall, adding a jitter-like quality that no amount of network speed can eliminate.
Why a LAN event cannot give you the whole answer
Running the whole room through a local switch collapses network latency to a value most players would call zero, but that does not touch the server’s tick rate, which remains a property of the simulation itself. The engine still runs a discrete-step world, commands must still wait for the next processing window, and every client continues to interpolate remote players from the stream of updates it receives. The Photon documentation’s point—that the screen shows an interpolation between two ticks—remains true even when the round-trip time is measured in microseconds. Lag compensation continues to operate, though with negligible rewinding, because the architecture has no off switch for it.
Display latency is a separate thread that no local cabling can cut. A panel’s internal electronics still add a measurable delay, and the rendering pipeline from GPU to display port passes through buffers that stay full regardless of the network topology. The hall might provide identical monitors to every competitor, but nothing about a LAN makes a pixel switch faster.
The hall can still leave its own fingerprints
What a venue can control is limited and sometimes counterproductive. Server tick rate is a configuration choice, not a fact of geography, and organisers set it to match the competitive rules, not to chase an impossible zero. The rendering chain—driver settings, compositor flips, monitor processing—is no different on a stage than it is in a bedroom, and large-format spectator screens or capture hardware can push that part of the chain in the wrong direction. Valve’s developer documentation makes no promise that a LAN bypasses prediction or interpolation; it describes a system that was designed to work across imperfect connections, and that system stays running even when the connection is perfect.
Online play relies on a chain of prediction, interpolation and rewind to paper over the cracks. LAN events strip away the single largest variable in that chain—the public internet—but they leave the rest of the architecture exactly as it was. The professional edge is not built on chasing zero delay, because zero delay is a fantasy. It is built on understanding which compensations the game makes and which ones a player can turn to their advantage.