
瓦尔海姆 - 多人游戏后端深入探讨

双服务器架构:Iron Gate 在 Valheim 中构建了两种不同的服务器配置(即直接的 Steam 后端和 PlayFab 中继后端),使运营者可以在性能和跨平台覆盖范围之间做出明确选择。
中继的权衡:跨平台联机模式会将所有流量经由 Microsoft Azure 的中继网络路由,消除了端口转发的麻烦,但增加了延迟,并使其依赖于微软的基础设施。
上限即约束:Valheim 的 10 人上限是网络层面的决策,而不是游戏设计上的决策。由于带宽压力,ZDO 对象同步系统在更高玩家数量下会退化。
免费二进制文件,蓬勃生态:通过 Steam 工具免费分发专用服务器二进制文件,催生了一个商业化的第三方托管市场,如今该市场服务着数百万玩家,而铁门工作室几乎零运营成本。
可携带的世界:世界状态保存在两个本地文件中,这些文件可在自托管服务器和租用服务器之间自由迁移,这种可移植性选择强化了玩家的长期投入。
Iron Gate Studio 的官方专用服务器文档,让我们更近距离地了解了 Steam 最受欢迎的生存游戏之一背后的基础设施决策。该指南是写给服务器运维者,而不是工程师的。但仔细阅读后,你会发现其中有意为之的架构选择(例如,两种服务器配置、硬性玩家上限,以及以社区为先的托管理念),任何多人游戏开发者都能从中学到东西。
间接地,Valheim 的做法展示了:当一家小工作室做出基础设施决策,而这些决策的规模远超他们团队单独能够处理的范围时,会发生什么。
两种服务器配置,一款游戏
大多数游戏只发布一种网络后端,然后接受其限制。Iron Gate 却发布了两种,而且这种区别对于任何试图跨平台游玩的玩家都很重要。
Steam 后端通过 Valve 的网络层直接连接玩家。它简洁、开销低,而且不需要中介。但它只适用于 PC 上的 Steam 用户。一群都在 Steam、都在同一平台上的朋友,可以直接运行服务器,无需额外设置。但一旦有人想用 Xbox 或 PC Game Pass 加入,这条路就会被关闭。
跨平台联机后端改变了局面。通过将流量路由到 Microsoft Azure PlayFab Party 中继服务器,它让 Xbox 和 PC Game Pass 玩家也能与 Steam 用户一起游玩。以跨平台模式运行的专用服务器不需要端口转发,而中继会自动处理外部连接。对于运行一个可被跨平台好友持续访问的持久世界的运维者来说,启用跨平台的专用服务器是唯一的路径。
在启动时只需一个标志即可做出选择:-crossplay。加入它,你就启用跨平台联机。省略它,你就得到仅限 Steam 的直接连接。Iron Gate 在其官方支持页面上公开记录了这两种配置,包括各自的权衡。
Azure 的中继
PlayFab Party 是 Microsoft 的游戏多人中继网络。当 Valheim 服务器以跨平台模式运行时,它连接到 Azure 某个区域性的中继节点,而不是直接接受玩家连接。玩家连接到的是那个中继,而不是服务器本身。中继负责在两者之间路由。
Iron Gate 的文档坦率地说明了这会带来什么代价。Valheim wiki 指出,与直接的 Steam 后端相比,跨平台玩家更容易遇到延迟、超时和断开连接。中继增加了一跳网络路径,而且服务器会根据距离大约 17 个 Azure 区域中的某一个自动选择中继位置。运维者无法干预玩家最终落到哪个中继上。某个区域的服务器,可能最终会把流量路由到离部分玩家群体很远的中继,而对此无能为力。
这种取舍在基于中继的架构中很常见。中继简化了连接并消除了配置摩擦,但流量路径总是会比直接连接更长。对于也在权衡同一决策的工作室来说,一种替代方案是用部署在靠近玩家群体位置的小型专用服务器实例,取代通用中继。位于边缘位置、低于 0.25 vCPU 的游戏服务器可以提供服务器权威性,而无需额外的中继跳转。像 Edgegap 的编排网络这样的方案,使得在 615+ 个全球位置上进行分数级部署成为可能,让工作室能够把中继式部署的可达性与直接连接的延迟表现结合起来。
跨平台联机还是 Mod:二选一
双服务器配置带来一个运维者必须提前规划的后果:跨平台联机和 Mod 不能同时运行。
广泛使用的 Mod 加载器 BepInEx 挂钩到 Valheim 的 Steam 网络层。启用跨平台联机会完全用 PlayFab 栈替换掉这一层,而一旦发生这种情况,BepInEx 就不会加载。没有 Mod 运行。两套网络栈并不共享通用抽象层,因此不存在混合方案。
这个决定能清楚地映射到你的玩家群体是谁。Steam 上的一群玩家可以在 Steam 后端上运行一个带 Mod 的服务器,享受直接连接和完整的 Mod 支持。包含 Xbox 或 Game Pass 玩家的一群人则需要启用跨平台联机,同时使用原版服务器。提前知道这一点的运维者,就能据此规划服务器配置、Mod 列表和玩家群体。这是一项实际约束,而不是设计失败。
10 人上限
Valheim 的对象同步系统使用一种叫 ZDO(Zone Data Object)的结构。世界中的每个实体——玩家、生物、建筑部件、驯养动物——都由一个 ZDO 表示。ZDO 状态发生变化时,会重新发送整个对象,而不仅仅是发生变化的字段。实现更简单,也更适合 Mod,但更消耗带宽。随着玩家数量增加,某一区域内活跃 ZDO 的数量也会增加,而每个 tick 的总状态数据也会随之增长。
对游戏网络程序集的社区分析在 James A. Chambers 的博客上有详细记录,发现 ZDO 管理器里有硬编码的发送和接收速率限制。Mod 可以解除这些限制,但社区测试发现,即使加上网络 Mod,随着同时在线玩家接近 5-6 人,性能也会明显下降。10 人上限只是更深层带宽预算的表层体现。大型玩家自建结构和驯养动物数量会独立于玩家人数对该预算施压,而 Iron Gate 自己的文档也承认了这一点。
免费二进制文件,繁荣的生态系统
Iron Gate 最具影响力的基础设施决策之一并不是技术上的,而是经济上的。
专用服务器二进制文件是免费的,任何人都可以通过 Steam Tools 获取,无需购买游戏。Iron Gate 在其官网上发布了完整的设置指南,包括 Docker 指南、启动参数、管理员命令和备份配置。他们把运维者所需的一切都交了出去,然后退居幕后。
结果是,Iron Gate 将服务器成本和运维工作完全外包给了社区和商业托管服务商。像 G-Portal、BisectHosting 和 Nitrado 这样的公司如今托管着成千上万台 Valheim 服务器,负责 DDoS 防护、提供控制面板并运行客户支持——这些成本 Iron Gate 一分钱都不用出。原本可能成为成本中心的部分,如今变成了由愿意每月支付大约 10-15 美元而不是自己运行硬件的玩家资助的分布式托管供应链。
对于考虑社区服务器的工作室来说,这种模式值得研究。免费二进制策略之所以有效,是因为它创造了一个服务玩家、却不要求开发者亲自运营的市场。希望更多直接参与的工作室,包括希望在游戏内直接提供服务器租赁、由系统自动完成开通并将收入回流工作室的工作室,可以探索正是为此打造的编排平台。基础设施已经存在。它是否适合某个工作室的商业模式是另一个问题,但这个选项是真实存在的,而且正变得越来越容易获取。
可携带的世界
在 Iron Gate 的设置指南中,有一个能强化社区托管模式的设计细节被安静地写着:Valheim 的世界状态存储在两个本地文件中。.db 文件包含所有世界进度,.fwl 文件包含种子。两者都由运维者随身携带。
没有云端锁定。自托管的一组玩家只需复制两个文件,就能迁移到租用服务器。某个供应商的租户,只需下载备份并重新上传,就能切换到另一个供应商。Iron Gate 的文档把这视为常规操作,语气平实地一步步讲解。
对于玩家来说,这意味着对自己世界的真正拥有。对于开发者来说,这是一个提醒:持久化架构会塑造玩家信任。能够被保留、迁移和备份的世界,才是玩家愿意长期投入的世界。把世界状态锁定在专有服务上,或许能简化开发,但一旦出问题,它会制造出玩家一眼就能察觉的那种依赖。
---
[编辑注] 与本系列中的其他条目不同,本文引用的是 Iron Gate Studio 的官方专用服务器文档 和 Valheim 社区 Wiki,而不是开发者大会演讲或事后总结。这些架构洞见是真实且可验证的,是根据我们的知识推导出来的,而不是由 Iron Gate 直接陈述的。
原始内容中的所有权利归其各自所有者所有。
书写者
Edgegap团队










