游戏里明明躲开了，为什么还是被击中？-优快云博客

设想一局射击游戏：你看到对手，立刻退到墙后。屏幕上的角色已经躲好，血量却在下一刻掉了一截。

第一反应大概是：“这也能打中？”

对手可能同样困惑。在他的画面里，你还没完全进掩体，那一枪确实瞄准了。

两个人看到的画面不一致，不一定是谁看错了。联网游戏里，屏幕上正在发生的事，与服务器此刻掌握的状态，本来就可能有时间差。

这篇以常见的服务器权威型实时游戏为例。不同游戏的同步和命中规则差异很大，下面解释的是可能出现这种现象的机制，不能拿来判定某一局里的具体争议。

你按下移动键，这次操作要经过网络才能到达服务器。服务器处理后的状态，还要再传到其他玩家那里。

与此同时，你的屏幕不能一直停着等。

于是，一局游戏里会同时存在几个视角：你本地已经显示的位置、服务器确认过的位置，以及对手收到并显示的位置。它们属于同一场比赛，却不保证对应完全相同的时刻。

其他玩家的动作还可能经过插值处理：客户端留一点缓冲，把收到的离散位置连成平滑运动。画面因此更连贯，但你看到的对手通常也就带着一点过去的影子。

理解这一点，就能把“我明明看见了”与“最终怎么判定”分开讨论。前者是可靠的体验反馈，却不一定足以独立还原整个事件。

如果每次移动都要等服务器回复，你按下方向键，角色过一会儿才迈步；再按跳跃，又等一轮。网络延迟会直接变成手感上的迟钝。

客户端预测就是为了解决这个问题：先根据本地输入推进自己的角色，等权威状态回来，再检查两边是否一致。Unity 的网络文档也用这种方式解释如何兼顾即时响应与服务器判定。Unity：客户端预测

“预测”这个词容易让人想到猜对手下一步要做什么。这里更常见的情况其实是：你已经按了向右，客户端先按同样的运动规则算出自己会往哪里走。

大多数时候，这个结果与服务器足够接近，你感觉不到中间有过一次核对。

但如果服务器已经判定你被击退，或者某个碰撞条件与你本地掌握的不一样，本地先走出的那一步就可能需要修正。

你向前跑了几步，突然又回到原来的位置。这种“橡皮筋”一样的体验，常被叫作回拉。

它可能来自本地预测与权威状态出现差异。客户端收到更新后，需要让后续状态重新对齐；具体是平滑过渡、明显跳回，还是用其他方式纠正，取决于游戏实现。

这里有个容易误会的地方：收到一个较早的位置，不代表客户端一定要简单地跳回那个位置。完整的预测系统可以在权威状态基础上，重新处理尚未确认的输入。修正的是推演的起点，不是让玩家机械地活在过去。

对于玩家，内部过程并不重要。他关心的是：明明按了操作，游戏为什么又把结果改了？

因此，画面看起来流畅还不够。一个游戏可以一直保持很高的帧率，同时不断纠正角色位置，玩起来照样难受。

稳定延迟会让信息持续落后。延迟抖动和连续丢包，则会让更新的节奏也变得不稳定。

比如，角色原本匀速前进，几次更新突然没来。本地还能根据旧信息继续显示，但不知道对手是否已经转向。等新状态终于到达，画面可能需要一次更明显的调整。

具体表现取决于输入是否冗余发送、状态更新如何组织，以及客户端允许推算多远，不能把一次丢包直接等同于“一次操作丢失”。

这也是为什么只看平均延迟，常常解释不了手感。有时数字看着不高，玩家却频繁遇到停顿、瞬移或回拉。

测试时，与其只记录“平均多少毫秒”，不如同时记下修正发生在什么时候、持续多久，以及它是否改变了玩家正在做的动作。

一种可能是伤害结果到达得晚：命中已经发生，只是你较晚收到消息。

另一种可能与延迟补偿有关。有些游戏在处理射击时，会参考一段历史状态，尽量判断玩家开枪时所看到的目标能否被击中，而不只看处理请求这一刻的目标位置。Valve 对这类机制及其视觉矛盾有专门说明。Valve：延迟补偿设计

这会带来视角上的冲突：射击者觉得自己打中了当时仍在外面的目标，被击中者却觉得自己早已进了掩体。

补偿通常需要边界。允许参考多早的历史、怎样处理过晚的操作、哪些对象参与补偿，都是游戏规则的一部分。它不是无条件相信客户端，更不意味着延迟越高越有优势。

完全取消补偿，也未必让双方都满意。那样可能让射击者经常觉得“准星明明对着，却打不中”。网络耗时没有消失，只是由不同的体验承担。

当然，穿透规则、碰撞体、服务器负载甚至程序缺陷，也可能产生类似现象。仅凭一段本地录屏，不能直接认定是延迟补偿造成的。

测试这类问题，最好让两个可控客户端进入同一场景，并保留可关联的操作记录。只给其中一方增加延迟，与双方都变慢，可能暴露不同的问题。

可以从几组具体观察开始：

对齐记录时，需要使用可关联的事件或游戏时刻。两台设备各自录屏上的时间，未经校准不能直接相减。

也不要只验收“重新连上了”。如果客户端已经显示角色复活，服务器仍认为角色阵亡，那么连接虽然恢复，比赛状态还没有恢复正确。