David Aldridge，现在是 Bungie 的技术负责人，于 2011 年在 GDC 历史上发表了影响深远的游戏网络演讲之一。该演讲题为“我先开枪了”，揭开了光环：致远星的 16 人竞争性多人游戏背后的完整网络架构。

该演讲涵盖了游戏架构和设计理念的主要方面，从基础复制协议和优先级引擎到在真实网络条件下设计、测量和优化单个游戏机制的实际过程。

间接地，这突出了任何游戏工作室，无论大小，都可以添加到他们的多人游戏中以帮助改善其在线架构的最佳实践。

[编者注] 鉴于 David 演讲的巨大范围，我们在本文中特意包含了每个主要见解下的“主要结论”，以帮助阅读。

传承自Tribes的架构

光环：致远星的网络并不是从零开始构建的。Aldridge 和他的团队将他们整个架构基础追溯到 1998 年的一篇 GDC 论文：“Tribes 引擎网络模型”由 Mark Frohnmayer 和 Tim Gift 撰写。要深入了解那篇基础论文及其对现代开发者的教训，Edgegap 在 Tribes 网络模型上进行了专门的深入研究。

Bungie 解决的核心问题是一个熟悉的问题：

• 对于一个比赛中的 N 个玩家，传输的游戏状态量几乎按 N 的平方扩展。

• 在一个 16 人游戏中，简单的“发送所有内容”方法需要大约 20 兆比特每秒的带宽需求。

• 换句话说，“完全不可行”。

Tribes 模型给了他们答案。系统不是建立在可靠的传递上，而是建立在半可靠协议上。

“半可靠”一词听起来像是一种妥协。实际上，这是一种有意的架构选择。

正如 Aldridge所解释的：“不可靠性使得积极的优先化成为可能”，这就是使整个系统扩展的原因。当你不必保证每个更新的传递时，你可以让流量控制层决定什么是当前最重要的并相应地填充每个数据包。没有被淹没的连接导致的延迟债务。没有等待丢失数据包重新发送的系统级停顿。

主要结论：半可靠协议不是捷径，它是可扩展的多人网络的基础。如果您的游戏拥有大量的对象和玩家，那么保证传递最终会在带宽上使您崩溃。这就是为什么 具有高度优化数据同步能力的网络代码是关键。此外，数据意味着出口成本，应尽量减少以确保降低整体云成本。

三种协议，三种任务

在那个半可靠基础之上，Bungie 运行三种不同的复制协议，每种协议都针对不同类型的数据进行调整。

• 状态数据提供一个保证：最终，最当前的值将到达。它不保证任何中间值。如果玩家的位置每秒更新 30 次，但只有 10 次通过，客户端会重构正确的当前位置，跳过所有中间更新。这涵盖了游戏属性的绝大多数，包括位置、健康、计时器以及比赛中所有网络实体的数百个对象属性。

• 事件则是相反：零传递保证。它们可以被完全丢弃。这是可接受的，因为事件描述了某事为何发生，例如为什么健康条下降或为什么 Warthog 失去轮子。如果你不在场见证过渡，你只关心当前状态。事件的价值是背景风味。状态数据携带真相。

• 控制数据是一股玩家控制器输入的子采样流，尽可能频繁地从客户端发送到主机，并反映回所有客户端。它很小，大约每个玩家 20 位，经过精心打包。它的唯一目的是预测准确性。如果玩家推动他们的杆开始向左侧移动，结果的位置变更在几个帧内不会可见。控制数据立即传递该意向，让其他客户端在状态数据显示之前开始预测移动。

将上下文事件和输入预测分离到具有不同可靠性保证的协议，让您能够有效地服务于每种数据类型，而不是为最坏情况过度设计。

优先化：引擎下的引擎

三种协议为您提供正确的数据类型。优先化决定了每个数据包中实际发送的内容。

游戏世界中的每个对象都获得一个持续的优先级分数，按客户端评估。系统评估距离、屏幕存在、威胁潜力和最近的交互历史。一些加权是直观的。一些则不是。

Aldridge 的团队发现玩家会执着地观察他们自己投出的手榴弹，“即使在丢出后它们已完全与他们无关”，因此玩家拥有的手榴弹需要比纯威胁逻辑建议的优先级更高。死尸在粉碎后几秒钟内获得接近最大重要性，因为玩家会在杀死后观察布娃娃倒下。远处角落里滚动的无操作手榴弹大约以每秒三次的频率更新。

当流量控制决定发送一个数据包时，复制层根据优先级顺序填充包。高优先级对象进入。低优先级对象等待。如果带宽受限，游戏优雅地降级，较不重要对象更新更缓慢，而不是停顿整个仿真结果是一个没有硬对象上限的系统，在 16 人比赛中支持超过 2,000 个同步实体。

这种每对象、每客户端的可见性是来之不易的。Edgegap 的 分析为游戏开发者提供了一个类似的层次，以深入了解服务器和网络性能，而不需要数年的定制定作投入，展示为现场多人游戏做出知情、可行的开发决策所需的数据。

主要结论：优先化将半可靠协议转换为可扩展系统。正确的实施需要根据实际玩家行为调整权重，而不仅是逻辑上的接近。正确的实施也需要拥有工具以查看您的网络实际上在做什么。

映射延迟：序列图作为设计工具

在为任何机制编写网络代码之前，Aldridge 的团队绘制了一个双机序列图：一边是客户端，另一边是主机，每个消息箭头倾斜以表示网络传输中的单向延迟。

倾斜是整件事的重点。它使每个潜在重复、每个漏洞窗口以及任何两个机器可能在代码不存在之前对游戏状态产生不同意见的时刻可见。

手榴弹投掷是最简洁的例证。在一台机器上流程简单：按下触发器、启动动画、释放帧，手榴弹发射。问题是如何在不生成伪影的情况下引入第二台机器。

• 选项一：请求主机许可以开始动画。立即揭示问题。按钮按下后客户端没有获得任何反馈。用Aldridge的话说：“玩家对此充满激情。”这是完全不可接受的。

• 选项二：在本地投掷并同时告知主机。这种方法没有明显的延迟窗口，听起来不错，但意味着没有实际发生主机仲裁。这是一种无声的延迟债务积累，保证晚些时候会出现同步错误。

实际答案是第三条路径：在按下按钮时预测动画，但在释放帧时暂停手榴弹创建。客户端的手臂立即移动。手榴弹在释放帧时消失。发送确认请求到主机。大约一个往返时间后，主机确认到达。

在那窗口期间，玩家的超级大size动画手臂占据了屏幕的三分之一。根据 Aldridge 的说法：玩家不会在投掷手榴弹时看他们的手；他们通过准星瞄准。根据 Aldridge 的说法，他们不会注意到高达150毫秒的间隙。根据 Aldridge 的说法，普通玩家，不会注意到高达200毫秒的间隙，这解释了为什么 Bungie在三款光环游戏中推出了手榴弹投掷。

主要结论：拥有两台机器的序列图是可供网络设计使用的最实用工具之一。 直接在代码编写之前，在明确的延迟箭头的指导下规划出一个机制会揭示难以通过任何其他方式发现的延迟窗口和延迟债务。

[编者注：不是每个人都拥有像 Bungie 在 AAA 游戏中拥有的资源。优化是关键，但预规划是奢侈。这就是为什么确保为游戏服务器、网络和整体后端的优化预留时间对性能和成本效率至关重要。]

延迟在哪里？

David 与他的团队使用的序列图方法直接导致了演讲中最重要的规则的揭示：永远询问您在哪里隐藏了延迟。

“如果您有主机仲裁发生，您将某处有延迟。如果您没有某处的延迟，您没有主机仲裁——您已承担延迟债务。”

不能消除。只能放置。设计工作是选择放置的位置，玩家不会注意到或其感知影响小到可以发货。

每个工作室都可以访问的重要杠杆之一是简单地通过服务器放置减少基础延迟。Edgegap 的编排平台通过将游戏服务器部署在最靠近实际玩家群体的地方减少了 平均延迟 58%。这并不能消除“延迟在哪里”的问题，但它极大地缩小了您工作的范围。

换句话说，200毫秒的往返需要非常不同的设计权衡与40毫秒的。尤其是较小的工作室受益，因为较少的网络工作需要用于隐藏本不应该存在的延迟。

主要结论：延迟不只是一个需要解决的错误；它是一个需要明智花费的预算。通过智能的服务器放置减少基础往返时间有助于缩小优化问题的预算，参考一个更小的工作室，缩减网络系统的成本。

当最佳网络代码修复是游戏设计修复

Bungie 在致远星 中的五个主要网络“优化收益”中，有四个是通过改变游戏机制而不是网络代码实现的。

这是演讲中最反直觉的教训之一，也是最持久的。

盔甲锁例子使之具体化：

• 机制：按下按钮，播放三帧介绍动画，获得无敌和无限质量。

• 在版本发布之前有两个失败的迭代。

• 两者都有一个窗口，其中手榴弹可以在介绍动画期间在主机上引爆并造成伤害，导致已经在屏幕上看到蓝色护盾的玩家收到他们确信已经免疫的伤害。

• 每个测试版之后都有数千个论坛帖子。

最终版本进行了有针对性的改变。

正如 Aldridge所描述的：“我们进去抓住设计师如此精心调整的帧延迟数值，并把它盖过网络。”正如 Aldridge所描述的：“我们实际上改变了游戏的播放方式。” 主机提前激活护盾，通过测量主机与激活客户端之间的往返时间缩短介绍延迟。当客户端看到护盾出现时，与他们的预期一致。不一致被转移到最在意的玩家，即使用盔甲锁的玩家，而是到了主机和其他玩家，他们几乎不会注意到其他人的护盾提前几帧启动。

暗杀机制走了类似的路线。最终版本使用了视觉上的插值混合，大约三分之二秒的时间用来吸收进入时的位置差异。在调试模式中，混合是可见的，动画制作人在第一时间指出了它。在游戏中，它是不可见的。在每次暗杀开始时，摄像机拉出到第三人称状态，在确切窗口内以每秒约 25 英尺的速度移动。玩家的位置参考改变如此快速，以至于一个 20 英尺的混合完全不被注意。他们的大脑填补了连续性。

布娃娃解决方案将原则推到极致：完全停止网络同步布娃娃。只与所有同行同步初始死亡状态。在那之后，让物理在本地发生偏差。解决了两个设计关注点：

• 首先，布娃娃阻挡子弹（解决方案允许完全穿透没有副作用）和；

• 光环社区长期以来的一个传统，即蹲在倒下对手的尸体上，需要布娃娃处于正确的位置。

两者均可解决，没有人注意到更改，结果是大约 10到12% 带宽释放。

主要结论：从一开始您的网络工程师和您的游戏设计师就需要合作。其中一些最有效的延迟解决方案不是在网络层找到的。它们是在机制本身的设计中找到的，也是可以吸收不一致的感知窗口和玩家注意模式中找到的。

首先构建工具，然后优化

Aldridge引用了一个优化规则：“程序优化的第一规则：不要做。第二规则，仅对专家：还不要做。”

Bungie 知道他们需要优化，所以在触碰任何一行网络代码之前，他们构建了安全进行优化的工具。

带宽分析器在整个仿真中跟踪使用率和优先级结果。

真正的能力来自将分析器数据拼接到 光环的现有电影系统中。

电影是决定性的游戏记录，自 光环 3以来就是用户功能。Aldridge 的团队在每个游戏帧后注入一个包含所有网络状态的调试块，采样期间所有发送和接收的包及优先决策。正如他所说：“对于 光环 历史上的第一次，他们可以在事后分析网络性能，回到任何时刻，过滤到特定客户端，并检查它们在何时向谁传输了什么。”总开发时间：核心工具约六周。

该工具集直接促成了从 光环 3 到 致远星 超过 80% 的带宽降低。

一个例子表明了它揭示了什么：在地面上滚动的闲置手榴弹在优先级层上消耗了不成比例的带宽。根本原因是来自 光环 3 结尾的一个错误修复，该修复为设备对象提供了一个大的优先级提升以解决延迟投诉。由于设计失误，手榴弹和设备共享相同的父类。地图上的每个投下的手榴弹继承了提升，并始终被视为高优先级。一行修复（即，仅对激活设备应用提升）释放了约20%的带宽。

对于没有六周时间来构建自定义分析基础设施的工作室，Edgegap 的 分析工具提供容器和游戏服务器层的现场和历史性能数据，帮助团队捕获那些 Bungie 的自定义分析器旨在发现的系统模式、带宽异常、对象级优先级问题、服务器帧时间峰值。

主要结论：网络熵悄然积累，您不能修复您看不到的东西。在优化之前投入深度检查工具建设不是可选，正如它是使优化成为可能的工作。

将感知延迟转变为科学

在模拟的网络条件下进行游戏测试为 Bungie 提供了一个受控环境，但“比赛质量”测量问题更难。如 Aldridge 所指出，玩家“可以告诉我们他们是否度过了愉快的时光，几乎完全与他们是否赢得比赛有关。”这不够细致以驱动工程决策。

解决方案：一个专用于游戏测试的控制器按钮，直接在电影中注入时间戳调试事件。每当玩家感到延迟时，按下该按钮。工程师跳转到那个确切的帧，检查完整的网络状态，并进行调查。当团队可以运行他们的带宽目标并看到测试者按压零按钮时，他们知道他们已经成功。

出现了一个有用的副作用：玩家不仅因为实际的网络问题而按按钮，还因为游戏机制让他们困惑或迷失方向时按下按钮。

从几乎满血的手榴弹中一枪即死感觉像是延迟。一个没有清楚解释死亡原因的死亡摄像头感觉像是延迟。工程团队会提取那些电影剪辑并直接带给设计师，提供数据。网络工具成为游戏设计的反馈_loop_。

主要结论：感知延迟是产品信号，而不仅仅是网络指标。通过为游戏测试者提供精确的数据标记它（与可重现的游戏状态相关联）将模糊的抱怨转变为工程和设计师的可操作数据。

智能主机选择和主机迁移的成本

主机迁移，即在当前主机连接恶化时在游戏期间切换到更好的主机，功能强大，但在工作时才如此。

然而，Aldridge 承认它可以成为专门的演讲，因为它是一个 重要的工程工作，考虑它的工作室不应 低估范围。

Highwire Game 的Michał Buras，六天在 Fallujah 上的主网络工程师，在他的演讲中分解了主机迁移复杂性在对等网络和中继网络中的挑战级别，这是一个在走上这条道路之前有益的参考。

专用服务器完全绕过了这个问题。对于专用服务器，谁担任主机，不存在主机迁移问题，会议连续性因此在基础设施层管理。

主要结论：谁主持会议与您如何设计会议一样重要。P2P或中继网络架构中的主机迁移具有工程成本，根据专用服务器基础设施以完全避免。

数字，以及它们对带宽成本的意义

致远星 的最终基准：以特定设计目标 384 kbps 实现 16 人游戏，在 250 kbps 的条件下以无延迟伪影运行。对于光环 3，总带宽减少超过 80%。

节省的每千位比两个方面：

• 首先，对玩家来说，较低的带宽要求意味着更多的玩家基础能够在更广泛的连接类型上运行游戏良好。

• 其次，对于您的基础设施账单而言，出口成本直接与您的服务器传输数据量成比例。

因此，优化复制、排频率和优先化逻辑也是在优化您的云费用。对于Unreal Engine开发者寻找具体起点，Edgegap 已发布Unreal Engine 服务器分析和优化清单，正在开发 Unity 等效。

主要结论：带宽优化不仅仅是网络质量问题。它是直接影响游戏本身盈利能力的业务成本问题。因此，每次复制效率的改进都会直接减少出口支出，使其成为少数几项同时在玩家体验和基础设施预算上产生回报的工程投资之一。

—

本文基于并引用了 David Aldridge 在 2011 年的原始 GDC 演讲，该演讲发表于 GDC YouTube 频道。原始内容中的所有权利归其各自的所有者所有。