关于游戏的网络同步探索2
原文
https://www.zhihu.com/question/29076648/answer/43957516
链接：https://www.zhihu.com/question/29076648/answer/43726059
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
声明：下面会大量使用CSGO作为例子，这是因为Valve在多人游戏的网络通信方面做得较好，可以当做一个典型来分析。
========================================================
先讲多人竞技游戏中客户端和服务器是如何互动的吧
游戏中所有的逻辑判定都是由服务器完成的，客户端只负责发送请求和接收服务器的反馈，并把反馈具象化。拿CSGO做例子吧，比如你（玩家A）拿着AK瞄准了玩家B的头开了一枪，那么你的客户端会向服务器发送一个数据包，里面包含了谁（你）拿着什么武器（AK）从什么位置（你在地图上的坐标）向什么方向（角度）开了一枪。服务器收到后进行判定，这一枪的伤害会经过玩家B的头部模型，判定为爆头伤害，数值为104（这个值是瞎编的），因此判定玩家B死亡。然后向所有玩家的客户端通信，更新当前游戏状态，其中会包括玩家A用AK爆头击杀了玩家B，也会包括其他游戏信息，比如玩家的位置等等。你（玩家A）收到通信后再你的GUI上显示你击杀了玩家B，而玩家B则会收到被你击杀的信息。
接着讲一个概念，叫服务器的通信频率（tick rate）。事实上服务器不是实时地向玩家通信来更新游戏状态的，因为这样需要的计算量很大，同时对网络带宽的要求也会高的不现实。因此服务器会以一定的频率来进行通信。 CSGO在娱乐模式下通常采用60Hz的频率，也就是说每过1/60秒玩家的客户端就会收到一次新的信息。如果回到上面那个例子，那么实际情况应该是：你（玩家A）拿着AK瞄准了玩家B的头开了一枪，你的客户端会向服务器发送一个数据包，服务器接收后进行判定。判定完成后等待至下一次通信，再向所有玩家更新游戏状态。也就是说游戏过程其实是一个离散的过程而非连续过程。
=====================================================================
上面的例子都假设客户端和服务器之间的延迟无穷小。那么当玩家Ping很大的时候会发生什么的呢？假设你（玩家A）与服务器之间存在100ms的延迟（单向，往返则是200ms），其他玩家的延迟忽略不计，服务器的通信频率足够大（频率不够大还会造成其他很严重的问题，这个放在后面讲）。你在某一刻向服务器发送了一个请求（比如向前走），那么这个请求会在100ms之后到达服务器。服务器判定后返回结果，再经过100ms你的客户端会收到确认，服务器已经把你的位置向前移动了若干距离。假设客户端在没有收到任何服务器的更新前画面都不会变化，那么着200ms内你就会觉得游戏“卡顿”。
实际上在很多游戏里（比如CSGO）在这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应该存活。换句话说采用倒带法的服务器里如果有一个延迟很大的玩家将会拖累其他低延迟玩家的游戏体验。
----------------------------------------------------------------------------------------------------------------------------
Bonus：
前面的例子都是以服务器的通信频率足够高为前提的，下面简要描述一下低通信频率带来的问题。这里我要举的例子是大名鼎鼎的《战（和谐）地4》（下称BF4）。
BF4在刚刚发布的时候可谓是Bug满天飞整一个就是半成品，其中非常严重的就是网络通信问题（netcode issue）。根据制作组DICE提供的信息，BF4的通信频率是10Hz。这是一个相当低的设定了，大多数FPS的通信频率在30Hz左右，而CSGO为60Hz，电子竞技比赛时一般服务器的通信频率还会提高到120Hz（因为比赛时大家都是在一个局域网里所以延迟很小高频通信能够更加精确反映游戏内状态）。由此带来什么糟糕的后果呢？
1.游戏体验的不连贯。BF4的客户端，和其它很多游戏一样有应用客户端预测法来补偿延迟。但是因为服务器更新的频率是在太慢了（0.1秒才更新一次，人类的反应时间差不多略小于0.1秒，即玩家已经可以感觉到其中的不连贯）。拿移动来举例吧，玩家正常的前进，突然玩家的延迟很短暂的增加了一下然后又回到正常（也就是spike），那么其中某一次移动的请求就会花更多的时间到达服务器。客户端这边因为没有收到服务器的通信而绘制了玩家前进的样子，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已经死亡客户端只显示kill cam。 简单来说玩家B完全没有还手或者躲藏的机会，因为玩家B一直都认为自己没有受到攻击，只是在一瞬间就被A打死了。对玩家A来说整个过程没有任何问题，而玩家B则是个冤大头。此时的BF4已经失去了竞技的平衡性。
--------------------------------------------------------------------------------------------------
在BF4发布八个月后（没错，八个月，期间发布了数款BF4的DLC），发行商EA（果然不要脸）终于决定要修复这些问题。一开始他们决定吧BF4的服务器端通信频率提高到30Hz。然而BF4是一款复杂度远远超过其他FPS游戏的一款作品（64人，海陆空载具，弹道分析【BF里的子弹并非是在发射的瞬间就击中了敌人而是要经过一定的飞行时间才会击中，且还会受到重力影响而下坠】），30Hz的通信频率就已经让很多玩家的电脑吃不消了。后来采取了一个折中策略，玩家附近的游戏状态以30Hz的频率进行更新，而距离玩家较远的信息继续以10Hz的频率来更新。 同时还提供一个选项允许客户端以更高的频率向服务器“索要”数据（当然其中造成的硬件负担不可小觑）。目前BF4的网络通信已经恢复到“可玩”的状态。根据某些资深玩家推测，BF4的服务器无法以超过30Hz的频率进行通信，主要原因是其引擎寒霜3内核有缺陷。因此BF4不太可能成为一款竞技游戏走向电竞舞台。
=======================================================
更新（闲扯淡内容）：
感觉既然扯了BF4的低频通信那就再在战地系列里扩展一下吧。
最早出现低频（10Hz）通信的战地系列游戏是战地：叛逆连队2（BF:BC2），然后战地3（BF3）也沿用了一样通信频率。细心的玩家会发现自BFBC2以来所有的战地系列游戏使用的都是寒霜（Frostbite）引擎 （BFBC2是寒霜，BF3是寒霜2，BF4和战地：硬仗BFH是寒霜3）。使用低频和引擎的关系很大（如之前所述）。
我在这里想讲的是同样是使用低频通信，同样存在严重的网络通信问题，BFBC2被誉为神作被很多战地系列的老玩家奉为经典，而BF4被黑的死去活来（youtube上和Reddit论坛上甚至有针对DICE的檄文）的原因。
BFBC2是2009年发布的FPS游戏，是第一款使用寒霜引擎的多人FPS（当时也是DICE拿来卖引擎的作品，和孤岛危机类似）。在发布后立刻好评如潮，时至今日在北美依然有不少服务器在线供玩家游戏（包括其DLC越南）。当时很多玩家都没有注意到低频通信带来的问题，即使瞬杀等问题存在。这里最主要的一个原因在于BFBC2中武器的设定。
BFBC2中所有的武器（除去栓动狙击步枪和携带独头弹的泵动式霰弹枪）伤害都比较小，常规的突击步枪和卡宾枪通常需要5-7发（击中躯干）才能击杀一个满血的敌人，远距离需要更多，而轻机枪往往需要7法以上，但远距离伤害不减少。这主要带来的一个特征就是TTK（击杀时间）相对当时很多主流FPS游戏都要长（相比使命召唤，CS：S等，网游不考虑在内）。因此在10Hz的通信环境下，要出现和BF4中类似的瞬杀的情况条件苛刻很多（玩家的生命值必须非常低，而不是50%或者75%以下）。同时BFBC2中的武器射速普遍没有那么高（高射速应该是从BF3开始的），因而即使玩家生命值很低需要击杀的时间也可能会超过0.1秒，那么玩家就能够有足够的反应时间。另外BFBC2最多只允许32人同服游戏，近距离的接战没有那么混乱，玩家感觉到“莫名其妙就死了”的概率也低很多。
在BFBC2发布后的一段时间开始有玩家注意到了网络通信中的瑕疵，并尝试在youtube上制作视频进行说明，但并没有得到很多响应。说到底当时BFBC2绝对是跨时代的作品，其优秀的游戏品质和创新的设定让玩家对网络通信中的瑕疵更加宽容。试想一下，BFBC2是世界上第一款引入全场景可破坏的FPS游戏，是第一款强调步兵小队作战的战地游戏，是第一款主推快攻（rush）模式的FPS游戏（这个模式貌似还是只在战地系列中有，RO2和Insurgency有类似的模式但不同），玩家自然对其百般推崇。网络通信中的小瑕疵？没关系，玩的爽就行。
---------------------------------------------------------------------
到了BF4发布的时候，很多玩家怒了。
第一，BF4很大程度上只是BF3换了层皮，而且开发很不完善，bug很多（前面有提到），玩家对DICE极度不满，自然就有人出来挑刺。
第二，BF4武器射速以及伤害模型的问题，使得网络通信质量问题更加凸显，youtube上大量的视频都表明要复原通信问题比BFBC2简单很多。
