John Chu，现任 Bungie 中央技术在线部门的首席技术项目经理，曾担任 Bungie 的高级技术项目经理，他在 GDC 2022 上发表了“让玩家汇聚：在 Destiny 2 中构建跨平台联机”，完整讲述了 Bungie 如何为全球最活跃的持续运营游戏之一，在七个平台上推出跨平台联机的制作历程。

这也间接说明，任何规模的游戏工作室都可以把一些最佳实践加入到其多人游戏中，以帮助改善其跨平台架构。

[编者注：鉴于 John 的演讲篇幅庞大，我们特别为本文在每个主要见解下加入了一个“主要收获”段落，以提升可读性。]

在自有引擎中构建跨平台联机，意味着几乎所有东西都得从零开始搭建

跨平台联机是个容易理解的概念。你只是把来自不同平台的玩家接入同一个游戏世界。但在专有引擎里，几乎没有什么东西能直接在平台间正常工作——一切都必须重建。

Bungie 的 Tiger Engine 是为初代 Destiny 打造的，其部分代码库甚至可以追溯到 Halo 时代。所有此前依赖平台级 API 的系统都必须从头重建：网络、玩家身份、好友列表、会话邀请、语音聊天和文本聊天，全部都要重新做成可同时适配 Sony、Microsoft、Valve 和 Google 的版本。正如 John Chu 所描述的那样，这些都是引擎中“最庞大、最吓人的伤筋动骨式改动”之一，因为网络是其最基础的底层系统之一。

单是网络层面的改动就相当大。由于 Destiny 2 多年来分别在各个平台上发售并针对各平台做了优化，这些优化在合并后并不兼容。团队构建了一个映射层，通过一致的句柄在网络上传递信息，而这些句柄可以在各端转换成适合平台的形式。Fireteams 的在线会话也必须重构，不再由单个玩家托管一个会话，而是为每个平台分别维护独立的在线会话。

使用 Unreal 或 Unity 等第三方引擎的游戏，很多跨平台可移植性都已经内置好了。Bungie 并没有。如果你是在自有引擎中开发，那么在确定跨平台联机范围之前，先盘点所有会接触平台 API 的系统。这个清单会比你预想的更长。

主要收获：在专有引擎中，几乎所有接触平台级 API 的系统都需要为跨平台联机重建。范围和时间线从一开始就必须体现这一现实；第三方引擎开发者也应在假设平台依赖已经被覆盖之前，先审计自己的平台依赖。

统一的玩家身份不是功能，而是前提

Destiny 2 的玩家会花上数百小时打造他们的守护者。这个守护者是他们自我的延伸，而身份的重要组成部分就是名字。在跨平台联机之前，这个名字来自平台：你的 gamertag、Steam 个人资料名、PSN 账号名。到了跨平台联机时代，这种做法立刻失效。同一个玩家在 PlayStation 上可能叫“Oryx”，在 Steam 上却是“Savathun”，而他们在不同平台上的朋友根本认不出来。

Bungie 的解决方案是 Bungie Name：由玩家自选名称加上四位唯一标识符组成，例如“Oryx#1234”。它会在玩家首次登录时自动从所用平台名称生成种子，既保持注册流程顺畅，又不增加额外步骤。它会出现在游戏中玩家头顶以及他们游玩的队伍名单上，无论平台如何，都能保持一致身份。

这个问题如今在业内已是众所周知，而今天构建跨平台联机的工作室可以使用 Bungie 当年必须完全自建的方案。Epic Online Services 通过其 Auth Interface 免费提供跨平台身份与社交层，可在 PC、主机和移动端之间工作。brainCloud 提供类似的跨平台身份与认证基础设施，专为游戏设计，并内置跨平台账号合并支持。LootLocker 提供跨平台玩家认证和统一玩家账户，可将多个平台身份关联到单一档案之下。其底层原则都是一样的：统一身份层必须被视为基础设施，而不是在其他所有事情做完之后再处理的次要功能。

主要收获：任何跨平台联机体验从第一天起都需要一个与平台无关的身份系统。今天的工作室不必从零开始搭建。如今，Epic Online Services、brainCloud 和 LootLocker 这样的服务都已开箱即用地提供了这套基础设施。

在大型远程跨团队项目中管理相互依赖关系

随着四个团队和大约 50 个人同时负责体验的不同部分，彼此间的依赖无处不在。网络层的改动会影响会话邀请系统。关于玩家身份的决定会波及队伍名单 UI。而由于整个团队都在远程协作，通常能顺手化解这些问题的走廊闲聊并没有自然发生。

Bungie 的应对方式是有意设计同步机制。他们按功能领域（所有做好友与在线状态的人聚在一起，所有做通信的人聚在一起）以及按职责分组（所有工程师或所有测试人员分别开会）举行定期会议。这样不同问题就能在合适的会议里浮现出来。在一次专门聚焦好友与在线状态的每周同步会上，团队意识到没有人真正厘清在跨平台世界里封禁该如何运作。让工程师和设计师一起参加同一场会议，意味着这个模糊点能立刻被解决，而不是悄悄变成设计债务。

不过，Chu 也坦率承认了过度开会的风险：“为了在团队内建立共识而召开的同步会议，会以牺牲 IC 时间为代价。” 项目早期，会议太多意味着个人贡献者没有足够时间真正去做事。团队不断调整节奏，减少总会议时间，直到额外开销变得合理。

主要收获：按功能领域和职责刻意设计同步会议，能暴露阻塞点并增强团队凝聚力。但过度开会会直接拖慢交付速度。定期审视你的节奏，并尽可能删减。

对局配对池应反映模式的竞技风险

并非所有游戏模式都具有相同的竞技权重，而这种差异应该决定你如何构建跨平台对局配对。Bungie 从一开始就将竞技模式与合作模式分开，遵循两个明确原则：公平与玩家保护。

对于 Strikes 这类合作模式，没有明显的平台优势。没有会改变结果的输入差异，也没有会让某一方更容易遭受利用的安全差异。无论平台如何，大家都一起游玩。对于竞技模式，则创建了两个独立池：一个是主机池，覆盖 PlayStation、Xbox 和 Stadia（其运行在受控的数据中心硬件上，不太可能出现客户端篡改）；另一个是 PC 池，覆盖 Steam 和 Microsoft PC Store。跨平台 Fireteams 的处理方式是：当主机玩家与 PC 玩家组队时，允许主机玩家进入 PC 池，但反过来不行。

这个池系统还被设计得可扩展，因此未来如果出现具有不同失衡风险的模式，也能处理，而无需重构任何东西。事先明确指导原则，让单独的设计决策容易得多。今天构建跨平台联机的工作室，也可以直接通过对局配对配置来应用同样的逻辑。Edgegap 的对局配对器文档在其竞技游戏示例中就正好涵盖了这种模式，展示了如何在无需从零构建自定义池逻辑的情况下，对休闲与竞技模式分别强制不同的对局配对约束，包括平台和输入限制。

主要收获：先在设计池规则之前定义你的指导原则。按活动类型分池，把系统设计成可扩展的，并清楚：合适的对局配对配置就能在无需定制工程的情况下实现这类逻辑。

跨平台联机会引入新的毒性向量，需要跨平台解决方案

当你扩大玩家的社交接触面时，也就扩大了他们接触恶意行为者的可能性。把不同用户名规范、安全文化和审核历史的平台结合在一起，会产生单一平台生态中根本不存在的骚扰形式。

Bungie 早期识别出两个主要风险。第一，用户名中的脏话和贬损性语言：有些平台过滤很严格，有些则不然。没有他们自己的过滤层，不适当的平台名称会直接作为 Bungie Name 的初始值带入。第二，平台级封禁是各自孤立的。玩家在 PlayStation 上封禁了某个骚扰者，仍然可能被同一个人通过 Steam 账号接触到。

对于内容过滤，Bungie 集成了一套具备机器学习能力的第三方方案，且上下文感知足够强，能够区分玩家是在用同样的语言辱骂他人，还是在表达兴奋。若要内部自建并维护一个覆盖 12 种支持语言的模型，需要大量专门人才。对于封禁系统，Bungie Block 设计为覆盖所有平台上所有已关联账户。封禁某人一次，与其关联的每个账户都会在所有地方被封禁。为了上线，这是一项硬性要求。Chu 明确指出，敌对行为往往会针对少数群体和更脆弱的玩家群体，因此妥善保护是不容妥协的。

主要收获：跨平台联机的封禁系统必须是跨平台的。只在单个平台封禁、却不覆盖玩家在其他平台上关联账户的机制，并不是真正的保护。应在上线前就把它做好。

第一方认证要求会影响设计——要在前期制作阶段就开始阅读

要在七个平台上发售，意味着要应对七套认证要求，而许多第一方平台的认证文档里都有专门的跨平台联机章节。熟悉这些要求只是基本门槛。更难的是把这些要求与你想要的设计相协调。

有些平台要求，玩家在该平台上应主要通过自己的平台名称来识别，这与 Bungie 的 Bungie Name 概念直接冲突。有些平台禁止在自己的平台上游玩时显示其他平台的徽标或图标。这些都不是边缘案例——它们是必须在体验能够上线之前解决的要求。

Bungie 的做法是在前期制作阶段就开始这些对话，尽早标记冲突，并与第一方沟通，以理解每项要求背后的精神，而不仅仅是字面条文。这是个漫长的过程。但提早开始意味着有时间找到对双方都有效的解决方案。Chu 承认，Bungie 拥有既有且紧密的第一方关系，这是很幸运的。无论工作室规模大小，这个原则都适用：越早暴露这些冲突，你就越有空间去解决它们。

主要收获：在前期制作刚开始时就阅读第一方跨平台联机认证要求，而不是等到结束时。尽早识别冲突，才能在时间线受风险之前找到前进的路径。

在自建与采购之间要有明确取舍

一旦你把所有需要为跨平台联机重建的系统都列出来，其中有些会是其他公司已经很好地解决过的真正难题。能跨所有平台稳定工作的语音编解码器。覆盖十多种语言的脏话和毒性过滤。这些都不是差异化功能。它们是基础设施，而且已有成熟供应商。

Bungie 集成了一套第三方语音方案，这让团队可以把注意力放在只有 Bungie 自己能构建的跨平台联机部分。对于文本过滤来说，内部构建并维护一个具备上下文感知能力、覆盖 12 种语言的模型，需要大量专门人员，而项目没有时间或预算去招募这些人。

文本聊天是个例外。尽管有现成方案，Bungie 还是自己构建了文本聊天服务，理由是对平台的控制能带来第三方无法匹配的长期集成潜力。这个区分很有用：第三方已经比你自己能做到的更好时就买；控制权和深度集成更重要时就自己做。

不过，Chu 也直接指出，采购并不能解决所有问题。集成第三方方案本身就需要真实的工程时间，而在 Bungie 的案例中，有些集成范围定得过大，不得不推迟到后续版本。你还会把自己的游戏绑定到另一款产品的发布节奏和更新计划上。

主要收获：语音、身份和审核方面的第三方方案可以显著压缩范围。但集成始终需要时间，并会带来外部依赖。把自研与采购视为范围管理工具，并从一开始就把集成时间纳入计划。

利用分阶段发布来降低大型功能在线上游戏中的风险

跨平台联机带来的新服务，比 Destiny 2 最初上线以来 Bungie 交付的任何东西都多。若在一个赛季内全部推出，就意味着只能有一次机会在七个平台上做对，而活跃玩家群又依赖这一体验不能出问题。这种风险实在太大，不能一次性承受。

因此，Bungie 把发布分散到多个赛季中，优先前置风险最高的改动。网络层重构在早期就上线了，让它有数月时间沉淀和稳定，然后跨平台联机的其他部分再建立在其基础之上。新的 UI 系统和早期跨平台功能则在前一个赛季中引入。在正式上线前的那个赛季，Bungie 员工就已经可以在正式零售版游戏中使用跨平台功能，与公众玩家一起游玩长达数月。最后，一个有限的公开测试版在 Strike 列表中启用了跨平台联机，对新的网络和对局配对代码进行了真实规模的压力测试。

途中也有一些小插曲，玩家偶尔会比预期更早碰到跨平台功能。但这些都被视为有助于暴露 bug 的事件，而不是失败。正如 Chu 引述工作室内部的话所说：“我们无法控制结果，但可以控制执行。” 分阶段发布策略正是这一点的体现。

主要收获：对于线上游戏中的大型功能，应将发布分散到多个更新中，并把风险最高的引擎改动优先前置，让它们有时间稳定下来。带真实玩家的内部 alpha 和有限公开测试版，是正式上线前建立信心的最佳工具。

本文基于并引用了 John Chu 在 GDC 2022 上的原始演讲。原始内容的所有权利归其各自所有者所有。