易竞技前言：在知乎上有玩家提问“在FPS游戏中玩家延时都不一样的情况下是怎样做到游戏的同步？”知乎网友“周恺华”对此给出较为充实的回答，有兴趣了解这方面知识的玩家可以通过下面的回答来一窥究竟。
知乎网友“周恺华”的回复：
声明：下面会大量使用CSGO作为例子，因为Valve在多人游戏的网络通信方面做得较好，可以当做一个典型来分析。
多人竞技游戏中客户端和服务器的互动
游戏中所有的逻辑判定都是由服务器完成的，客户端只负责发送请求和接收服务器的反馈，并把反馈具象化。拿CSGO做例子，玩家A拿着AK瞄准了玩家B的头开了一枪，那么玩家A的客户端会向服务器发送一个数据包，里面包含了谁（玩家A）拿着什么武器（AK）从什么位置（玩家A在地图上的坐标）向什么方向（角度）开了一枪。服务器收到后进行判定，这一枪的伤害会经过玩家B的头部模型，判定为爆头伤害，数值为XX，判定玩家B死亡。服务器再向所有玩家的客户端通信，更新当前游戏状态，其中包括玩家A用AK爆头击杀了玩家B，也会包括其他信息，比如玩家们的位置等等。玩家A收到通信后显示击杀了玩家B，玩家B则会收到被击杀的信息。
接着讲一个概念，叫服务器的通信频率（tick rate）。事实上服务器不是百分百实时地向玩家通信来更新游戏状态的，那样需要的计算量很大，同时对网络带宽的要求也会高的不现实，因此服务器会以一定的频率来进行通信。
CSGO在娱乐模式下通常采用60Hz的频率，也就是说每过1/60秒玩家的客户端就会收到一次新的信息。如果回到上面那个例子，那么实际情况应该是：玩家A拿着AK瞄准玩家B的头开一枪，你的客户端会向服务器发送一个数据包，服务器接收后进行判定。判定完成后等待至下一次通信，再向所有玩家更新游戏状态。也就是说游戏过程其实是一个离散的过程而非连续过程。
易竞技配图：CSGO是近年来不错的FPS游戏
易竞技配图：CSGO是近年来不错的FPS游戏
如果玩家的Ping很大，服务器会怎么办？
上面的例子都假设客户端和服务器之间的延迟无穷小，那么当玩家Ping很大的时候会发生什么的呢？
假设玩家A与服务器之间存在100ms的延迟（单向，往返则是200ms），其他玩家的延迟忽略不计，服务器的通信频率足够大（频率不够大还会造成其他很严重的问题，这个放在后面讲）。玩家A在某一刻向服务器发送了一个请求（比如向前走），那么这个请求会在100ms之后到达服务器，服务器判定后返回结果，再经过100ms你的客户端会收到确认，服务器已经把你的位置向前移动了若干距离。假设客户端在没有收到任何服务器的更新前画面都不会变化，那么在这200ms内你就会觉得游戏“卡顿”。
实际上很多游戏里中你会在这200ms里看到你自己是在向前走，其实那只是客户端“擅自”在绘制你前进的样子，这是一种延迟补偿策略，称为“客户端预测法”。即客户端能够大致预测游戏未来的走向，因此在接收到服务器更新前会把预测到的画面先绘制出来（比如移动、武器的开火效果、弹药计数的变化等）。客户端收到服务器通信后如果数据有出入则立刻纠正为服务器提供的数据。因此在延迟很大的时候玩家会发现“明明往前走了过了一会又瞬移回到之前的位置”的原因，或者是“明明开了好几枪而且也都显示了但过了一会弹药计数只减少了一点点”。
既然扯到这里了那就认真的讲下延迟补偿策略（lag compensation），一般来讲补偿策略分服务器端和客户端两类，上面提到的预测法属于客户端一类，其他的客户端策略还有插帧法。所谓插帧法就是客户端会记录之前一次从服务器收到的信息，然后在接受到下一次通信的时候不立刻更新游戏画面，而是逐渐的更新画面（比如两次通信间玩家B移动了10单位距离，客户端会绘制玩家B以一定的速度移动了这10单位距离，而非立刻绘制玩家B瞬间移动了10单位距离）。插帧法的问题在于如果玩家并未沿直线运动且其直线路径中有本应不能通过的物体存在时（比如绕过一堵墙），客户端会绘制出该玩家穿墙而非绕过去的动作。
服务器端处理延时同步常用的策略
1.“眼不见为净”法，服务器不去补偿玩家的延迟是一个合理的做法，特别是当游戏内进行的事件非常多（想想《行星边际2》里面千人同图混战的情形）。浪费宝贵的服务器资源去补偿个别玩家的延迟是不明智的。这个策略的缺点很明显，就是玩家有可能会对游戏体验不满意。
2.“倒带”法，采用倒带法的服务器会记录刚刚过去一段时间内（比如0.5秒）游戏内的所有信息。当一个有延迟的玩家（比如200ms）向服务器发送一个请求，那么服务器在处理这个请求的时候会调取0.2秒前游戏的状态然后进行判定，在把判定结果对所有客户端进行同步，如此一来该玩家的操作虽然有延迟但也能与他/她所看见的画面一致。该策略的最大问题在于它让不同延迟之间的玩家被迫体验较大的延迟。举个例子，假设游戏里击杀时间（TTK）足够小，玩家A（10ms延迟）和玩家B（延迟200ms）对射，两人都是空血（一次攻击即死），A比B先开火（时间差很小，比如50ms）。玩家A的次攻击很快（10ms后）就得到了处理并记录在服务器中，玩家B被判死亡。然而在200ms后玩家B的请求到达，服务器倒带0.2秒，此时玩家AB都未死亡，因此玩家B的攻击有效，玩家A也被判定为死亡。如果没有延迟，那么服务器应该会判定玩家B死亡，因此玩家B将无法攻击，玩家A应该存活。换句话说采用倒带法的服务器里如果有一个延迟很大的玩家将会拖累其他低延迟玩家的游戏体验。
下一页：低通信频率会带来的灾难
以BF4为例，低通信频率会带来的灾难
前面的例子都是以服务器的通信频率足够高为前提的，下面简要描述一下低通信频率带来的问题。这里我要举的例子是大名鼎鼎的《战地4》（下称BF4）。
BF4在刚刚发布的时候可谓是Bug满天飞整一个就是半成品，其中非常严重的就是网络通信问题（netcode issue）。根据制作组DICE提供的信息，BF4的通信频率是10Hz。这是一个相当低的设定了，大多数FPS的通信频率在30Hz左右，而CSGO为60Hz，电子竞技比赛时一般服务器的通信频率还会提高到120Hz（因为比赛时大家都是在一个局域网里所以延迟很小高频通信能够更加精确反映游戏内状态）。由此带来什么糟糕的后果呢？
易竞技配图：销量很高但是口碑争议的BF4
易竞技配图：销量很高但是口碑争议的BF4
1.游戏体验的不连贯。BF4的客户端，和其它很多游戏一样有应用客户端预测法来补偿延迟。但是因为服务器更新的频率是在太慢了（0.1秒才更新一次，人类的反应时间差不多略小于0.1秒，即玩家已经可以感觉到其中的不连贯）。拿移动来举例吧，玩家正常的前进，突然玩家的延迟很短暂的增加了一下然后又回到正常，那么其中某一次移动的请求就会花更多的时间到达服务器。客户端这边因为没有收到服务器的通信而绘制了玩家前进的样子，0.1秒后服务器告知客户端实际的位移小于绘制的距离，客户端进行纠正（瞬间向后退），而0.1秒可以前进很大一段距离了（至少肉眼可以感觉出来有变化），如此瞬移回退让玩家感觉非常不舒服，即使延迟很小只要有变化就有可能发生这种情况。同样的情况适用于玩家看到的其他玩家所在的位置。在服务器中敌人的位置往往比客户端上显示的要滞后，因此很多时候明明瞄准了却打不中。相对的，如果提高通信频率，客户端“擅自”绘制的画面和服务器数据能够以更高的频率进行纠正，其中每次产生的变化都不会让玩家察觉。
2.“瞬间”击杀（Instant Kill）。BF4里的自动武器射速绝大多数都超过了600RPM（即每0.1秒一发），高射速武器如AEK971可以达到900RPM甚至更高，而大多数武器在近距离内都是造成25伤害（玩家满血100）。因此玩家A完全可以在0.1秒内发射至少2发子弹，在近距离内击杀生命值小于等于50的玩家B（这个边界值随射速提高而提高，如AKE971可以在0.1秒于近距离击杀生命小于等于75的玩家）。假设玩家A开始射击的一瞬间服务器刚好进行了一次对客户端的通信，玩家A在之后的两次发送射击请求都被服务器接收并判定（玩家B死亡），而一直到玩家A开火后的0.1秒内玩家B都没有接收到任何被攻击的信息。0.1秒后玩家B死亡，但玩家B的客户端只能绘制一次玩家A开火（虽然收到两次开火的信息），简单来说玩家B完全没有还手或者躲藏的机会，因为玩家B一直都认为自己没有受到攻击，只是在一瞬间就被A打死。对玩家A来说整个过程没有任何问题，而玩家B则是个冤大头。因此BF4已经失去了竞技的平衡性。
在BF4发布八个月后（没错，八个月，期间发布了数款BF4的DLC），发行商EA（果然不要脸）终于决定要修复这些问题。一开始他们决定吧BF4的服务器端通信频率提高到30Hz，但是BF4是一款复杂度远远超过其他FPS游戏的一款作品，30Hz的通信频率就已经让很多玩家的电脑吃不消了。后来采取了一个折中策略，玩家附近的游戏状态以30Hz的频率进行更新，而距离玩家较远的信息继续以10Hz的频率来更新。同时还提供一个选项允许客户端以更高的频率向服务器“索要”数据（当然其中造成的硬件负担不可小觑）。目前BF4的网络通信已经恢复到“可玩”的状态。根据某些资深玩家推测，BF4的服务器无法以超过30Hz的频率进行通信，主要原因是其引擎寒霜3内核有缺陷。因此BF4不太可能成为一款竞技游戏走向电竞舞台。
FPS游戏技术社区
网友评论