在游戏开发领域，鲜有人能像 Fred Gill 一样，拥有如此广博的经验与洞见。他职业生涯辉煌，曾在 Respawn Entertainment 担任要职，参与打造了 Apex Legends 和 Titanfall 等热门大作。Fred 已多次成功驾驭发行前开发的种种复杂局面与挑战。

近日，他与我们深入探讨了游戏开发中各个精妙的阶段，剖析了塑造一款游戏从概念走向发行之路的关键优先事项、技术选型与战略考量。

GGWP：在游戏开发的发行前阶段，您的团队最重要的优先事项有哪些？

Fred Gill：游戏开发分为不同阶段，每个阶段的优先事项各不相同：

• 前期制作（Pre-production）。目标是「找到乐趣」。怎么做？制作大量原型，以精准锁定能给玩家带来乐趣的要素。大多数原型的品质都达不到可发行的水准，这没关系——重点在于以尽可能快、尽可能低的成本，弄清楚哪些行得通、哪些行不通。大多数原型会使用占位素材（白模／灰模），因为它们随时可能被弃用。

在这一阶段，工程团队与技术总监会为团队的快速原型开发提供支持——快速迭代（短反馈循环）能带来更高的品质；而一旦找到了乐趣（即确定功能集），就要开始考虑需要哪些技术来支撑这款游戏——既包括客户端（PC 或主机）技术，也包括服务器端技术／API。

• 制作（Production）。制作阶段可能会拆分为两个阶段。第一个阶段通常是产出一个垂直切片（Vertical Slice）和／或水平切片（Horizontal Slice）（若两者都做，可能会拆成两个阶段／里程碑）。水平切片是指把整个游戏世界都搭建出粗略框架，使游戏能够从头玩到尾。垂直切片则是把游戏中的一小部分打磨到可发行的品质（美术素材、音频、目标性能等）。垂直切片（VS）和水平切片（HS）都可以用来更准确地估算把整个游戏内容做到可发行品质所需的工作量。第二个阶段则是把游戏做到那样的品质。

「找到乐趣」的工作在制作阶段并不会停止——只是在这一阶段，它往往表现为渐进式的改进与调整，而非颠覆性的变革；偶尔也会出现能让游戏品质大幅提升的重大改动，遇到时您就只能想办法应对。我知道有些游戏在 Alpha 阶段之后进行了重大改动，结果证明堪称神来之笔，但风险极高，那绝不是您会希望做这类改动的时机。

这一阶段团队也会开始敲定用于游戏发行的技术决策；技术团队会结合自己对游戏的理解，对第三方技术进行评估。

• Alpha 阶段。这一阶段的目标是「功能完备」（feature complete）——所有游戏功能均已实现，但仍在补充部分内容，例如用最终的模型和贴图替换此前的粗略框架区域，以及音效、音乐、游戏内过场动画等。玩法功能此时可能仍有不少 Bug，但应当已经完整。

在这一阶段，如果游戏是在线游戏，并且有重要的新技术为游戏发布提供支撑，团队可能会选择进行一次「技术测试」（Technical Test）。这类测试过去被称为「封闭 Alpha 测试」或「公开 Beta 测试」，但这些术语常常让公众感到困惑。Respawn 在开发 Titanfall2 时提出了「技术测试」这一说法——Titanfall2 采用的专用服务器扩容技术与初代 Titanfall 完全不同。这次「技术测试」旨在检验扩容能力是否足以支撑游戏发行。结果扩容表现并不理想，但我们通过这次技术测试摸清了所有问题所在，从而确保了正式发行时的顺利上线！

• Beta 阶段。所有功能与内容均已完成，此时团队（通常是核心成员）会集中精力修复 Bug，为发行做好准备。

• 发行（Ship）。将游戏正式发行；如果没有规划运营服务（live service），可能会推出若干补丁，因为游戏发行后玩家不可避免地会发现 Bug；如果规划了运营服务，团队则会着手开发相应的内容。

GGWP：在这一阶段，您如何在游戏设计、技术开发与市场营销之间取得平衡？

FG：在我看来，游戏设计高于一切——如果设计团队为了让游戏变得更好而需要做出改动（尤其是当他们能够证明这一需求时），那就必须优先满足，于是其他事项就得往后排，或者发行日期就得推迟。我们在 Apex Legends 上就遇到过类似情况——我们实际的发行日期（2019年2月4日）并非最初期望的日期。

提升游戏的知名度至关重要，这意味着要与市场团队协作，共同制作素材以尽可能地展现游戏的最佳一面——可能是截图、游戏内画面、发行前的测试版本等。而当团队仍在打磨玩法与内容（以及修复 Bug）时，这会颇为棘手。关键在于让开发团队与市场团队在目标和需求上达成一致——说起来容易，做起来却相当有挑战。专注（FOCUS）是制作游戏最重要的要素之一——把少数几件事做到极致，而不是把大量事情做得平庸。在游戏收尾阶段，这种专注尤为关键——只要核心要素到位，并且您没有丢掉这份专注，游戏品质在制作阶段最后几个月里所能取得的提升幅度会令人惊叹。

GGWP：您如何为自己的项目确定最合适的游戏引擎？这一决策中的关键因素有哪些？

FG：对于任何技术选型（「自建还是购买」），都有两个关键问题，即：1）「它能否让您更早发行、风险更低，并且至少达到同等品质？」；2）「它是否物有所值？」这两个问题实际上就是投资回报率（ROI）。

由此又会引出一长串更为细致的问题，其中一些是：

• 采用它会如何改变您最大的风险？
• 它属于竞争优势，还是通用商品（或者很快就会变成通用商品）？
  • 「您能接受失去对这部分技术的掌控权吗？
• 这项技术所填补的空白是否已被充分理解／是否稳定？
  • 「找到乐趣」的过程可能会改变技术需求（即技术上的空白）
• 这项技术是否成熟／稳定？
  • 它是否支持您所需的平台？
  • 已有多少款游戏采用这项技术完成了发行？
  • 这项技术与需求是完全契合，还是只覆盖了一部分，抑或超出了需求范围？
    • 如果您的需求发生变化怎么办？
  • 更新 & 支持——您能否影响其发展方向／功能／Bug 修复？
    • 如果不能，您能否（轻松地）自行添加所需功能，或者接管其维护？
• 如果团队想「自己动手写」，他们凭什么认为自己能做得更好？
  • 范围更聚焦
  • 未来的灵活性

这些问题及其答案都存在许多微妙之处。理想情况下，答案应当是客观的，而非主观的。

技术组件越大，这些问题就越难回答！ 为什么？

• 较小的技术通常有一个优势，就是能把一件事做好／做到极致。这意味着评估可以更聚焦，而且通常以数据驱动，因而更客观。如果评估有误，也相对更容易更改。但关键在于，通常受影响的团队成员较少——可能只是某一个人，或者技术团队，又或者是技术团队再加上团队中的另一个小组。这类技术的例子包括 RADGameTools Oodle 和 Bink。

• 较大的技术（引擎便是其中最大的）会以参差不齐的品质完成多项工作。在每一款引擎中，都已经做出过种种决策／取舍。这些最终都意味着妥协，也就是说，没有任何一款引擎能够完美驾驭所有游戏类型。当您在开发原型时，这些妥协或许并不明显。只有当您试图把游戏推向引擎的极限（CPU、GPU、内存、流式加载等）——通常也就是您准备发行的时候——才会真切地感受到痛苦，也才会真正理解引擎团队当初所做的决策／取舍／妥协。

注意：有些游戏的设计永远不会把引擎推向极限。如果是这种情况，那就再好不过了。

引擎的选择会影响整个团队的工作流程，因此这一决策会更加主观。我见过许多团队试图把引擎「改造成团队所习惯的工作方式」。那简直是自讨苦吃，我从没见过有谁成功做到过（除非对引擎进行硬分叉）。引擎选择在当下、以及在您发行时，会对各个领域分别产生怎样的影响？它会如何影响内容创作者与工程团队的迭代速度（这与品质直接相关）——哪些方面会更快，哪些方面会更慢，它能否既支持您当下验证游戏、又支持日后将其发行？这里可以举个例子：「您的设计团队是否愿意使用可视化脚本来迭代玩法？您能否用可视化脚本完成发行（其性能是否足够）？如果您需要基于文本的脚本，那么每次升级引擎时进行相应集成的成本又有多高？」

我认为，「如果一个游戏团队已经用某款引擎发行过一款游戏，那么这个团队要切换到另一款引擎就应当是相当困难的（并非不可能）」——一旦团队亲身经历过用某款引擎发行游戏的全过程（尝过其中的苦头），就会理解引擎团队所做的取舍／妥协，于是日后用同一款引擎发行游戏就会变得更容易。

GGWP：您能否谈谈第三方服务在您游戏开发中所扮演的角色？您又是如何选择要集成哪些服务的？”

FG：除了上面的回答之外，对于第三方服务，还有以下这个问题需要考虑：

• 它如何支持多个客户？
  • 是单租户还是多租户（这会影响下文的问题 & 答案）？
  • 我能否（在需要时）顺利地从多租户切换到单租户？

注意：多租户可能成本更低，但也可能存在扩容、安全以及「吵闹邻居」（noisy neighbour）问题（不仅其他应用可能成为您的吵闹邻居，您的游戏也可能成为它们的吵闹邻居）。

• 它能否扩容以支撑我预期的玩家规模？
  • 全生命周期的总受众量
  • 峰值同时在线人数
  • 扩容特性如何
    • 它能多快完成扩容？
      • 在发生故障后至关重要（故障可能出在别处）
    • 随着玩家增多，该服务的性能会如何下降（延迟）？
    • 是动态自动扩容（与缩容），还是需要人工介入？
  • 等等
• 补丁／更新的模式是怎样的？
  • 它是否支持零停机？
  • 它是否支持向一部分玩家部署？
  • 如果出现问题，能多快回滚？
  • 等等
• 数据 & 安全
  • GDPR
    • 第三方需要／保留哪些数据，保留多长时间？
    • 对于数据主体访问请求（Subject Access Requests，SAR）提供哪些支持？
    • 对于被遗忘权（Right To Be Forgotten，RTBF）提供哪些支持？
  • 他们在（开发与部署方面）部署了哪些安全措施？
  • 等等
• 扩容能力是否经过测试／验证？
  • 性能特性如何？
  • 如果我的游戏大获成功（5 倍、10 倍）怎么办？
• 支持模式如何？
  • 哪些是自助式服务，哪些是全程贴身式（white-glove）服务？
  • SLA（服务级别协议）是怎样的，又有哪些问题上报路径？
• 成本建模：
  • 如果我的游戏取得中等程度的成功，会如何影响盈利能力？
  • 如果我的游戏大获成功，会如何影响盈利能力？

Respawn 做的是游戏，而不是技术。技术只是制作游戏的副产品。Respawn 之所以自行为 Titanfall 开发了许多后端服务，是因为他们想要／需要的技术在市场上要么并不存在，要么还不成熟。由于团队对这些技术的优劣了如指掌，而更换技术就意味着要砍掉游戏功能，这些技术后来被沿用并加以改造，应用到了 Titanfall2 和 Apex Legends 上。EA 当时是 Respawn 的发行商，拥有一些 Respawn 本可使用的后端服务，但作为一家独立开发商，Respawn 希望尽量减少与任何单一发行商的绑定。这一切在 2017 年 Respawn 被 EA 收购后彻底改变了。

GGWP：根据您的经验，哪些服务更常由内部自行开发，哪些通常会外包？又是什么因素驱动着这些决策？

FG：与 2013／2014 年相比，如今可供授权使用的后端服务多了许多，而且它们能够以非常成功的游戏所要求的规模运行。其选择标准与我上面关于选择游戏引擎的回答非常相似，只是需要着重考虑以下几点：

• 这些服务中，是否有哪些属于团队应当自主掌控的关键差异化优势？
  • 是否属于预期在发行后需要快速迭代／变更的领域？
• 团队是否需要对该服务获得运营层面的洞察，而合作伙伴无法／不愿提供支持？

在 EA，第一方服务在安全层面已经通过审批，在数据处理方面符合法律合规要求，也经过了大规模测试，而且至关重要的是，只需极少量的游戏胶水代码即可实现互操作。另一方面，第三方服务往往更为精致好用，也就是说更易于集成和配置（毕竟其公司的存亡可能正取决于这一点）。

GGWP：对于多人游戏而言，在发行前需要准备好哪些运营（LiveOps）服务？

FG：这是个长长的清单。我们在 Apex 发行时并没有把这些全部做到——其中一些在当时还无法实现，比如在 2019 年 2 月 Apex 发行时，跨平台游玩和跨平台进度同步还无法实现。最关键的经验是：在您首次把游戏交到玩家手中之前就把这些工作做好，要容易得多。

• 身份认证——第一方／联合发行商身份认证
• 崩溃报告
  • 客户端以及任何服务器／服务——MTTF（平均失效前时间）与 MTBF（平均故障间隔时间）都很重要
• 匹配
• 数据持久化
• 反作弊（这本身就是一个大话题）
• 社交／社区系统
• 用户生成内容（UGC）——审核、举报（这本身就是一个大话题）
  • 文字聊天
  • VoIP
  • 等等
• 遵守全球各地的法规（且在不断演变）
  • 适用于文字 & 语音聊天的 CVAA
  • COPPA
  • 等等
• 游戏内商店（视发行模式而定）
  • 确保您符合不断演变的全球各地法律，例如战利品箱（Loot Boxes）在比利时是被禁止的
• 服务器扩容
  • 如果使用专用服务器，则需自动扩缩容（扩容与缩容）以匹配需求
    • 出于成本考虑，Apex Legends 采用了一套混合系统：在数据中心部署裸金属服务器，当需求超出裸金属服务器的容量时，再扩展到云端
  • 如果使用监听服务器或点对点（peer-to-peer）——则涉及 NAT、服务器迁移等问题
• 服务器配置／功能一键停用开关
• 服务器更新／打补丁
• A/B 测试能力
• 客户端更新与打补丁（包括剥离未来赛季的内容／数据）
• 跨平台游玩与跨平台进度同步（数据持久化）
• 遥测数据——采集与可视化
  • 针对 SAR 与 RTBF 的 GDPR 支持
  • 对基础设施运行状况的洞察
    • API 调用、延迟、数据库使用情况等
  • 对对局「质量」的洞察
  • 对玩法的洞察
    • 常规数据——角色使用情况、武器使用情况、治疗道具拾取情况等
    • 检测串通作弊、小号（smurfing）、代练（boosting）等行为
  • 对商店的洞察
  • 对参与度、留存率的洞察

GGWP：您如何规划并为多人服务的可扩展性做好准备？

FG：测试、测试、再测试，而且要以超出您预期玩家数量（包括同时在线和全生命周期）的规模来测试！有两个方面需要您考虑：

1. 后端服务——身份认证、数据持久化、社交等
2. 玩法服务器——运行玩法模拟的服务器

背景知识：多人游戏基本上有三种常见架构：

• 监听服务器（Listening server）——其中一台 PC／主机客户端同时充当权威服务器。随着玩家规模的增长，它可以「无限」扩容，因为服务器由玩家自己提供。但它存在诸多问题：带宽和连接质量（因为这些通常运行在玩家家中）、可支持的玩家数量、NAT、延迟、同时充当客户端和服务器的机器所承受的性能负担，以及当服务器崩溃／连接中断／充当服务器的玩家「拔掉插头」时，游戏／服务器状态的迁移问题。它还是反作弊的噩梦——充当权威服务器的机器有可能享有延迟优势（视架构而定），可能遭受 DoS（拒绝服务）或 DDoS（分布式拒绝服务）攻击，如果是 PC，还可能被玩家破解。

• 点对点（Peer to peer）——与监听服务器有诸多相似之处。在点对点架构下，每个客户端也都是一台「迷你服务器」，各自维护着对世界现状的一份视图，并且每位玩家都与其他每一位玩家保持连接。点对点架构无法扩展到大量玩家，即超过 8 人的情况；NAT 问题更严重（因为所有玩家都要连接到其他所有玩家），作弊的可能性也大得多（没有任何一方是权威方）。

• 专用服务器（Dedicated server）——专为在数据中心或云端运行游戏模拟而搭建的服务器，并被信任为权威方。前述监听服务器／点对点架构的其他所有问题都被降到了最低。专用服务器的最大问题在于容量——确保您在全球各地运行着足够多的服务器以匹配容量需求。注意：即便采用这种架构，如果您过于信任客户端（哪怕只是一点点），也会让您的反作弊、反欺诈和反有害行为工作变得更加难以执行。

在 Titanfall 之前，专用服务器都托管在数据中心的裸金属服务器上，这些服务器必须提前数月订购，而且最短承诺期为 30 天。如果您为一次发行订购的服务器太少，玩家就会难以进入对局，而纠正这一问题可能需要数周时间（因为订购有交付周期），等到您纠正过来时，您已经惹恼了社区中的大多数人，他们也已经转投其他游戏了。而如果您为发行订购了过多服务器，则可能会因服务器闲置而白白浪费数百万美元。随着您试图不断扩容以匹配活跃玩家规模，这一过程还得定期（每月）反复上演。

Titanfall 是首款在发行时就为专用服务器配备自动扩容能力的游戏。它使用的是 Microsoft 的 Thunderhead 系统。Titanfall 会「即时」启动专用服务器，并在不再需要时将其关闭；由于存在延迟，它会尽量保留略多于所需的容量，但有时玩家仍可能需要等上一两分钟。

Titanfall2 转向了一种混合模式：在全球各地的数据中心部署裸金属服务器，当某个地区的数据中心容量耗尽时，再随之补充云端容量。Apex Legends 发行时也采用了这种模式——它在成本与容量扩展之间取得了良好的平衡。

在测试基础设施方面，「瘦客户端」（thin clients，即一种模拟玩家进出游戏等交互行为的客户端）是一种很好的方式，但维护开销相当可观。此外，也有若干 API 测试框架可以取得类似的效果。对所有测试结果都要「持保留态度」——它们充其量只是对玩家在游戏中实际行为的最佳猜测，因此可能会与实际情况相去甚远——而且，仅仅一项新的游戏功能就可能让玩家的交互行为发生翻天覆地的变化！

在测试专用服务器方面，最理想的做法是让客户端通过正常的玩家流程运行机器人（bots），连接到专用服务器并进行游玩（服务器代码保持纯净）——但这很难创建和维护。让专用服务器自身运行机器人来代替玩家，可以接近这种效果（此时服务器代码会被污染），而且实现起来要容易得多；除此之外，就是尽可能安排真人在专用服务器上游玩，以对专用服务器进行压力测试——您能投入的机器人／真人越多越好。

我记得在 Apex Legends 上，任何人都极难预测基础设施需要支撑的峰值同时在线用户数（PSU，也称为 PCU，即峰值并发用户数）——EA 当时没有一款免费的 PC／主机游戏，而我们的营销策略是「确保在我们开始宣传 Apex 时，玩家手里就已经拿到了游戏」。我们当时的目标是确保基础设施能够承受一定数量的用户。2018 年 10 月，我与时任 EA 首席技术官的 Ken Moss 开了一次会。Ken、Laura Miele 和 Andrew Wilson 最近都玩过 Apex，都玩得非常尽兴。Ken 认为 PSU 的预测值远远偏低。我问 Ken 他认为我们应该以多少为目标。Ken 说 600 万，依据是 Fortnite（含移动端）经常突破 800 万——与其在偏低的数字上栽跟头，不如宁可多花些钱。此后，我们的很大一部分精力都放在确保能够扩容至 600 万上（我们确实不得不做出一些改动）——所幸我们这么做了，因为在首个发行周末，我们就轻松突破了 200 万，而我们最初的架构根本无法支撑这样的规模。

GGWP：在发行前阶段，您会采用哪些内容审核策略？

FG：在 Apex 上，我们的重心是确保反作弊足够稳健。对于文字聊天和语音聊天，我们（除了支持 CVAA 之外）什么都没做。这一方面是因为「缺乏数据指标」来判断文字聊天和语音聊天是否会滋生有害行为，另一方面则是因为我们有 Ping 系统，它在内部试玩测试中很受欢迎，这意味着玩家并不需要使用文字聊天或语音聊天。

对于未来的游戏，我一定会确保在发行之前就把 UGC（文字聊天、语音聊天等）审核功能构建到位。

GGWP：在发行前的测试阶段，尤其是对于大规模多人游戏，您如何确保游戏基础设施的稳定性与安全性？

FG：在安全方面，EA 拥有一支出色的安全团队、一个健康的安全社区，每年还会定期举办一场内部安全大会。在 EA，任何一款游戏发行之前，安全团队都会审查其基础设施和代码，并可提供渗透测试、定期代码扫描、凭据的安全存储、关键系统的代码审查，同时还设有一支应急响应团队以应对违规事件。

安全意识是团队必须持续强化的东西（「永远不要信任客户端」），功能以及代码／系统也需要定期审查。您的游戏一旦发行，就会持续遭到极少数玩家的攻击／弱点探测（每款游戏都是如此）——这些人包括试图作弊者、想利用 Bug／漏洞牟利者、数据挖掘者，以及企图实施欺诈的人。

在稳定性方面，则包括持续集成、支持以「瘦客户端」实现自动化的测试基础设施、客户端上的机器人、服务器上的机器人、一支庞大的 QA 团队、定期的内部试玩测试、出色的崩溃报告等。

GGWP：Fred，感谢您为那些立志打造令人难忘且成功的游戏的开发者们分享的真知灼见与指导。

FG：不客气！

---

关于 Fred Gill

Fred Gill —— LinkedIn

Fred 在电子游戏行业已经从业 40 多年。他的职业生涯始于 17 岁那年，当时他卖出了自己的第一款游戏。1988 年毕业后，Fred 与四位朋友共同创办了一家游戏公司，并在此后的 15 年里带领公司发展成一支 100 人的团队。这家公司最终于 1997 年被收购。2002 年母公司倒闭后，Fred 又创办了另一家小型开发工作室，这一次担任 CEO。然而，他发现担任 CEO 并不那么令人愉快，于是又转回到技术总监的岗位，加入了 EA 旗下的一家工作室。该团队在 11 个月内负责打造了 Battlefield: Modern Combat 的单人战役部分（作为 Dice 所开发多人模式的补充）。

Fred 后来于 2006 年加入 Swordfish Studios，之后重返 EA，加入了一个名为 EA Partners 的小型部门。在这一岗位上，他与多家独立工作室合作，以 EA 作为发行商，帮助他们的产品推向市场。他参与发行的作品包括 Crysis 2、Syndicate、Crysis 3、A Way Out、Unravel、Titanfall 以及 Titanfall 2（等等）。2017 年 EA 收购 Respawn 后，Fred 于 2018 年加入 Respawn，担任工作室技术总监，最终成为技术副总裁兼技术负责人。他的贡献包括协助发行 Apex Legends，并一直担任该系列的技术总监直至第 18 赛季。Fred 于 2023 年 8 月退休，回归本心，为自己制作游戏，且并不指望它们能取得商业上的成功。Fred 目前还在帮助两家慈善机构，其中一家由他自己创办（Antidote Gamers），旨在帮助对抗电子游戏中的有害行为。