|
如果不是同步的话，游戏的公平性怎么保证呢？那些cf,cs的比赛是如何解决这个问题的？
声明：下面会大量使用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简单很多。 说起来EA和DICE也是脸皮很厚的，发布后八个月（之前提到过）才开始尝试修复。他们的理由是：“开发人员去度假了”。 网游技术发展真够慢的，怎么大家十年前在讨论同步问题，十年后还有人在讨论这个问题呢？何为延迟补偿？如何进行坐标差值？B客户端屏幕上A已经跑到东边了，但是收到服务器说“A正在西边往北跑”，B到底该何去何从？ 各位说了那么多DR，TimeWrap，LockStep，自己实现过没有？有产品上线没有？这些问题明明很简单，却总被形容得云山雾罩的，离落地编码还是那么的遥远。我若干年前的一个实现版本，将简明扼要的解决这个问题： -------------------------------------------------------------------------------------------------------------- 影子跟随算法由普通DR（dead reckoning）算法发展而来，我将其称为“影子跟随”意再表示算法同步策略的主要思想：
 前面的1号终端控制红色飞船P1向左飞，并把自己的状态时时告诉服务器 后面的2号终端上接收到飞船P1的影子S1的状态（向左移动），并让P1的实体追赶S1
使用该算法可以容易的开发出一款马里奥赛车，或者Counter Strike，详细说明见后： 算法比较：
相位滞后：可选参数，实体与影子保持一定距离同步，相当于保持一定车距，这样在控制者突然停止的时候，不容易因为网络延迟跑过了又被拉回来。 惯性移动：可选参数，开始移动或者停止或者改变方向都有加速度，这样就不需相位滞后了。 每次服务器向各个客户端同步时间的时候，由于延迟，所有客户端的时间都是慢于服务器的，这没有关系，只要大家在一定误差范围内以相同的速度增加，就完全没有问题。  图2 IDC网络响应 在公网平均130ms的Latency下，是不存在“完全的”的同步情况。如何通过消除/隐藏延时，将用户带入快速的交互式实时游戏中，体验完美的互动娱乐呢？
需要根据具体情况，分清楚哪些我们可以努力，哪些我们不值得努力，弄明白实时游戏中同步问题关键之所在，巧妙的化解与规避游戏，最终在适合普遍用户网络环境中(200ms)，实现实时快速互动游戏。 案例解析：Counter Strike 实现CS的话，首先我们需要给人物移动加上惯性，比如静止状态突然开始移动，那么需要0.5-1秒的加速过程，而移动中突然停止也需要0.5-1秒的减速过程，这样就实现了无差别同步，不需要相位滞后来避免拉扯影响用户感。 同时开枪射击采用客户端判断，也就是说如果我看见你在墙前面，开枪射中，那么我向服务器发送“我击中你了”，这时有可能真实的你在墙后，那么表现出来的就是我看见我打中你了（减不减血由服务段判断），而你没有看见我，觉得我穿墙打中你了。  图3 CS的同步逻辑 关键状态进行缓存，不然如果别人向前连续跳五次，每次取得状态都取到最高点的话，别人客户端上的影子和跟随的实体会奇怪的持续的飞在天上，所以需要将起跳和落地这两个关键状态缓存，实体追赶时只有追上的第一个状态（一号影子）才能追逐第二个状态（二号影子）。 由此可以在完全时间同步的情况下平滑的跑动、跳跃，开枪射击采用客户端判断后手感得到提高，唯一需要担心的就是外挂，外挂多是实时游戏的代价，只能通过Cheating Death等工具防止了。 案例解析：马里奥赛车 用该算法实现马里奥赛车是很简单的，影子和实体都使用惯性，由于赛车惯性很大，不容易有突变的状态更新，所以效果会比FPS游戏更好。 玩家碰到道具后，马上在屏幕上隐藏该道具的显示并通知服务器，由服务器决断道具属谁，由于刚碰到道具就隐藏所以不会有碰到道具却在一段时间内无法取得延迟现象。 游戏道具系统实现也很容易，比如那个将当前第一名炸毁的道具，它的描述是：原角色+对象角色+约定发生时间。既然知道对象是谁，什么时间发生，那就更本不需要怎么同步了，所有客户端和服务器在该时间让炸弹爆炸就得了，这种手法类似即时战略游戏。 游戏还有一类道具是可以发射的乌龟壳，这个东西属于有弹道的发射物，类似Quake里面的某些武器，需要作一些同步处理，基本特性是服务器判断起决定作用，客户端同步判断，如果客户端与服务器都判断集中，那就集中；如果客户端判断集中而服务器判断没有集中，那会看到该角色似乎被打了一下，但很快又恢复了速度向前冲。 由于赛车本身就具备惯性比较大的特点，因此同步效果是比较好的，可以在更大的延迟情况下表现得和FPS差不多（比如300ms效果相当于FPS的200ms）。 非可靠包： 该“影子跟随算法”支持非可靠传输协议，如果使用非可靠传输，那么我们按照特定频率（如每秒10次）定时发送状态更新，因为协议中每个更新包出了位置外还有速度、方向和时间，甚至还能加速加速度，因此我们丢一个包没有关系，可以根据后来的包重新计算插值。只有关键状态更新时才需要可靠传输，这就避免了TCP中丢包时RTO指数增长造成的延迟了。 负面情况： 该算法缺点就是无法向“帧间同步”算法那样，每次发送按键给服务器，服务器处理后再反馈结果，在局域网中（平均延迟<5ms），这样的效果相当于单机游戏一样即时，游戏性也能很复杂。然而在Internet中（平均延迟130ms，设计基准200ms，每秒最多发送10个数据包）该算法却不能像单机游戏那样有复杂的场景互动，有类似格斗游戏的即时的动作判定。 许多策划在设计实时动作游戏时很多设计我们都难以实现，这样因为策划不容易明白哪些我们能做，哪些我们不能做。即便程序员精通同步理论，策划也经常碰壁。 当多数设计被程序员回复“无法实现”后，策划只有采取一种消极设计（砍掉很多有意思的互动元素），于是网络游戏的表现力到今天还是差单机游戏一大截。 这些问题也并不能因为“影子跟随算法”的提出而得到改进，大于100ms的判定时间，都很难做到即时。 最后，该算法编码复杂度比其他同步策略高，因为服务器需要计算一份影子数据，各个客户端需要计算一份影子数据，还需要计算实体追赶，而这三种计算都需要在同样的时钟下保持一致，这就增加了编码与调试的复杂度。 总结话题： Internet特点是“高带宽，高延迟”，可以说从本质上Internet就不是为了游戏而设计的。故此Internet绝对意义的同步是不存在的。“影子跟随算法”的核心思想有几个：时钟同步，客户端先行，平滑追赶。通过这三个特性，我们能够在近似时间同步的情况下，模拟各种物体的移动过程，而使用该算法的前提是设计者需要根据各个游戏的特性研究不同的优化技巧，策略因游戏而变。 比如发送状态更新包时，不需要每次都发送，而可以只发送改变的状态。什么时候我们觉得改变了？就是当客户端实体与自己的影子之间的误差大于某特定数值时我们才发送更新包，这样虽然玩家在原地做左右摇摆的小幅度移动，只要没有超出范围，都不需要发送新的状态更新，其他玩家机器上看起来，它是站着不动的。 比如当发现某客户端5秒钟没有相应了，那么就将该人物的影子冻结住，永远不要为了等待某个数据而不让游戏进行下去。
本算法需要客户端与服务器维护相同的时钟，当每5分钟同步的时候，直接根据服务器的时钟替换当前时钟就行了，不需要重新计算所有影子的位置，因为后续的状态数据将会马上刷新这些状态。更不需要将测量到的PING值考虑进去，该算法与PING具体值无关。 当发现策划案子不可行时，寻找近似替代方案，比如减少“一次性的”“决定性的”事件发生，比如延长导弹在空中飞行的时间，比如将敌人加入HP分多次打死，而不是以及毙命，等等，都是大家可以发挥想象的地方。 相关例子： 文章相关DEMO如果有需要的话，可向我索要。 参考阅读： 韦易笑（2006），帧锁定算法 韦易笑（2005），网游同步法则 同一局游戏内，每个客户端和服务器都各自是一个独立的世界。理想情况下，所有世界都应该是同步的、一致的，在任一给定时刻，玩家在每个世界中的位置和姿态都应该是相同的。然而由于延迟的存在，这种理想情况却不可能实现！ 尤其在射击游戏中，因为射击游戏给玩家的反应时间极短，1秒就能决定生死，职业玩家甚至对10毫秒的延迟都会非常敏感，所以在游戏中如果人物的移动忽快忽慢，甚至还有位置瞬移，玩家的射击体验就会大打折扣。 今天我们邀请到了来自天美的游戏后台开发Walter，他将从技术角度分享自己解决延迟问题的经验：在射击游戏中，我们要如何与延迟抗争，做到更好的体验？  网游都是采用典型的C-S通信模式，客户端必须持续地与服务器通信才能正常运作，网络通信的round-trip time明显就是我们不想要的延迟。网络传输的丢包、重传等，都可以纳入网络延迟的范畴。 但游戏中的延迟远不止网络延迟这么简单，计算机系统（包括手机）的运作、游戏的实现机制都会引入延迟。 点击鼠标产生开火指令，这个电信号的传输、被系统捕获都需要时间，客户端逻辑线程通常要到下一帧才会开始处理这次输入，逻辑处理中抛事件到渲染线程，渲染线程最快也要下一帧才能去渲染结果，渲染结果要显示到屏幕上又受限于屏幕的刷新率。  可见，即使是没有网络的纯客户端游戏，延迟都不可避免地存在。很多游戏在实现中会用到Buffering技术，这还会进一步加剧延迟。 衡量游戏品质的一项重要指标就是玩家常说的“手感”，而手感的关键组成部分就是反馈的及时性。对于射击游戏、竞速游戏，玩家对手感有着极高的期待，职业玩家甚至能感知到10ms级别的延迟差距，所以游戏开发者都会在这方面下很大的功夫。 网络游戏中，网络延迟是延迟的主体部分，降低网络延迟是优化体验的关键，也是开发商都会重视的地方。例如，由Riot Games开发的第一人称射击游戏《Valorant》就做到了为70%玩家提供小于35ms的RTT。 网络包在传输中要经过复杂的路由，这导致了高延迟以及更多的不确定性。所以，有实力的厂商都会在网络基础设施上做投入，例如Riot有去搭建自己的ISP。这一点可以简单理解为：厂商会围绕玩家就近部署很多接入服务器，内部的服务器之间由专用的高速通道相连，就像修了很多专用的高速公路，所以整体的通信非常稳定、高效。  越来越多的游戏都从TCP转向了UDP，在剔除/简化了拥塞控制以后，包传输的及时性有了明显的提升，尤其是在弱网环境下。 由于UDP不可靠的特性，一般都会实现Reliable-UDP。实际游戏中，一般会混用可靠与不可靠的UDP，纯表现的消息、状态同步等可能会用不可靠的UDP，用户输入、逻辑事件等重要的信息则会用可靠的UDP。 网络游戏中，客户端和服务器几乎每一帧都在通信，玩家的操作永远来自于客户端，权威的信息永远来自于服务器。但网络通信是不稳定的，服务器可能连续5帧都没有收到客户端A的数，但在下一帧又一口气收到5个。这种输入的缺失和爆发增长会导致卡顿，导致不平滑的游戏体验。无论是帧同步还是状态同步，都会面对这个问题。 经典的解决办法是使用buffering机制：增加一个buffer，缓存几帧数据以后再以稳定的频率向业务系统提供输入。这个机制良好地解决了网络传输带来的输入抖动问题，网络视频播放器中一直在使用该技术。  很多游戏中都有用buffering机制，它确实让游戏变得平滑了，但却以增加延迟为代价。追求极致体验的游戏都不得不在buffer的大小上做折中，有的只存1帧的数据，有的甚至完全消除buffer。 缩小buffer的同时还要保证平滑的游戏体验，这意味着游戏要提供非常稳定的帧率、避免毛刺，还必须要在没有输入的情况下自己去预测玩家的行为。 假设玩家在持续地移动，客户端每帧都在上报移动指令，后来由于网络故障，服务器在几帧内都未收到新的移动指令，这时服务器要尽最大的努力去预测，从而使网络恢复以后 玩家的移动仍然是平滑的。 帧率的影响到底大不大？帧率高到一定值以后 是否值得继续提高？这是一个有一定争议的话题。 油管上有一个高帧率对玩家表现的对比测试，感兴趣的同学可以观看一下。  不管是否值得，但毫无疑问，更高的帧率必然是有好处的。帧率越高，系统运作的延迟就越低，响应越及时，表现也会更平滑、更自然。客户端帧率超过100的游戏并不少见，但服务器帧率几乎都小于64。服务器的帧率有必要更高吗？ Riot说有必要，《Valorant》的服务器是以128帧运行的，这让人印象深刻。客户端与服务器都在模拟角色的移动，它们的运算结果会无可避免地出现分歧。假设服务器是1秒1帧，两端位置的最大分歧是1米，然后被强制纠正到一致。若两端都是1秒128帧，两端位置的最大分歧可能就只有10厘米了，然后也被强制纠正到一致。 帧率高了就像是小步快跑，每次产生很小的误差，然后不断地纠正，所以整体的表现会很平滑。另一方面，即使某个客户端只以60帧的频率上报移动指令，其他9个客户端仍然可以以128帧的频率收到服务器下发的位置更新，所以 其他9个人看到的人物移动仍然是非常平滑的。 在《Valorant》中，客户端与服务器的移动和物理都是保持128帧运行的，这使得两端的每一帧都可以 一一 对应上，这极大地方便了服务端的命中判定，服务器只需把其他人的位置回退固定的帧数，就可以与客户端上的位置匹配。  高帧率缩短了系统运作的延迟，提供了更加平滑、细腻且一致的角色移动，这对FPS游戏是很有意义的。射击游戏给玩家的反应时间是极短的，1秒就决定了生死，职业玩家对10毫秒的延迟都很敏感。 每个人都是非常平滑地移动，这是很利于玩家追踪和预测对方移动轨迹的，所以玩家的射击体验会好很多。要是人物的移动忽快忽慢，甚至还有位置瞬移，玩家的射击体验就会大打折扣。 但是，一切皆有代价。要做到这样的高帧率本身就很困难，需要花很大的力气去优化性能。就算技术上做到了，服务器运行的成本也是非常高的。 帧同步要求每个客户端的运算输入严格一致，这样才能保证每个世界始终处于一样的状态。这意味着它们的输入一定来自于同一个服务器，意味着玩家输入到逻辑执行之间要包含网络延迟，这个延迟通常是几十毫秒，这会立即让玩家觉得“游戏的手感不好”。 FPS游戏大多都是使用状态同步，因为这样很容易做客户端预测，从而实现更好的及时性。玩家按键操作之后，客户端把该输入发给服务器，同时客户端本地直接处理该输入、产生部分结果/表现，而不用等待服务器的返回，这就是客户端预测。 服务器处理完输入以后会通知客户端结果，如果本地运算结果与服务器下发的不一致，肯定要以服务器的为准，故客户端要做纠错处理。 由于是状态同步，即使客户端本地计算出错了，也总是能恢复到一致的、正确的状态，UE引擎的移动同步就是这样做的。 对于网络游戏，重要的信息必须以服务器为准、不能客户端自主决定，否则会外挂泛滥，例如子弹命中的判定、造成的伤害量、技能的生效等等。但如果玩家的输入总是要等服务器返回后才给玩家反馈的话，玩家会觉得游戏的体验很差。公平性与及时性都很重要，但却存在冲突，需要我们做一些细致的特殊处理。 接下来，我们来看一个实际的例子（此处的例子节选自由微软发行的第一人称射击游戏系列《光环（Halo）》的分享）。假设玩家扔手雷的粗略过程如下：  按键是客户端行为，前摇动画可以看作是一段固定的延迟，飞出手雷代表施法的正确结束、产生了效果。 我们是网游，生成手雷这么重要的事情当然得服务器说了算，所以我们会很自然地这样做：  图中黄色的文字标记出了延迟的位置，玩家按键以后 隔一段时间才出现前摇动画，这体验当然是不可接受的，我们要更早地给玩家反馈。 想要及时反馈，可以在按键后直接播前摇动画，并且在时间结束后直接飞出手雷：  这违背了服务器做决策的原则，明显更无法接受。服务器上前摇过程还未走完，但客户端已经飞出手雷了，若服务器上前摇过程被他人打断，客户端必须要把已经飞出的手雷给删掉，这种诡异的表现会让玩家非常困惑和不满。 《Halo》最终的实现方案是：  按键后，客户端立即播放前摇动画，但等服务器流程结束后再通知客户端飞出手雷。相当于在客户端把前摇给拉长了。这样做解决了上述问题，提供了良好的用户体验： ● 玩家按键后立即获得了反馈，所以操作体验很好。 ● 手雷的生成遵从了服务器的权威，杜绝了被打断导致的奇怪表现。 ● 虽然手雷的飞出有延迟，但动画末尾的手臂占据了大部分画面，玩家几乎感知不到这个延迟。即使玩家发现了这个延迟，影响也不大。 另外一个例子，是《Halo》中释放无敌技能的过程。我们仍然期望按键后就立即播放前摇动画，但却不能再像上面一样延迟出现无敌效果。 因为无敌状态对施法者太重要了，晚0.1秒就可能是生与死的差别，玩家对这段延迟非常在意、几乎无法容忍。这时还可以把延迟藏在哪呢？  为了给施法者提供极致的体验，这里修改了游戏机制 —— 把服务器端的施法延迟给缩短了，即把网络延迟藏在了这里。 这种修改游戏机制的做法是特例，应该谨慎使用。虽然施法方的体验变好了，但对他的对手是不公平的。这里之所以可以这么做，是因为玩家普遍不能接受自己的无敌晚一点出现，但却相对能容忍对方的无敌早一点出现。 我们再来看看射击游戏中的经典问题 —— 命中判定。延迟的存在，使这个问题变得更加棘手。 子弹是否打中敌人、打中的部位是头还是脚，这些都是非常关键的信息。命中的判定可以在客户端做，然后服务器做校验，也可以只在服务器做。无论用哪种方式，我们都必须要面对一个事实：玩家屏幕上看到的敌人位置，很可能不是此刻敌人的真实位置，或者说不是其他世界中对方的位置。 同一局游戏内，每个客户端和服务器都各自是一个独立的世界。理想情况下 所有世界都应该是同步的、一致的，在任一给定时刻，玩家A在每个世界中的位置和姿态（Pose）都应该是相同的。但由于延迟的存在，这种理想情况永远都不可能实现！ 一个简化后的、现实中的模拟如下图：  一个框代表游戏运行的一帧，图中只画出了部分帧，并假设客户端与服务器的逻辑帧能稳定地一一对应。红线代表客户端上报的自己当前帧的位置/移动，蓝线代表服务器每帧下发的其他角色的位置/移动。假设A和B都在持续地移动： l t1时刻，客户端A把自己本帧移动的结果（PAe）上报给服务器，客户端B同样把PBe上报给服务器。 l t2时刻，服务器上A和B的位置分别为PAe和PBe。服务器把当前帧的位置信息同步给所有客户端。 l t3时刻，客户端A收到玩家B的位置为PBe，但自己已经移动到了PAi。 这是很多游戏的角色位置模拟过程，在任一时刻，客户端看到的自己的位置始终是领先于服务器的，但看到的其他人的位置又都是落后于服务器的。这导致——战斗中，我们始终是在用将来位置的自己去打过去位置的敌人。例如客户端A在t3时刻瞄准了B，并开枪射击，服务器收到射击事件时已经是第i帧了，但t3时刻和t4时刻 玩家B在服务器上的位置都不是PBe。 假设命中判定在客户端做，t3时刻客户端A认为自己打中了B，但服务器需要校验这一次射击的合法性，服务器收到射击事件时 玩家B的位置已经变成PBi了，这时服务器很可能认为A打不中B。把命中判定交给服务器来做，仍然有同样的问题。 不同世界间的不同步是由延迟导致的，延迟导致的结果是：只要敌人持续在移动，并且移动速度比较快，你瞄准后的射击永远也打不中敌人。 解决命中问题的经典方案是 —— 服务器做玩家位置回退。服务器记录一段时间内每个人的历史位置和Pose，收到A的射击事件时，服务器把A之外的所有玩家都挪回到一个恰当的历史位置去，使服务器上其他人的位置与A看到的其他人位置基本一致。这样，客户端上能打中的 服务器上就也能打中了。如图所示：  但这种方案也有问题：它对被打的那一方不公平。例如t3时刻，玩家B明明已经躲起来了，在客户端B的世界里 玩家A是打不到自己的（位置PAe与位置PBi），结果你t3时刻的开火还是打死了自己。 要解决这个问题，一般是给回退的时长加一个约束，例如最多只允许回退一个RTT。 UE4默认的移动同步过程是：客户端和服务器都模拟角色的移动，客户端每帧上报自己移动后的结果和当前的移动输入，服务器收到移动输入后也去模拟移动。 若服务器的移动结果与客户端上报的结果误差在一定容忍范围内，则直接采纳客户端的结果，使服务器上玩家的位置等于客户的上报的位置。若误差超出了容忍范围，则以服务器为准，强制重置客户端的位置。 当容忍范围设置得较大的时候，服务器上会大幅度重置角色的位置，当同步到其他客户端以后，这个角色的移动必然会出现波动，要么是直接位置重置，要么是插值过去（加速移动过去）。无论用哪种处理方式，最终的结果都是：一个玩家B卡了，然后其他9个人看到的B的移动都是不平滑的。 Valorant认为：一个人卡了，却导致其他9个人的瞄准体验变差了，这是不可接受的。对应方案是：若服务器未收到移动输入，仍然根据当前的状态每帧做预测，当出现分歧时始终以服务器的模拟为准，并且每帧都下发角色的位置。 这样做，无论个人怎么卡，其他9个人看到的角色移动始终是平滑的，但卡的那个人自己会被频繁地拉扯。 这是战术射击游戏的经典话题，玩家在转角处来回晃悠可以获得先手优势（会先看到对方），是一种网络延迟导致的不公平现象。  如图所示，冲出角落的人会先看到对方，而蹲角落的人明显要晚一些看到对方。说明：这里是用了比较大的ping值来演示该效果，实际中不一定有这么明显。 产生这个问题的本质原因就是网络延迟，正如上面已经讲过的：若是自己在移动，自己客户端上自己的位置是领先于其他所有世界的，而静止不动的人的位置在所有世界中都是一致的。移动的人的位置要同步到其他客户端，这是需要经过网络传输的：  这个优势其实是可以用数学公式来描述的：  如图，holder要想打赢对方，就必须要在server applies kill shot之前把开火指令发送到服务器，这样才能实现比peeker先开火。进而可以得到这样的关系： holder reaction time < peeker reaction time - (holder RTT + holder buffering latency + server buffering latency) 所以peeker方领先的时间主要取决于holder方的网络延迟，以及buffering延迟。 更进一步，我们可以带入具体的数字来量化这个优势。按帧率60、单边通信30ms延迟来算，peeker方大约可以获得140ms的先手优势。 ① 降低网络延迟。无非就是就近部署、搭建高速专用网络、使用UDP，上面已经讲过了。 ② 降低buffering延迟。最小化buffer大小，上面也已经讲过了。 ③ 高帧率也是有帮助的。在Valorant中，如果客户端能跑140帧的话，这个差值可以降低到71ms。 技术上没办法彻底杜绝这个问题，而且也很难取得明显的改善，至少代价是很大的。但从设计上 我们有很多方法来优化它： ● 地图设计：例如一个区域只留一两个进入的入口（供他人peek around），但场地内有多个地方可以设伏、蹲守入口。这样的设计使得holder的位置高度不确定，但peeker的位置高度确定，变相地增加了peeker方的难度。 ● 降低移动中射击的准确率。在这一点上每个游戏的取舍都不同，Valorant在这方面做得比较狠，移动中几乎很难打中。 ● 让peeker的身体先暴露，但相机晚一点暴露。这使得peeker先暴露出自己的部分身体，然后相机才能看到holder。人的移速慢一点、系统运行帧率高一点、身体做大一点，都会有利于peeker先暴露出部分身体。 第六节摘自《Halo》的GDC分享：https://youtu.be/h47zZrqjgLc(责任编辑：蚂蚁团队) |