Fast-Paced Multiplayer (Part IV): Headshot! (AKA Lag Compensation)

最新推荐文章于 2026-05-28 14:43:07 发布

转载最新推荐文章于 2026-05-28 14:43:07 发布 · 2.6k 阅读

网络同步专栏收录该内容

4 篇文章

订阅专栏

本文深入探讨了客户端-服务器架构中时间一致性和延迟敏感事件的问题，特别是针对快速多人游戏中的‘头击’场景。通过介绍延迟补偿技术，详细解释了如何在射击瞬间准确命中目标头部，并在不同情况下保持游戏公平性。文中还讨论了这种解决方案对玩家体验的影响，以及其作为解决快速游戏节奏中常见问题的有效方法。

原文：http://www.gabrielgambetta.com/fpm4.html

Introduction

It’s been a long, long time (over two years! wow!) since I published the last article in the series, and to my pleasant surprise, I’ve gotten quite a few emails asking for “the next one”. So here’s “the next one” - which could be called time consistency of latency-sensitive events, but Headshot sounds more satisfying :)

Recap

The previous three articles explained a client-server scheme which can be summarized as follows:

Server gets inputs from all the clients, with timestamps
Server processes inputs and updates world status
Server sends regular world snapshots to all clients
Client sends input and simulates their effects locally
Client get world updates and
- Syncs predicted state to authoritative state
- Interpolates known past states for other entities

From a player’s point of view, this has two important consequences:

Player sees himself in the present
Player sees other entities in the past

This situation is generally fine, but it’s quite problematic for very time- and space-sensitive events; for example, shooting your enemy in the head!

Lag Compensation

So you’re aiming perfectly at the target’s head with your sniper rifle. You shoot - it’s a shot you can’t miss.

But you miss.

Why does this happen?

Because of the client-server architecture explained before, you were aiming at where the enemy’s head was 100ms before you shot - not when you shot!

In a way, it’s like playing in an universe where the speed of light is really, really slow; you’re aiming at the past position of your enemy, but he’s long gone by the time you squeeze the trigger.

Fortunately, there’s a relatively simple solution for this, which is also pleasant for most players most of the time (with the one exception discussed below).

Here’s how it works:

When you shoot, client sends this event to the server with full information: the exact timestamp of your shot, and the exact aim of the weapon.
Here’s the crucial step. Since the server gets all the input with timestamps, it can authoritatively reconstruct the world at any instant in the past. In particular, it can reconstruct the world exactly as it looked like to any client at any point in time.
This means the server can know exactly what was on your weapon’s sights the instant you shot. It was the past position of your enemy’s head, but the server knows it was the position of his head in your present.
The server processes the shot at that point in time, and updates the clients.

And everyone is happy!

The server is happy because he’s the server. He’s always happy.

You’re happy because you were aiming at your enemy’s head, shot, and got a rewarding headshot!

The enemy may be the only one not entirely happy. If he was standing still when he got shot, it’s his fault, right? If he was moving… wow, you’re a really awesome sniper.

But what if he was in an open position, got behind a wall, and then got shot, a fraction of a second later, when he thought he was safe?

Well, that can happen. That’s the tradeoff you make. Because you shoot at him in the past, he may still be shot up to a few milliseconds after he took cover.

It is somewhat unfair, but it’s the most agreeable solution for everyone involved. It would be much worse to miss an unmissable shot!

Conclusion

This ends my series on Fast-paced Multiplayer. This kind of thing is clearly tricky to get right, but with a clear conceptual understanding about what’s going on, it’s not exceedingly difficult.

Although the audience of these articles were game developers, it found another group of interested readers: gamers! From a gamer point of view it’s also interesting to understand why some things happen the way they happen.