Nearly every online shooter has produced the same moment for its players at some point: you were clearly behind cover, and you still died. It happens in Fortnite, in ARC Raiders, in Warzone, in games with excellent tick rates and games with poor ones alike. The specific games and specific tick rates differ, but the underlying mechanism causing this moment is, more often than people realize, the exact same one — a network protocol decision made decades ago that prioritizes speed over guaranteed delivery.
Meet the Protocol Behind Almost Every Shooter
Most online games send player movement and action data over UDP rather than TCP. TCP, the protocol behind most of the reliable internet — web pages, file downloads — guarantees every packet arrives, resending anything that gets lost along the way. UDP makes the opposite tradeoff: it prioritizes speed, and if a packet carrying your position data gets dropped somewhere between your machine and the server, UDP doesn’t resend it. It simply moves on to the next packet. For a fast-paced shooter, this tradeoff makes sense — a slightly stale position update that arrives instantly is far more useful than a perfectly accurate one that arrives late, and by the time a resent packet would arrive, the moment it described is already over.
Why This Produces the Exact Same Complaint Everywhere
Here’s the mechanism in plain terms: when a packet carrying your updated position gets dropped over UDP, the server never receives that update. It continues rendering you at your last known position — not where you actually are. If you moved behind cover in that dropped update, the server’s version of you is still standing in the open, and an opponent’s shot against that outdated position registers as valid, even though your own screen has shown you safely behind cover for a full second or more. This isn’t a bug specific to any one developer’s code. It’s the direct, predictable consequence of choosing UDP for speed, showing up identically across games built by completely different studios on completely different engines.
Why This Isn’t Something a Higher Tick Rate Fixes
This is worth understanding clearly, because it’s easy to conflate with tick rate, and they’re solving different problems. A high tick rate means the server updates its understanding of the world frequently. It says nothing about whether the specific packet carrying your critical position update actually survived the trip. ARC Raiders is a clean real-world example — independent testing measured its tick rate at roughly 90Hz, genuinely high, and players still experienced real desync that Embark eventually traced to backend packet loss, not the tick rate. A fast-thinking server can still be fed bad or missing information.
You can check your own packet loss directly, continuously over time, with our server ping test — this is the metric most players never think to look at, because most standard speed tests never show it to them at all.
Related Guides
- Gamer Hub — All Game Ping Tests
- ARC Raiders Ping Test
- General Server Ping Test
- What Causes Packet Loss?
- Jitter vs Ping for Gaming
Frequently Asked Questions
Why does “shot behind cover” happen even in games with good tick rates?
Because tick rate and packet loss are separate problems. A high tick rate means the server updates frequently, but it doesn’t guarantee every movement packet sent over UDP actually arrives — a dropped packet leaves the server with your last known, now-outdated position, regardless of how fast the server itself is thinking.
Why don’t games just use a more reliable protocol instead of UDP?
A more reliable protocol like TCP would resend lost packets, but by the time a resent packet arrived, the moment it described would already be over in a fast-paced game. UDP’s speed-over-reliability tradeoff is deliberate, not an oversight.