游戏开发的未来是否会是一条围绕五人团队、四个月原型周期，以及由精选玩家社区把关、决定哪些创意继续推进的流水线？

Avalanche Studios 似乎是这么认为的。在最近发表于 gamesIndustry.biz 的一篇人物专访中，首席出版官 Emma Farrow 准确描述了这一模式：无法证明自身价值的游戏会被砍掉，而淘汰本身被视为流程有效的证明。正如 Michael Duning-PTC 在看完这篇文章后所说：

“能存活下来的创意，都是那些证明了自己的创意。”

下面是我们对这种开发模式在游戏服务器基础设施“自建还是购买”决策上意味着什么的解读。这是 Edgegap 创始人兼 CEO Mathieu Duperré 的观点，而不是对 Avalanche 说了什么或做了什么的断言。

建立在预期失败之上的流水线

Avalanche 的做法，是把移动端开发的纪律直接移植到 PC 和主机平台上。Supercell 是移动端的典型案例：

• 多个小团队，

• 激进的淘汰，

• 偶尔出现一款爆款，为其他一切提供资金。

他们曾有一段时间查看过去 10 款游戏，其中 7 款在原型阶段被砍，2 款在软启动阶段被砍，只有 1 款（Clash Royale）全球上线。Farrow 描述的在结构上也是同样的事情，只不过面向的是 PC 和主机玩家。

这套逻辑是成立的。把创意验证前置到团队规模还很小的时候，可以让昂贵的问题变得便宜。它好不好玩？有没有受众？这些问题最好在第 4 个月、由 5 个人来回答，而不是在第 36 个月、由 200 个人来回答。并且当一个原型失败时，Farrow 把它视为流程正在发挥作用的证据，而不是努力白费的证据。

这种重新定义很重要。

花在最终不会上线的原型上的钱不是浪费，而是找到那个会成功的原型所需的成本。

大多数工作室都会忽略的基础设施算术

这就是游戏服务器“自建还是购买”的问题变得有意思的地方。

传统部署的基础设施（预留实例、提前购买容量、专属机群）是为一款已知游戏、持续且长期的负载而设计的。当一款作品能运营多年时，它的成本摊销效果很好。但如果预期结果是大多数项目都会被取消，那么它的摊销效果就很差。

一家同时推进 3 个原型、每个月都做一次社区试玩的工作室，面对的问题和一家只上线一款长线运营游戏的工作室完全不同。问题不是“如何为上线做扩容”，而是“如何避免为那些永远不会上线的游戏支付服务器费用”。这两者是不同的问题，而大多数传统托管方案是为前一个问题设计的。

按需编排会改变这笔账。一个原型如果在一个月里大约进行了 100 小时的在线社区测试，在按量付费平台上的成本可能只有几美元，与预留容量意味着的数百甚至数千美元相去甚远。这不是边际改进，而是完全不同层级的财务承诺，它让同时运行四五个并行原型在经济上变得合理，而不是鲁莽。Edgegap 的 定价计算器 把这件事变得很具体：工作室可以在做出任何承诺之前，先测试实际测试时长会花多少钱。

五人团队问题

还有第二层影响，它与金钱关系较小，却与时间和组织拖累关系更大。

一个五人原型团队里有程序员、设计师，也许还有一位身兼数职的通才。根本没有位置给专职基础设施工程师。如果搭建多人测试需要 Kubernetes 配置、容器仓库管理，或者去协调预留容量，那么就会发生两种情况之一。要么原型干脆跳过多人测试，这会让社区试玩反馈更弱。要么团队要等待中心化 DevOps，这会悄悄扼杀整个模式所依赖的迭代速度。

还有一个问题是，“自己搭建”在规模化时究竟意味着什么。像 Agones 这样的开源编排平台要想运行良好，需要深厚的 Kubernetes 专业知识、持续维护，以及仅仅为了维持运行就必须投入的专门工程时间。一些投资这类基础设施的工作室会把它合理化为可跨项目摊销的成本。但在一个大多数项目都会失败的模式中，这些“中心化服务”仍然会在内部被分摊到每个原型上，抬高每个小赌注的成本，并提高一款游戏在回本之前必须达到的营收门槛。这与快速迭代的需求正好相反。

自助式、按需编排消除了这个瓶颈。原型团队启动服务器、进行试玩，然后继续下一步。没有工单，没有等待。而且如果游戏在第 4 个月被砍掉，也不会把基础设施债务带到后面。Edgegap 的 编排平台 平均只需 3 秒就能从冷启动拉起游戏服务器，这正是一个小团队进行限时试玩活动时真正需要的响应速度。

一个有依据的观点：这对自建与购买意味着什么

需要说明的是，这更多是我们的观点，而不是行业里已经被普遍验证的模式。

在我们看来，选择做很多小赌注的工作室，其实也是在隐含地选择购买而不是自建基础设施，不管他们是否这样表述。只有当某一款大型游戏能够在很长时间内摊销这笔投资时，自定义服务器基础设施的建设才具有经济上的意义。一个默认大多数项目都会失败的模式，从结构上来说就是不适合自建的地方。

我们已经在使用 Edgegap 平台的工作室身上看到了这一点。Halfbrick Studios——《水果忍者》的发行商——在 Thrill of the Fight 2 上使用了按需编排；这是一款预算较小的作品，但它需要真正的多人基础设施，而不是由专职 DevOps 团队来运维。一款小体量游戏，却以和大作同等的基础设施严谨程度来对待，而没有大作那样的成本结构。这就是这个模型。世界上一些最大的工作室——那些名字你一听就会认出来的工作室——出于同样的原因采用同样的方法：产出波动，就需要成本波动；否则，你就在为那些根本不会上线的游戏支付基础设施费用。

越早意识到这一点的工作室，就能运行更精简的原型周期。那些没有意识到这一点的工作室，则会把基础设施成本背到那些永远不会上线的游戏上，从而让整个快速迭代模式比必要的更昂贵。移动游戏行业已经在多年的迭代中学会了这一点。采用同样开发理念的 PC 和主机工作室，不必再用缓慢的方式去学。

—

本文受 Lewis Packwood 于 2026 年 3 月 10 日在 GamesIndustry.biz 发布的报道以及 Michael Duning-PTC 在 LinkedIn 上发表的观点启发并引用。原始内容的所有权利归其各自所有者所有。