以下是 Michal Buras 在 2024 年 9 月 10 日的现场服务游戏峰会上的演讲记录。

期望的收获是更好地理解可用的不同网络技术，以及不同游戏基础设施的好处和挑战。具体来说，就是点对点作为一种技术及其挑战，特别是主机迁移，以及这如何影响你的开发资源。

演讲 - 完整记录

介绍

大家好，

我叫 Michal，今天我想展示我们为创建完美的多人游戏解决方案所经历的旅程，针对 Six Days in Fallujah，特别是我们对点对点解决方案的分析以及如何管理主机迁移。此外，我们还将讨论专用服务器游戏托管。

希望你能收获到更好地理解可用的不同技术，以及不同游戏基础设施的好处和挑战。

简单来说，我们将讨论点对点作为一种技术及其挑战，特别是主机迁移，以及这如何影响你的开发资源。

然后我们将探讨不同的专用服务器托管基础设施选项，包括裸金属、计算虚拟机和容器实例。

关于演讲者

首先，介绍一下我自己，我是 Michal Buras，负责 Six Days in Fallujah 的网络/在线工程。该游戏取得了非常成功的推出，我们正在持续开发。

个人来说，我已经在游戏开发领域工作了六年，在软件开发方面工作了十年。我最初是在工业领域从事 VR 而不是游戏的，但我想做游戏。因此，我加入了 [多人游戏组] (MPG)，在那里我做了一些关于网络的迷人工作，除此之外还有其他的事情。之后，我在 Breach Studios 担任通才工作，但我真的想从事网络，所以我加入了 Highwire Games。

演讲的目标

我为什么在这里，对吧？

在最初的发布后，我被我的团队指派为 Six Days 添加主机迁移，这是我们游戏体验的关键，也是游戏能够持续在线的关键。我意识到，不同技术之间缺乏信息和分析 [可用]。

此外，出于好奇，我想评估点对点 [网络] 是否真的是我们在游戏开发中所说的那种成本效益解决方案。

最后，我希望这个探索能够帮助其他人，并扩大游戏开发社区可用的知识。

多人游戏中的点对点网络 - 基础知识

我知道在场的并不是每个人都是工程师，所以这里有关于点对点的基础知识以及如何通过网络连接玩家的快速概述。

点对点，正如他们所说，应该是非常简单的。游戏创建一个监听服务器，然后使用公共 IP 将所有玩家连接到服务器。不幸的是，真相并不像看起来那么简单，因为你的公共 IP 不是你自己的公共 IP。

这意味着 IP 地址是共享的。你的互联网服务提供商将多个用户分组到单个 IP 下，过程称为网络地址转换。

唯一的区别是每次请求网页或其他资源时，临时分配给你的端口号。对非工程师来说，想象一下服务器的 IP 就像公寓大楼。然而，每栋楼都有多套住房。每次你点披萨时，都会给你一个唯一的套房号码，并且这个号码会随着时间的推移而变化。

而这会导致很多困惑。

我们需要找到一种机制来获取被分配的号码，并以某种方式与其他玩家分享这些信息。

点对点网络 - STUN 服务器

这个解决方案被称为 STUN 服务器。把它想象成黄页。如果你希望人们能够找到你的业务，你必须用你当前的号码更新黄页。

不幸的是，这个解决方案并不安全，因为我们的套房号码可能会被进一步共享，互联网的任何人都可能向我们发送任何信息。大多数服务提供商发现这不安全，并阻止这种流量。

点对点网络 - 中继服务器

替代方案，即我们拥有的唯一替代方案，是中继服务器。你私有的地址不会与其他人共享，除了中继信息的服务器。

几乎没有计算的服务器，但因为它们需要一定的计算能力，你必须托管它们，这意味着你需要一个服务提供商。

有很多提供中继服务器解决方案的服务可供评估，但在本次演讲中我只谈论我认为最有趣的三种。

中继：Epic 在线服务 - 概述

首先，Epic 在线服务（EOS）提供免费的中继，这意味着零前期成本和零维护成本。

这个解决方案需要最少的开发，他们是跨平台的，具有大厅系统，而你所缺少的唯一东西就是匹配系统。

但是，你对那些玩家的路由没有绝对的控制权。

中继服务器在你的游戏数据包中增加了一个额外节点，它必须通过这个节点传递，这会引入延迟。考虑到中继数量有限，玩家可能会基于当时的可用性被路由到远的地方。这种高延迟在商业游戏中是不可接受的，因为它会导致玩家体验不佳，进而导致流失。这直接导致在 Discord 上的玩家沮丧并损失收入。

中继：Epic 在线服务 - 易受攻击的地方

Epic 在线服务也可能被攻击。

这是来自 Steam 的一款 AAA 游戏的例子。我们这里有一群玩家在大厅中，他们可以交换由 WebSocket 处理的信息。当你制作一个点对点游戏时，你通常会收集关于主办游戏的玩家，即他电脑上的相关信息，对吧？

使用一个叫 Fiddler 的简单应用程序，你可以访问这个大厅信息存储，并以明文方式暴露所有其他玩家的私人信息。这个应用程序只需要两次点击就可以安装，十岁的孩子都可以使用。因此，某人基本上可以从你的数据库中抓取数据，对吧？

这对商业游戏来说是一个巨大的风险。所以在使用大厅系统时，务必小心你所实现的内容。

中继：WebRTC

我发现的另一个有趣的点对点解决方案是 WebRTC 中继。我通过 People Can Fly 的 Outriders 了解到这一基础设施选项，他们几年前有一次 Unreal 深度调研的演讲。

简而言之，这是一个好的实施，因为他们重用了中继服务器，但他们不得不大量修改 Unreal 代码以应对这一点。此外，他们还必须自行托管中继。这是一个需要构建、测试、优化和维护的定制基础设施，这意味着每月会产生本可以用于其他地方的成本。

然而，目前尚不清楚在性能方面它们是否真比 EOS 中继好那么多。

中继：自我开发/自我托管

这让我想到了自我开发的中继服务器。其中一个项目的设想是我们可以在 Unreal Engine 中制作一个中继服务器，序列化数据包，可能分析它们以防止作弊。这在概念层面上没有任何意义，因为增加了计算延迟和成本。

如果你正在计算，它就不再是中继服务器。它变成了一种专用服务器。因此我的建议是，如果你想拥有自己的中继技术，只需从 GitHub 获取一个代理，修改成可在运行时配置。你不需要实现任何类型的数据包重复、排序等，因为你的游戏管理器应该处理这些。

但是如果你现在退一步，想一想这一切。此时，你不是在制作一个游戏，而是在构建基础设施。 在不帮助游戏以内容、更好的技术或功能的情况下烧钱。

这有什么意义？

主机迁移与中继挑战的影响

现在，所有这些服务都有一个基本挑战。

你需要一种称为主机迁移的机制，因为如果主机游戏的玩家退出，所有人都会断开连接。

这是一个你需要解决的基本问题，因为它确实会杀死游戏会话。对于任何商业游戏来说，这是一个巨大的问题，尤其是多人游戏。

我们在 Six Days 中遇到了一个巨大的问题，很多人随意退出游戏，因为我们的游戏非常困难。你只有一次机会，一次击杀，对吧？他们或许不知道自己是主机玩家，或者也许他们并不在乎是主机玩家。所以这成了游戏的障碍。

[在] Six Days 中我仅使用 Unreal 引擎网络驱动程序实现了基本的主机迁移，在最基本的形式下工作良好。我不想在这里详细谈论，因为这是给 Unreal 极客的，因此如果你感兴趣，可以在私下聊天中问我。

但是整个项目需要全面重构，以支持所有功能。现在每个小功能，每个设计师制作的蓝图都必须重新工作，而实现主机迁移没有银弹，除非你的引擎本地支持它，但这将会带来网络带宽成本。

相较于其他替代方案，这存在太大的项目管理风险，而收益则太低。

要点是，虽然中继的前期成本很便宜，但你必须构建的主机迁移解决方案变得极其昂贵。其实并不便宜。

这一切对不同技术和服务的调查使我们意识到，“便宜”的点对点解决方案，我们需要构建一个称为主机迁移的整个系统，这不会是无缝解决方案且用户体验差，而我们还需要去维护它。

所以，要么你雇用额外的员工，要么你推迟你的项目发布日期。在这两种情况下，你都在烧钱。所有这一切都是因为你增加了游戏每个部分的复杂性。我们评估的结果是，我们需要额外的一个测试人员和一个开发者专门负责重新工作所有功能，以便继续前进。

这将使我们每月花费约 $15,000。而且这将会随着时间增长。我希望你记住这个问题，我们还可以为 15K 得到什么？我们还可以使用这些开发资源得到什么？

专用服务器 - 基础设施与成本分解

下一步是评估其他选项，即专用服务器。让我们比较每个选项并进行成本分解。

在我进一步之前，让我们看一下这张图。左侧你可以看到 Six Days 的游戏会话随时间变化。这是 24 小时内的真实历史数据。

如何阅读这个。举个例子，红色曲线代表北美东部，在 UTC 零时有 33 场游戏的峰值。这意味着有 33 个 Six Days 服务器并行运行。

由于我们的游戏需要两个 vCPU 或逻辑线程，这一地区的维持将需要 66 个逻辑 CPU。在右侧，你有这种游戏分发的每月成本。这仅仅是一个地区。因此现在让我们乘以几倍。如果我们将开发资源换成基础设施，我们可以在图中看到多少场游戏。

假设的预算是 $15K。

公共云 (AWS)

首先最明显的，大家都去 AWS。

让我们看看我们可以在这块最知名的公共云上得到什么。我已针对每个地区单独计算了峰值成本，以便尽可能准确。

[Six Days 有] 程序生成地图和非常复杂的 AI，我们的游戏需要更多的计算，但每天仍然有 2,200 名玩家的游戏会话。还不错，对吧？如果我们的游戏像 Valorant 或 Counter Strike，那将接近 10K 玩家会话。

裸金属

老旧的裸金属。

我知道你们中的一些人可能会说裸金属性能更好，可以容纳 20% 以上。在 Six Days 的情况下，我的游戏笔记本无法在单个逻辑线程上运行服务器，所以计算不幸保持不变。

也许更简单的游戏，比如 Valorant，可以做到 8K，就像亚马逊一样。

无论如何，在我们的情况下，这不是选择。我也必须注意，市场上可能有一些额外的灵活裸金属选项，可以容纳更多的玩家，但我在这次演示中无法提及。

容器实例 - 概述

所以我开始谷歌搜索容器实例，因为我想看看容器化游戏服务器技术是否有任何进展，后来我发现了这些家伙。

由于容器实例是完全托管的，因此无需任何工程费用，我只需上传游戏镜像，我不在乎地区、开销或我必须在其他基础设施技术中进行的任何配置。

这就是我发现 Edgegap 的方式。我们是第一个以这种方式开发它，使其可用于多人游戏。

容器实例 - 镜像缓存

所有公司都喜欢 Azure，因为我为什么会想到容器实例？我不是凭空想出来的。

第一次为一家 VR 公司进行基础设施设置时，我在寻找比扩展云计算更好的选择。我在 Azure 中找到了容器实例，但它们部署得超级慢。

因为它们不进行镜像缓存，而 Edgegap 则会。

我很高兴终于发现有人为容器实例实现了这个缺失的东西。这使我们能够在相同预算下处理比公共云多两倍的工作量。而且再次，如果这款游戏是类似 Valorant 的话，15K 美元将有效覆盖整个游戏的服务器基础设施的每月预算。

容器实例 - 分布式编排

在这里还要注意的另一个很酷的事情是，使用容器时，我们不受任何特定数据中心的限制。

例如，我们可以在开普敦每天为朋友托管一场游戏，而不必管理一个本地的 Kubernetes 集群，在其余时间将闲置。

这使我们的游戏更加包容。

通常，当你制作游戏时，会选择在游戏区域中最低垂了的果实，对吧？但如果你添加所有这些小地点，在那里人们因高延迟无法玩，总的来说，这些小果子就会变成一顿美餐。

由于现在有很多关于游戏货币化的谈话，你可以把此视为打开之前不可用的新市场的机会。

公共云 - 浪费的容量与容器实例

为什么这些容器实例如此好？

让我们看看我做的这张图。绿色线代表未平均的真实玩家数据。正如你所看到的，它有峰值、波动，非常难以预测。

当我们使用公共云解决方案时，我们需要保持空闲的、未使用的游戏服务器的开销，以容纳这些玩家和任何潜在的偏差。

这就是为什么增加和减少可用服务器池的速度非常慢。所以，在公共云中，红线下方的区域是你支付的费用，而绿色线下方的区域是你应该支付的费用。红色区域是资金流失的地方。

现在，仅针对单个区域，这项规模还会随着你拥有的区域数量而增加。

容器实例解决了这些问题，因为它们由于之前提到的镜像缓存，可以非常快速地部署。没有启动或关闭的延迟，这样我们可以实时精确地调整需求。

结果，蓝线几乎与玩家流量一致，你只需为你的使用支付费用。

最终比较

所有这一切使我进入演示的最后一张幻灯片，关于我们在 Six Days 中是如何管理网络基础设施的。我们发现，当你和朋友在私人聚会中以点对点方式玩耍而没有主机迁移时，这足够了，而这占了我们流量的 40%。

结论

当我还是个孩子的时候，很多游戏都是像 Counter Strike 这样的点对点游戏。而且曾经是点对点监听服务器。我们从未遇到过主机离开的令人烦恼的问题，因为我们彼此认识，不想破坏乐趣。除非，当然，妈妈进来告诉我们停止游戏去做作业，因为玩游戏是得不到科学学位的。

妈妈部分是对的。但是对于和随机人匹配的游戏来说，点对点模式是一场灾难。尤其是对我们这样的高难度游戏。

所以我们为匹配游戏选用 Edgegap 提供的专用服务器，以确保你的玩家体验不再基于某个随机团队成员的情绪退出。

因此，我诚心推荐你为你的游戏采用 Edgegap 的混合模式，如果你真正想在质量与数量之间取得平衡。

就是这样。感谢你的时间，不要犹豫在 LinkedIn 上添加我。谢谢大家！