《守望先锋》架构设计与网络同步

标签：取消   转换   逻辑   流程   屏幕渲染   叠加   依赖   射击游戏   工作方式   

原文链接

《守望先锋》架构设计与网络同步

Overwatch Gameplay Architecture and Netcode

Timothy Ford

Lead Gameplay Engineer

Blizzard Entertainment

翻译：kevinan

在GDC2017【Overwatch Gameplay Architecture andNetcode 】的分享会上，来自暴雪的Tim Ford介绍了《守望先锋》游戏架构和网络同步的设计。一起来看看吧。

          哈喽，大家好，这次的分享是关于《守望先锋》（译注：下文统一简称为Overwatch）游戏架构设计和网络部分。老规矩，手机调成静音；离开时记得填写调查问卷；换下半藏，赶紧推车！（众笑）

          我是Tim Ford，是暴雪公司Overwatch开发团队老大。自从2013年夏季项目启动以来就在这个团队了。在那之前，我在《Titan》项目组，不过这次分享跟Titan没有半毛钱关系。（众笑）

          这次分享的一些技术，是用来降低不停增长的代码库的复杂度（译注，代码复杂度的概念需要读者自行查阅）。为了达到这个目的我们遵循了一套严谨的架构。最后会通过讨论网络同步（netcode）这个本质很复杂的问题，来说明具体如何管理复杂性。

          Overwatch是一个近未来世界观的在线团队英雄射击游戏，它的主要是特点是英雄的多样性， 每个英雄都有自己的独门绝技。

Overwatch使用了一个叫做“实体组件系统”的架构，接下来我会简称它为ECS。

          ECS不同于一些现成引擎中很流行的那种组件模型，而且与90年代后期到21世纪早期的经典Actor模式区别更大。我们团队对这些架构都有多年的经验，所以我们选择用ECS有点是“这山望着那山高”的意味。不过我们事先制作了一个原型，所以这个决定并不是一时冲动。

开发了3年多以后，我们才发现，原来ECS架构可以管理快速增长的代码复杂性。虽然我很乐意分享ECS的优点，但是要知道，我今天所讲的一切其实都是事后诸葛亮 。

ECS架构概述

          ECS架构看起来就是这样子的。先有个World，它是系统（译注，这里的系统指的是ECS中的S，不是一般意义上的系统，为了方便阅读，下文统称System）和实体(Entity)的集合。而实体就是一个ID，这个ID对应了组件(Component)的集合。组件用来存储游戏状态并且没有任何的行为(Behavior)。System有行为但是没有状态。

这听起来可能挺让人惊讶的，因为组件没有函数而System没有任何字段。

ECS引擎用到的System和组件

          图的左手边是以轮询顺序排列的System列表，右边是不同实体拥有的组件。在左边选择不同的System以后，就像弹钢琴一样，所有对应的组件会在右边高亮显示，我们管这叫组件元组（译注，元组tuple，从后文来看，主要作用就是可以调用Sibling函数来获取同一个元组内的组件，有点虚拟分组的意思）。

System遍历检查所有元组，并在其状态（State）上执行一些操作（也就是行为Behavior）。记住组件不包含任何函数，它的状态都是裸存储的。

          绝大多数的重要System都关注了不止一个组件，如你所见，这里的Transform组件就被很多System用到。

来自原型引擎里的一个System轮询(tick)的例子

          这个是物理System的轮询函数，非常直截了当，就是一个内部物理引擎的定时更新。物理引擎可能是Box2d或者是Domino（暴雪自有物理引擎）。执行完物理世界的模拟以后，就遍历元组集合。用DynamicPhysicsComponent组件里保存的proxy来取到底层的物理表示，并把它复制给Transform组件和Contact组件（译注：碰撞组件，后文会大量用到）。

System不知道实体到底是什么，它只关心组件集合的小切片(slice，译注：可以理解为特定子集合)，然后在这个切片上执行一组行为。有些实体有多达30个组件，而有些只有2、3个，System不关心数量，它只关心执行操作行为的组件的子集。

像这个原型引擎里的例子，（指着上图7中）这个是玩家角色实体，可以做出很多很酷的行为，右边这些是玩家能够发射的子弹实体。

每个System在运行时，不知道也不关心这些实体是什么，它们只是在实体相关组件的子集上执行操作而已。

Overwatch里的(ECS架构的)实现，就是这样子的。

EntityAdmin是个World，存储了一个所有System的集合，和一个所有实体的哈希表。表键是实体的ID。ID是个32位无符号整形数，用来在实体管理器（Entity Array）上唯一标识这个实体。另一方面，每个实体也都存了这个实体ID和资源句柄（resource handle），后者是个可选字段，指向了实体对应的Asset资源（译注：这需要依赖暴雪的另一套专门的Asset管理系统），资源定义了实体。

组件Component是个基类，有几百个子类。每个子类组件都含有在System上执行Behavior时所需的成员变量。在这里多态唯一的用处就是重载Create和析构（Destructor）之类的生命周期管理函数。而其他能被继承组件类实例直接使用的，就只有一些用来方便地访问内部状态的helper函数了。但这些helper函数不是行为(译注：这里强调是为了遵循前面提到的原则：组件没有行为)，只是简单的访问器。

EntityAdmin的结尾部分会调用所有System的Update。每个System都会做一些工作。上图9就是我们的使用方式，我们没有在固定的元组组件集合上执行操作，而是选择了一些基础组件来遍历，然后再由相应的行为去调用其他兄弟组件。所以你可以看到这里的操作只针对那些含有Derp和Herp组件的实体的元组执行。

Overwatch客户端的System和组件列表

          这里有大概46不同的System和103个组件。这一页的炫酷动画是用来吸引你们看的（众笑）。

然后是服务器

你可以看到有些System执行需要很多组件，而有些System仅仅需要几个。理想情况下，我们尽量确保每个System都依赖很多组件去运行。把他们当成纯函数(译注，pure function，无副作用的函数)，而不改变（mutating）它们的状态，就可以做到这一点。我们的确有少量的System需要改变组件状态，这种情况下它们必须自己管理复杂性。

下面是个真实的System代码

          这个System是用来管理玩家连接的，它负责我们所有游戏服务器上的强制下线（译注，AFK, Away From Keyboard，表示长时间没操作而被认为离线）功能。

这个System遍历所有的Connection组件（译注：这里不太合适直接翻译成“连接”），Connection组件用来管理服务器上的玩家网络连接，是挂在代表玩家的实体上的。它可以是正在进行比赛的玩家、观战者或者其他玩家控制的角色。System不知道也不关心这些细节，它的职责就是强制下线。

          每一个Connection组件的元组包含了输入流(InputStream)和Stats组件（译注：看起来是用来统计战斗信息的）。我们从输入流组件读入你的操作，来确保你必须做点什么事情，例如键盘按键；并从Stats组件读取你在某种程度上对游戏的贡献。

你只要做这些操作就会不停重置AFK定时器，否则的话，我们就会通过存储在Connection组件上的网络连接句柄发消息给你的客户端，踢你下线。

          System上运行的实体必须拥有完整的元组才能使得这些行为能够正常工作。像我们游戏里的机器人实体就没有Connection组件和输入流组件，只有一个Stats组件，所以它就不会受到强制下线功能的影响。System的行为依赖于完整集合的“切片”。坦率来说，我们也确实没必要浪费资源去让强制机器人下线。

为什么不能直接用传统面向对象编程模型？

上面System的更新行为会带来了一个疑问：为什么不能使用传统的面向对象编程(OOP)的组件模型呢？例如在Connection组件里重载Update函数，不停地跟踪检测AFK？

答案是，因为Connection组件会同时被多个行为所使用，包括：AFK检查；能接收网络广播消息的已连接玩家列表；存储包括玩家名称在内的状态；存储玩家已解锁成就之类的状态。所以（如果用传统OOP方式的话）具体哪个行为应该放在组件的Update中调用？其余部分又应该放在哪里？

传统OOP中，一个类既是行为又是数据，但是Connection组件不是行为，它就只是状态。Connection完全不符合OOP中的对象的概念，它在不同的System中、不同的时机下，意味着完全不同的事情。

那么把行为和状态区分开，又有什么理论上的优势（conceptual advantages）呢？

          想象一下你家前院盛开的樱桃树吧，从主观上讲，这些树对于你、你们小区业委会主席、园丁、一只鸟、房产税官员和白蚁而言都是完全不同的。从描述这些树的状态上，不同的观察者会看见不同的行为。树是一个被不同的观察者区别对待的主体（subject）。

类比来说，玩家实体，或者更准确地说，Connection组件，就是一个被不同System区别对待的主体。我们之前讨论过的管理玩家连接的System，把Connection组件视为AFK踢下线的主体；连接实用程序(ConnectUtility)则把Connection组件看作是广播玩家网络消息的主体；在客户端上，用户界面System则把Connection组件当做记分板上带有玩家名字的弹出式UI元素主体。

Behavior为什么要这么搞？结果看来，根据主体视角区分所有Behavior，这样来描述一棵树的全部行为会更容易，这个道理同样也适用于游戏对象(game objects)。

然而随着这个工业级强度的ECS架构的实现，我们遇到了新的问题。

首先我们纠结于之前定下的规矩：组件不能有函数；System不能有状态。显而易见地，System应该可以有一些状态的，对吧？一些从其他非ECS架构导入的遗留System都有成员变量，这有什么问题吗？举个例子，InputSystem, 你可以把玩家输入信息保存在InputSystem里，而其他System如果也需要感知按键是否被按下，只需要一个指向InputSystem的指针就能实现。

在单个组件里存储一个全局变量看起来很很愚蠢，因为你开发一个新的组件类型，不可能只实例化一次(译注：这里的意思是，如果实例化了多次，就会有多份全局变量的拷贝，明显不合理)，这一点无需证明。组件通常都是按照我们之前看见过的那种方式（译注：指的是通过ComponentItr<>函数模板那种方式）来迭代访问，如果某个组件在整个游戏里只有一个实例，那这样访问就会看起来比较怪异了。

无论如何，这种方式撑了一阵子。我们在System里存储了一次性（one-off）的状态数据，然后提供了一个全局访问方式。从图16可以看到整个访问过程（译注：重点是g_game->m_inputSystem这一行）。

如果一个System可以调用另外一个System的话，对于编译时间来说就不太友好了，因为System需要互相包含（include）。假定我现在正在重构InputSystem，想移动一些函数，修改头文件(译注：Client/System/Input/InputSystem.h)，那么所有依赖这个头文件去获取输入状态的System都需要被重新编译，这很烦人，还会有大量的耦合，因为System之间互相暴露了内部行为的实现。（译注：转载不注明出处，真的大丈夫吗？还把译者的名字都删除！声明：这篇文章是本人kevinan应GAD要求而翻译！）

从图16最下面可以看见我们有个PostBuildPlayerCommand函数，这个函数是InputSystem在这里的主要价值。如果我想在这个函数里增加一些新功能，那么CommandSystem就需要根据玩家的输入，填充一些额外的结构体信息发给服务器。那么我这个新功能应该加到CommandSystem里还是PostBuildPlayerCommand函数里呢？我正在System之间互相暴露内部实现吗？

随着系统的增长，选择在何处添加新的行为代码变得模棱两可。上面CommandSystem的行为填充了一些结构体，为什么要混在一起？又为什么要放到这里而不是别处？

      这些代码确保了像弹孔、焦痕持久特效不会很奇怪的叠在一起。例如，你用猎空的枪去射击一面墙，留下了一堆麻点，然后法老之鹰发出一枚火箭弹，在麻点上面造成了一个大面积焦痕。你肯定想删了那些麻点，要不然看起来会很丑，像是那种深度冲突（Z-Fighting）引起的闪烁。我可不想在到处去执行那个删除操作，最好能在一处搞定。

          我得修改代码了，但是看上去好多啊，调用点一大堆，改完了以后每一处都需要测试。而且以后英雄越来越多，每个人都需要新的特效。然后我就到处复制粘贴这个函数的调用，没什么大不了的，不就是个函数调用嘛，又不是什么噩梦。（众笑）

          其实这样做以后，会在每个调用点都产生副作用的。程序员就得花费更多脑力来记住这段代码是如何运作的，这就是代码复杂度所在，肯定是应该避免的。

          于是我们有了Contact单例。

          它包含了一个未决的碰撞记录的数组，每个记录都有足够的信息，来在本帧的晚些时候创建那个特效。如果你想要生成一个特效的时候，只需要添加一条新记录并填充数据就可以了。等运行到帧的后期，进行场景更新和准备渲染的时候，ResolveContactSystem会遍历数组，根据LOD规则生成特效并互相叠加。这样的话，即使有严重的副作用，在每一帧也只是发生在一个调用点而已。

          除了降低复杂度以外，“推迟”方案还有很多其他优点。数据和指令都缓存在本地，可以带来性能提升；你可以针对特效做性能预算了，例如你有12个D.VA同时在射墙，她们会带来数百个特效，你不用立即创建全部这些特效，你可以仅仅创建自己操纵的D.VA的特效就可以了，其他特效可以在后面的运算过程中分摊开来，平滑性能毛刺。这样做有很多好处，真的，你现在可以实现一些复杂的逻辑了。即使ResolveContactSystem需要执行多线程协作，来确定单个粒子效果的朝向， 现在也很容易做。“推迟”技术真的很酷。

Utility函数，单例，推迟，这些都只是我们过去3年时间建立ECS架构的一小部分模式。除了限制System中不能有状态，组件里不能有行为以外，这些技术也规定了我们在Overwatch中如何解决问题。

遵守这些限制意味着你要用很多奇技淫巧来解决问题。不过，这些技术最终造就了一个可持续维护的、解耦合的、简洁的代码系统。它限制了你，它把你带到坑里，但这是个“成功之坑”。

学习了这些之后呢，咱们来聊聊真正的难题之一，以及ECS是如何简化它的。

作为gameplay(游戏玩法，机制)工程师，我们解决过的最重要的问题就是网络同步（netcode）。

这里先说下目标，是要开发一款快速响应（responsive）的网络对战动作游戏。为了实现快速响应，就必须针对玩家的操作做预测（predict，也可以说是预表现）。如果每个操作都要等服务器回包的话，就不可能有高响应性了。尽管因为一些混蛋玩家作弊所以不能信任客户端，但是已经20年了，这条FPS游戏真理没变过。

          游戏中有快速响应需求的操作包括：移动，技能，就我们而言还有带技能的武器，以及命中判定（hit registration）。

这里所有的操作都有统一的原则：玩家按下按键后必须立即能够看到响应。即使网络延迟很高时也必须是如此。

像我这页PPT中演示的那样，ping值已经250ms了，我所有的操作也都是立即得到反馈的，“看上去”很完美，一点延迟都没有。

然而呢，带预测的客户端，服务器的验证和网络延迟就会带来副作用：预测错误（misprediction，或者说预测失败）了。预测错误的主要症状就一点，会使得你没能成功执行“你认为你已经做出的”操作。

虽然服务器需要纠正你的操作，但代价并不会是操作延迟。我们会用”确定性”（Determinism）来减少预测错误发生的概率，下面是具体的做法。

          前提条件不变，PING值还是250毫秒。我认为我跳起来了，但是服务器不这么看，我被猛拉回原地，而且被冻住了（冰冻是英雄Mei的技能之一）。这里（PPT中视频演示）你甚至可以看到整个预测的工作过程。预测过程开始时，试图把我们移到空中，甚至大猩猩跳跃技能的CD都已经进入冷却了，这是对的，我们不希望预测准确率仅仅是十之八九。所以我们希望尽可能的快速响应，

如果你碰巧在斯里兰卡玩这个游戏，而且又被Mei冻住了，那么就有可能会预测错误。

下面我会首先给出一些准则，然后讨论一下这个崭新的技术是如何利用ECS来减少复杂度的。

          这里不会涉及到通用的数据复制技术、远端实体插值（remote entity interpolation）或者是向后缓和（backwardsreconciliation）技术细节。

我们完全是站在巨人的肩膀上，使用了一些其他文献中提过的技术而已。后面的幻灯片会假定大家对那些技术都已经很熟悉了。

确定性(Determinism)

          确定性模拟技术依赖于时钟的同步，固定的更新周期和量化。服务器和客户端都运行在这个保持同步的时钟和量化值之上。时间被量化成command frame，我们称之为“命令帧”。每个命令帧都是固定的16毫秒，不过在电竞比赛时是7毫秒。

          模拟过程的频率是固定的，所以需要把计算机时钟循环转换为固定的命令帧序号。我们使用了一个循环累加器来处理帧号的增长。

在我们的ECS框架内，任何需要进行预表现、或者基于玩家的输入模拟结果的System，都不会使用Update，而是用UpdateFixed。UpdateFixed会在每个固定的命令帧调用。

          假定输出流是稳定的，那么客户端的始终总是会超前于服务器的，超前了大概半个RTT加上一个缓存帧的时长。这里的RTT是PING值加上逻辑处理的时间。上图39的例子中，我们的RTT是160毫秒，一半就是80毫秒，再加上1帧，我们每帧是16毫秒，全加起来就是客户端相对于服务器的提前量。

          图中的垂直线代表每一个处理中的帧。客户端开始模拟并把第19帧的输入上报给服务器，过一段时间（基本上是半个RTT加上缓冲时间）以后，服务器才开始模拟这一帧。这就是我为什么要说客户端永远是领先于服务器的。

          正因为客户端是一股脑的尽快接受玩家输入，尽可能地贴近现在时刻，如果还需要等待服务器回包才能响应的话，那看起来就太慢了，会让游戏变得卡顿。图39中的缓冲区，你肯定希望尽可能的小（译注：缓冲越小，模拟时就越接近当前时刻），顺便说一句，游戏运行的频率是60赫兹，我这里播放动画的速度是正常速度的百分之一（译注：这也是为了让观众看得更清晰、明白）。

客户端的预测System读取当前输入，然后模拟猎空的移动过程。我这里是用游戏摇杆来表示猎空的输入操作并上报的。这里的（第14帧）猎空是我当前时刻模拟出来的运动状态，经过完整的RTT加上缓冲事件，最终猎空会从服务器上回到客户端（译注：这里最好结合演讲视频，静态的文章无法表达到位）。这里回来的是经过服务器验证的运动状态快照。服务器模拟权威带来的副作用就是验证需要额外的半个RTT时间才能回到客户端。

那么这里客户端为什么要用一个环形缓冲（ring buffer）来记录历史运动轨迹呢？这是为了方便与服务器返回的结果进行对比。经过比较，如果与服务器模拟结果相同，那么客户端会开开心心地继续处理下一个输入。如果结果不一致，那就是一个“预测错误”，这时就需要“和解”（reconcile）了。

如果想简单，那就直接用服务器下发的结果覆盖客户端就行了，但是这个结果已经是“旧”（相对于当前时刻的输入来讲）的了，因为服务器的回包一般都是几百毫秒之前的了。

除了上面那个环形缓冲以外，我们还有另一个环形缓冲用来存储玩家的输入操作。因为处理移动的代码是确定性的，一旦玩家开始进入他想要进入到移动状态，想要重现这个过程也是很容易的。所以这里我们的处理方式就是，一旦从服务器回包发现预测失败，我们把你的全部输入都重播一遍直至追上当前时刻。如下图41中的第17帧所示，客户端认为猎空正在跑路，而服务器指出，你已经被晕住了，有可能是受到了麦克雷的闪光弹的攻击。

接下来的流程是，当客户端收到描述角色状态的数据包时，我们基本上就得把移动状态及时恢复到最近一次经过服务器验证过状态上去，而且必须重新计算之后所有的输入操作，直至追上当前时刻（第25帧）。

          现在客户端进行到第27帧（上图）了，这时我们收到了服务器上第17帧的回包。一旦重新同步（译注：注意下图41中客户端猎空的状态全都更正为“晕”了）以后，就相当于回退到了“帧同步”（lockstep）算法了。

我们肯定知道我们到底被晕了多久。

      到了下图第33帧以后，客户端就知道已经不再是晕住的状态了，而服务器上也正在模拟相同的情况。不再有奇怪的同步追赶问题了。一旦进入这个移动状态，就可以重发玩家当前时刻的操作输入了。

          然而，客户端网络并不保证如此稳定，时有丢包发生。我们游戏里的输入都是通过定制化的可靠UDP实现。所以客户端的输入包常常无法到达服务器，也就是丢包。服务器又试图保持了一个小小的、保存未模拟输入的缓冲区，但是让它尽量的小，以保证游戏操作的流畅。

          一旦这个缓冲区是空的，服务器只能根据你最后一次输入去“猜测”。等到真正的输入到达时，它会试着“缓和”，确保不会弄丢你的任何操作，但是也会有预测错误。

          下面是见证奇迹的时刻。

          上图可以看到，已经丢了一些来自客户端的包，服务器意识到以后，就会复制先前的输入操作来就行预测，一边祈祷希望预测正确，一边发包告诉客户端：“嘿哥们，丢包了，不太对劲哦”。接下来发生的就更奇怪的了，客户端会进行时间膨胀，比约定的帧率更快地进行模拟。

这个例子里，约定好的帧速是16毫秒，客户端就会假装现在帧速是15.2毫秒，它想要更加提前。结果就是，这些输入来的越来越快。服务器上缓冲区也会跟着变大，这就是为了在尽量不浪费的情况下，度过（丢包的）难关。

这种技术运转良好，尤其是在经常抖动的互联网环境下，丢包和PING都不稳定。即使你是在国际空间站里玩这个游戏，也是可以的。所以我想这个方案真的很NB。

现在，各位都记个笔记吧，这里收到消息，现在开始放大时间刻度，注意我们是真的加速轮询了，你可以看见图中右边的坡越来越平坦了。它比以前更加快速地上报输入。同时服务器上的缓冲也越来越大了，可以容忍更多地丢包，如果真的发生丢包也有可能在缓冲期间补上。

          一旦服务器发现，你现在的网络恢复健康了，它就会发消息给你说：“嘿哥们，现在没事了”。而客户端会做相反的事情：它会缩小时间刻度，以更慢的速度发包。同时服务器会减小缓冲区的尺寸。

如果这个过程持续发生，那目标就会是是不要超过承受极限，并通过输入冗余来使得预测错误最小化。

早些时候我有提到过，服务器一旦饥饿，就会复制最后一次输入操作，对吧？一旦客户端赶上来了，就不会再复制输入了，这样会有因为丢包而被忽略的风险。解决方法是，客户端维持一个输入操作的滑动窗口。这项技术从《雷神世界》开始就有了。

我们不是仅仅发送当前第19帧的输入，而是把从最后一次被服务器确认的运动状态到现在的全部输入都发送过去。上面的例子可以看出，最后一次从服务器来的确认是第4帧。而我们刚刚模拟到了第19帧。我们会把每一帧的每一个输入都打包成为一个数据包。玩家一般顶多每1/60秒才会有一次操作，所以压缩后数据量其实不大。一般你按住“向前”按钮之前，很可能是已经在“前进”了。

结果就是，即使发生丢包，下一个数据包到达时依然会有全部的输入操作，这会在你真正模拟以前，就填充上所有因为丢包而出现的空洞。所以这个反馈循环的过程和可增长的缓冲区大小，以及滑动窗口，使得你不会因为丢包而损失什么。所以即使丢包也不会出现预测错误。

接下来会再次给你展示动画过程，这一次是双倍速，是正常速度的1/50了。

          这里有全部不稳定因素：网络PING值抖动，有丢包，客户端时间刻度放大，输入窗口填充了全部漏洞，有预测失败，有服务器纠正。我们它们都合在一起播放给你看。

          接下来的议题，我不想讲太多细节，因为这是Dan Reid的分享的主题(译注，已经翻译)，因为这是开幕式的一部分，所以强烈推荐各位听一下，真的很棒。还是在这个房间，我讲完了就开始。

          所有的技能都是用暴雪自有指令式脚本语言Statescript开发的。脚本系统的一大优点就是它可以在前后穿越时空。在客户端预测，然后服务器验证，就像之前的例子里面的移动操作，我们可以把你回滚然后重播所有输入。技能也使用了与移动相同的前后滚原则，先回退到最后一次经过验证的快照的状态，然后重播输入直到当前时刻。

大家肯定还记得这个例子，就是猎空被晕导致的服务器纠正过程，技能的处理过程是相同的。客户端和服务器都会模拟技能执行的确定性过程，客户端领先于服务器，所以一般是客户端先模拟，服务器稍后跟进。客户端处理预测错误的方式是，先根据服务器快照回滚，然后再前滚（roll forth），就像这样幻灯演示的动画过程那样。这里演示的是死神的幽灵形态。图45中的这些方块（译注：Statescript中的State）代表了幽灵形态，有了这些方块我就可以很自信的播放很酷的特效和动画了。

幽灵形态结束后就会关闭这些方块。在同一帧中这些小动画会展示出State的关闭过程。紧接着就是幽灵形态的出现，不久以后我们就会得到来自服务器的消息：“嗨，我预测的幽灵形态的过程已经告诉你了，所以你赶紧倒退回去，把这些State都打开，然后咱们再重新模拟全部输入，把这些State都关了”。这基本上就是每次服务器下发更新时回滚和前滚的过程了。

能预测移动很酷，这意味着可以预测每个技能，我们也确实这样做了，同样，对于武器或者其他的模块，我们也可以这么做。

现在讨论一下命中判定的预测和确认。

          ECS处理这个其实很方便，还记得吗，实体如果拥有行为所需的组件元组，它就会是这个行为的主体。如果你的实体是敌对的（还记得我们之前讲的敌对性检查吧）而且你有一个ModifyHealthQueue组件，你就可以被别的玩家击中，这都受制于“命中判定”。

          这两个组件，一个是用来检查敌对性的，一个是ModifyHealthQueue。ModifyHealthQueue是服务器记录的你身上的全部伤害和治疗。与单例Contact类似，也是延迟计算的，而且有多个调用点，这就是最大的副作用。延迟计算是因为不想在抛射物模拟途中，立即生成一大堆特效，我们选择延后。

顺便说一句，伤害，也完全不会在客户端预测，因为它们全都是骗子。

然而命中判定却是在客户端处理的。所以，如果你有一个MovementState组件，而且是一个不会被本地玩家操纵的remote对象，那你会被运动 System经过插值（interpolate）运算来重新定位。标准插值是发生在最后一次收到的两个MovementState之间的，这项技术自从《Quake》时代就有了。

System根本不在乎你是一个移动平台、炮台、门还是法老之鹰，你只需要拥有一个MovementState组件就够了，MovementState组件还要负责存储环形缓冲区，还记得环形缓冲嘛？之前用来保存那些猎空小人的位置的。

有了MovementState组件，服务器在计算命中以前，就会把你回滚到攻击者上报时你所在的那一帧，这就是向后缓和（backwards reconcilation）。这一切都与ModifyHealthQueue组件正交， ModifyHealthQueue组件决定了是否接受伤害。我们还需要倒回门、平台、车的状态，如果子弹被挡住了的话，就无所谓了。一般来说如果你是敌对的，而且有MovementState组件，你就会被倒回，而且可能会受伤。

          被倒回（rewind）是被一组Utility函数操纵的行为；而受伤是MovementState组件被延迟处理时发生的另外一个行为。这两种行为独立开来，各自发生在各自的组件切片上。

          射击过程有点抽象，我这里会分解一下。

          图47中的框是每一个实体的逻辑边界（bounding volumes）。逻辑边界基本上就是代表了这个源氏的实时快照的并集。所以源氏周围的逻辑边界就代表了过去半秒钟这个角色的全部运动（的最大范围）。如果我现在沿着准星方向射击，在倒回这个角色以前，会首先与这个边界相交，因为基于我的PING值，它有可能在边界内的任意一处位置。

          这个例子里，如果我沿着这个方向射击，那只需要单独倒回安娜即可，因为子弹只和她的边界相交了。不需要同时倒回大锤和他的能量盾或者车，以及后面的门。

          射击如同移动一样，也可能会有预测失败。

          这里的绿色人偶是死神的客户端视角，黄色是服务器视角。这些绿色的小点点是客户端认为它的子弹击中的位置。可以看见绿色的细线是子弹经过的路径，但服务器在校验的时候，这个蓝紫色的半球才代表实际命中的位置。

          这完全是个人为制造的例子，确定型模拟过程是很可靠的，为了重现射击过程中的预测失败，我把我的丢包率设置为60%，然后足足射了这个混蛋20分钟才成功重现(众笑)。

          这里我还得提一句，模拟过程如此精确，要归功于我们的QA团队的同事。他们从不接受“NO”作为答案，而且因为市面上其他游戏都不会把命中判定的预测精确度做到这个水平，所以我们的QA小伙伴们根本不相信我，也不在乎我。只是不停地提bug单，而且是越来越多的bug单，而每一次当我们去检查是否真的有bug时，结果是每次都真的有。这里要对他们表示深深的感谢，有了他们的工作才使得我们能做出如此伟大的产品。

如果你的PING值特别高，命中判定就会失效。

          一旦PING值超过220毫秒，我们就会延后一些命中效果，也不会再去预测了，直接等服务器回包确认。之所以这么做的原因是，客户端上本来就做了外插值（extrapolate），不想把目标倒回那么远。不想让受害者觉得他们拼命跑到墙后面找掩护，结果还是被回拉、受伤。所以加了一层保护。这倒回外插后一段时间内的行为。下面的视频会演示这个过程（译注：强烈建议看视频）。

          PING为0的时候，对弹道碰撞做了预测，而击中点和血条没有预测，要等服务器回包才渲染。

          当PING达到300毫秒的时候，碰撞都不预测了，因为射击目标正在做快读的外插，他实际上根本没在这里，这里我们用了DR（Dead Reckoning）导航推测算法，虽然很接近，但是他真没在那里。死神左右来回晃动时就会出现这种情况，外插时完全无法正确预测。这里我们不会照顾你的感受，你的网络太差了。

          最后这个视频，PING达到1秒的时候，尤为明显。死神的移动方式不变，还会有外插。顺便提一句，甚至PING已经是1秒钟那么慢了，客户端的所有操作都还是能够立即预测、响应的，只不过大部分都是错的而已。其实我应该放大招的（午时已到），肯定能弄死他。

          下面讲下其他预测失败的例子，PING值还是不怎么好，150毫秒。这种条件下，无论何时遇到运动预测失败，都会错误的预测命中。下面用慢动作展现一下。

      看，都已经飙血了，但是却没看见血条，也没看见弹坑，所以对于弹道碰撞的预测来讲就是错误的。服务器拒绝了，这不是一次合法的命中。碰撞效果预测失败的原因就是“冰墙”立起来了。你“以为”自己开火时还站在地上，但是服务器模拟时，你已经被冰墙升到了空中，就是这个行为导致预测失败的。

          当我们修复这些微小的命中预测错误时，发现大部分情况都能通过与服务器就位置问题达成一致来消除，所以我们花了很多时间来对齐位置。

          下面是与运动相关的预测失败的例子，同时也与游戏玩法有关。

          PING值还是150毫秒，你想射中这个死神，但是他处于幽灵形态，箭头碰到他时，客户端会预测说应该有血飚出来，没有弹坑（hit pit），也没有血条。我们根本没击中他，因为它已经先进入幽灵状态了。

这种例子里，虽然大部分时间都会优先满足进攻者，但除非受害者做了什么事情缓和（mitigate）了这次进攻。在这个例子里，死神的幽灵形态会给他3秒钟的无敌时间。无论如何，我们没有真的打到死神。

让我从哲学角度想象一下，你就是那个死神，你进入了幽灵状态，但事实上服务器很可能会让你播放所有特效，让后让你死掉，因为你不可能如此快速进入那个状态。

ECS简化了网络同步问题。网络同步代码中用到的System，知道自己何时被用于玩家身上，很简单直接，基本上如果一个实体被一个带有Connection组件的东西控制了，它就是一个玩家。

          System也知道哪些目标需要被倒回到进攻者时刻的那一帧上，任何包含MovementState组件的实体都会被倒回。

实体与组件之间的内在关联主要行为是MovementState可以在时间线上被取消。

          上图52是System和组件的全景图，其中只有少数几个与网络同步行为有关。而这就是我们已知最复杂的问题了。System中有两个是NetworkEvent和NetworkMessage，是网络同步模块的核心组成部分，参与了接收输入和发送输出这样的典型网络行为。

          还有另外几个System，一只手就数得过来：InterpolateMovement，Weapons，Statescript，MovementState，我特别想删了MovementState，因为我不喜欢它。所以呢，实际上网络同步模块中，只有3个System是与gameplay有关的，其中用到的组件就是右边高亮列出的，也只有组件对于网络同步模块是只读的。真正修改了数据的就是像ModifyHealthQueue，因为对敌人造成的伤害是真实的。

现在回头看一下，用了ECS这么多年后，都学到了哪些知识与心得。

我有点希望System和Utility都能回到最早那个ECS操作元祖的权威例程的用法，做法有点特殊，我们只遍历一个组件就够了，再通过它访问所有兄弟组件。对于真正复杂的组件访问元组模型，你必须知道确切的访问对象才行。如果有个行为需要一个含有40个组件的元组，那可能是因为你的系统设计过于复杂了，元组之间有冲突。

元组另一个很酷的副作用是，你掌握了关于什么System能访问什么状态的先验知识，那么回到我们用到元组的那个原型引擎当中，就可以知道2或3个System可以操作不同的组件集合。因为根据元组的定义就可以知道他们的用途。这里设计的非常容易扩展。就像之前那个弹钢琴的动画一样，不过可以看到多个System同时点亮，只因为它们操纵的组件集合是不同的。

由于已经知道组件读写的优先级，System的轮询可以做到多线程处理gameplay代码。这里要提一句，Transform组件依然很受欢迎，但只有为数不多的几个System会真正修改它，大部分System都是对它只读。所以当你定义元组时，可以把组件标记上“只读”属性，这就意味着，即使有多个System都操作对该组件，但都是只读，可以并行处理。

实体生命周期管理需要一些技巧，尤其是在一帧的中间创建出来的那些。在早期，我们推迟了创建和销毁行为，当你说“嘿我想要创建一个实体时”，实际上是在那一帧结束时才完成的。事实证明，推迟销毁一点问题都没有，而推迟创建却有一大堆副作用。尤其是当你在System A 中申请创建一个新的实体，然后在System B中使用，这时如果你推迟了创建过程，你就要隔一帧才能使用。

这有点不爽。这也增加了很多内部复杂性(译注：看到这里，复杂性都是一些潜规则，需要花脑力去记住的hardcode)，我们想修改掉这部分代码，使它可以在一帧的中途创建好，这样就可以马上使用了。

我们在游戏发布之后才做了这些改动，实在很恐怖。这个补丁打在了1.2或者1.3版本，上线那天晚上我都是通宵的。

我们大概花了1年半的时间来制定ECS的使用准则，就像之前那个权威的例子，但是我们需要改造一些现有的代码使之能够适应新的架构。这些准则包括：组件没有函数；System没有状态；共享代码要放到Utils里；组件里复杂的副作用要通过队列的方式推迟处理，尤其是单例组件；System不能调用其他System的函数，即使是我们自己的取名System也不行，这个System几年之前暴雪分享过的。

仍然有大量代码不符合这个规范，所以它们是复杂度和维护工作的主要来源，就一点也不奇怪了。通过检视代码变更数量或者说bug数量，你就能发现这一点。

所以，如果你有什么遗留代码而且无法融入ECS规范的话，就绝对不应该使用。保持子系统整洁，不用创建任何代理组件去对它们进行封装。

不同的系统设计是用来解决问题的不同方法。

ECS是一个集成大量System的工具，不合适的系统设计原则就不应该被采用。

          ECS的设计目的是用来把大量的模块进行集成并解耦，很多 System及其依赖的组件都是冰山形状的。

冰山型组件对其他ECS的System暴露的表面很小，但它们内部其实有大量的状态、代理或者数据结构是ECS层无法访问的。

在线程模型中这些冰山的体型相当明显，大部分ECS的工作，例如更新System，都是发生在主线程(图58顶部)上的。我们也用到了大量的多线程技术，像fork和join。这个例子里，有角色发射了大量的抛射物，然后脚本System说我们需要生成一些抛射物，就创建了几个工作线程来干活。还有这里是ResolvedContactSystem想要创建一些碰撞特效，这里花费了几个工作线程去做这项工作。

抛射物模拟的幕后工作已经被隔离，而且对上层ECS是不可见的，这样很好。

另外一个很酷的例子就是AIPetDataSystem，很好的应用了fork和join模式，在ECS层面，只有一点点耦合，可能是说“嗨，这是一扇可破坏的门，你可能需要在这些区域重建路径”，但是幕后工作其实很多，像获取所有三角形，渲染并裁减，这些都与ECS无关，我们也不应该把ECS置于那些问题领域，应该自己想办法。

          这里的视频演示的是PathValidationSystem，路径（Path）就是全部这些蓝色色块，AI可以行走于其表面上。其实路径并不只用于AI，也用在很多英雄的技能上。所以就需要在服务器和客户端之间对这些路径进行数据同步。

          视频里的禅亚塔将会破坏这里的这些物品，你会看见破坏后的物体掉落到表面下方。然后那里的门会打开我们会把那些表面粘在一起。PathValidationSystem只需要说：“嗨，三角形有变化”。然后冰山背后就会用全部数据重建路径。

          现在准备结束今天的分享了。

ECS是Overwatch的粘合剂，它很酷，因为它可以帮你用最小的耦合来集成大量分散的系统。如果你打算用ECS定义你的规范，实际上无论你想用什么架构来快速定义你的规范，应该都是只有少数程序员需要接触物理系统代码、脚本引擎或者音频库。但是每个人都应该能够用到胶水代码，一起集成系统。

          实施这些限制，就能够马到成功。

          事实证明，网络同步真的很复杂，所以必须尽可能的与引擎其余部分解耦，ECS是解决这个问题的好办法。

          最后在接受提问以前，我想感谢我们团队成员，尤其是gameplay工程师，大家花了3年时间创造了如此美妙的艺术品。我们共同努力，创建原则，架构不断进化，结果也是有目共睹的。

《守望先锋》架构设计与网络同步

标签：取消   转换   逻辑   流程   屏幕渲染   叠加   依赖   射击游戏   工作方式   

原文地址：http://www.cnblogs.com/lpcoder/p/7074428.html