Why a shot is hard to judge
Imagine two players aiming at each other in an online match. Player A fires at the exact moment Player B appears in the crosshair, on A’s screen. But A’s screen is already a little out of date. It shows where B was a short time ago, because the information had to travel from the server to A. B’s screen, in turn, is also slightly behind, and B has probably already moved on.
So the question of whether the shot hit has no single obvious answer. Each player’s version of events is reasonable from where they sit. The game has to pick one version to treat as official, and it has to do so quickly. The set of rules for doing this is often called hit registration, and the methods used to even out the delays are grouped under lag compensation.
Where the delay comes from
The delay in this situation is a combination of several parts:
- the time for A’s action to reach the server
- the time the server takes to process it
- the time for updates to reach the other players
- the short gaps between updates, set by the server’s tick rate
- the time your own screen and input devices take to show things
Each of these is small. Added together, and doubled in effect because both players are affected, they can be enough that the moment A believes they fired and the moment the server finishes processing it are noticeably different.
Two broad approaches
Games generally pick from a spectrum, with most using some mix.
Favor the shooter. The server tries to reproduce what the shooter saw. When it receives a shot, it looks at the shooter’s estimated delay and temporarily rewinds the positions of other players to roughly where the shooter saw them. It then checks whether the shot would have hit. This is the usual meaning of lag compensation in many first-person shooters. It makes shooting feel responsive, since a shot that looked right on your own screen tends to count.
Favor the target. The server judges shots using the current positions of players, without rewinding. This is easier to reason about and avoids the strange situation of being hit after reaching cover. The cost is that players with higher delay must lead their targets, aiming ahead of where the target appears. That is harder and can feel unfair to them.
Neither approach removes the underlying problem. They move the inconvenience from one player to the other.
The “hit after cover” experience
The most commonly discussed side effect of favoring the shooter is being hit after you believe you have taken cover. From the shooter’s perspective, the shot was fired while you were still visible. The server accepted that version, rewound your position, and counted the hit. By the time the news reaches you, you are already behind a wall.
This is not necessarily a bug or a sign of cheating. It is a direct consequence of the design choice. Many games limit the effect by capping how far back the server will rewind, so that a player with a very poor connection cannot claim a hit from too long ago. Past that limit, the shooter must adapt. The exact cap, if there is one, differs between games.
Client prediction and corrections
Lag compensation sits next to another technique. To make your own controls feel quick, the client often applies your movement immediately and confirms it with the server later. If the server disagrees, it sends a correction, and you may be pulled back to a different position. Players call this snapping or rubber banding, and it is closely tied to how stable your connection is, as discussed under packet loss.
Some games also let the client report hits directly to the server, trusting the shooter’s machine. This can feel very responsive, but it gives cheaters more room to act, so it is a trade-off between feel and security. Detection of cheating through anti-cheat software is a separate topic.
Why things still feel inconsistent
Even a well-designed system can produce moments that feel off.
- Connection differences. The larger the gap between two players’ connections, the more different their views. A player with a poor connection may find that more of their shots seem to miss, or that opponents seem to hit them oddly.
- Update rate. If the server updates the world infrequently, there are fewer snapshots of positions to rewind to, so the reconstruction is less exact.
- Animation and hitboxes. The areas on a character that count as hits are often simpler than what you see, and animations can sit a little ahead of or behind the underlying hit area. A shot that looks like a clean hit might therefore register as a miss, and the reverse can occur.
- Frame timing. Your own display and device add small delays that no network setting can fix. Timing issues of this kind are usually described as input latency.
Because of all this, a single clip in which a shot “should have counted” is weak evidence. The recording shows one player’s view, and the server may have judged using a different one.
Reading complaints with care
Complaints about hit registration are common in competitive games, and some are valid, since games do have bugs and poorly tuned settings. Many others come from a mismatch between what a player saw and what the server decided, which is built into how the system works. Players generally have no direct way to see the server’s record, and developers do not always publish their approach, so it is wise to be cautious about firm claims regarding any specific title.
If you want to reduce problems, a wired connection and a nearby server region usually help, though they cannot remove the effects described above. Latency is only one factor, as the explanation of ping time shows. Smoother, more even connections tend to produce more predictable results than a low number alone.