Iron Gate Studio 的官方专用服务器文档于 2024 年 4 月发布，至今仍是运营商工作的参考依据，其中详细介绍了如何运行 Valheim 服务器。该文档是为运营商而非工程师编写的。然而，如果将其与 2026 年 9 月 9 日发布的 Valheim 1.0 版补丁说明和常见问题解答放在一起看，这些指令背后的架构设计就会变得清晰起来：两种服务器配置、硬性的玩家上限，以及一种在设计上依赖社区的托管模式。

间接地，Valheim 的做法展示了一个小型工作室在做出远远超出其团队单独管理能力的架构决策时会发生什么。

10 人上限

Valheim 的对象同步系统使用一种名为 ZDO（区域数据对象）的结构。世界中的每个实体（玩家、生物、建筑构件、驯服的动物）都表示为一个 ZDO。当 ZDO 状态发生变化时，会重新发送完整的对象，而不仅仅是发生变化的字段。这更易于实现，对模组也更友好，但非常消耗带宽。随着玩家数量的增加，特定区域内活动 ZDO 的数量也会增加，并且每个 tick 的总状态数据也随之按比例增加。

社区对该游戏网络程序集的分析（在 James A. Chambers 的博客中进行了详细记录）发现，在 ZDO 管理器中存在硬编码的发送和接收速率限制。模组可以解除这些限制，但社区测试发现，在接近 5-6 名玩家同时在线时，性能会明显下降。10 人的上限只是更深层次带宽预算的表层显现。大型的玩家建造结构和驯服的动物种群也会独立于玩家数量消耗这部分相同的预算。

这个上限也是 1.0 版本未作改动的部分。Iron Gate 在另外四个平台上发布了游戏，升级了引擎，并重写了世界的保存方式，而限制却和以前完全一样。 “就像现在一样，Valheim 1.0 将是一款支持 1-10 名玩家的游戏，” 1.0 常见问题解答中写道。在如此大规模的发布中仍保持不变的限制，并不是一个等待调整的占位符。它是同步模型本身的形态，移动它意味着重写状态复制的方式，而不是提高配置中的数字。

这是值得深思的部分。在开发早期设置的玩家上限往往会固化，因为当上限开始让人感到局促时，其下方的架构已经在其上构建了多年的内容。

免费的二进制文件，蓬勃发展的生态系统

Iron Gate 最具影响力的基础设施决策之一不是技术方面的，而是经济方面的。

专用服务器二进制文件通过 Steam 工具对所有人免费提供，并在用户的库中列为工具，无需购买游戏。Iron Gate 在其官方网站上发布了完整的设置指南，包括 Docker 指令、启动参数、管理员命令和备份配置。他们把运营商需要的一切交到他们手中，然后抽身而去。

其效果是，服务器成本和运营由社区和商业托管服务提供商承担。像 G-Portal、BisectHosting 和 Nitrado 这样的公司托管着数千个 Valheim 服务器，处理 DDoS 保护，提供控制面板并运行客户支持，Iron Gate 无需为此支付任何费用。原本可能是成本中心的部分，转而变成了一个由愿意支付月租而非运行自己硬件的玩家资助的分布式托管供应链。

对于考虑社区服务器的工作室来说，这种模式值得研究。免费二进制文件策略之所以奏效，是因为它创造了一个服务于玩家的市场，而无需开发商来运营。如果工作室想要更直接地参与，包括能够从游戏内部提供服务器租赁、自动处理配置并让收入流回工作室，可以探索专为此设计的编排平台。

便携式世界

Valheim 的世界是一个文件夹。每个世界都位于以该世界命名的专属目录中，并且保存操作仅写入发生变化的区域。1.0 补丁说明中描述了一个 “新的保存系统”，该系统 “将世界数据拆分到各个区块中，以减少序列化和写入的数据量，从而提高性能，并且旨在抵御写入过程中的故障。”

该设计一次性解决了两个问题。在每次自动保存时重写整个世界，在全新的地图上成本很低，但在埋满玩家建筑的地图上却很折磨，而且写入过程中的崩溃可能会毁掉整个文件。分块写入限制了这两者。

对运营商来说，重要的是世界是磁盘上的一个文件夹，由运行服务器的人保管。自建托管的团队可以通过复制该文件夹迁移到租用的服务器。向一个提供商租用服务器的团队可以通过下载备份并重新上传来切换到另一个提供商。没有云锁定，Iron Gate 的文档也将移动世界视为常规操作。

对玩家来说，这意味着对自己的世界拥有真正的所有权。对开发人员来说，这是一个提醒：持久化架构塑造了玩家的信任。能够被保管、移动和备份的世界，才是玩家进行长期投入的世界。将世界状态锁定到专有服务可能会简化开发，但在出现问题时，它会制造出玩家会注意到的那种依赖关系。

两种服务器配置，一款游戏

大多数游戏只发布一个网络后端并接受其局限性。Valheim 发布了两个。

Steam 后端在 Valve 的网络层上直接连接玩家。它干净、开销低，且不需要中介。但它也只能触及 PC 上的 Steam 用户。

跨平台联机后端通过 Microsoft Azure PlayFab Party 中继服务器路由流量，正是它将 Steam、Microsoft Store、Mac App Store、Humble、Xbox、PlayStation 5 和 Nintendo Switch 2 玩家放在同一个世界中。Iron Gate 的 1.0 常见问题解答毫不含糊：“Valheim 将支持所有平台之间的跨平台联机。”

一个参数在这两者之间做出了选择。专用服务器随附的示例启动脚本中启用了 -crossplay 标志，这使得触及每个平台成为阻力最小的路径，而运行 Steam 直连则成为了刻意为之的行为。对于一款受众大多在 Steam 之外的游戏来说，这个默认设置就是单一标志中的策略。

Azure 的中继

PlayFab Party 是微软用于游戏多人的中继网络。处于跨平台联机模式的 Valheim 服务器连接到 Azure 的区域中继节点之一，而不是直接接受玩家连接。玩家连接到该中继，而不是服务器本身。中继处理它们之间的路由，以及公共服务器广告和跨平台玩家身份识别。

文档直言不讳地指出了这样做的代价。与直接使用 Steam 后端的玩家相比，跨平台联机玩家更容易遇到延迟、超时和断开连接的情况。中继增加了一次网络跳跃，其位置是根据与大约 17 个 Azure 区域之一的邻近程度自动选择的。运营商无法干预其玩家落户于哪个中继。一个区域的服务器最终可能会通过远离其部分玩家群体的中继来路由流量，且无可挽回。

这是基于中继的架构中常见的权衡，在选择这种架构之前值得了解。要了解中继与权威服务器和点对点连接的对比分析，请阅读 Edgegap 关于网络类型说明的文章。

一种替代方案是用部署在玩家群体附近的微型专用服务器实例来代替通用中继。在边缘位置运行一个低于 0.25 vCPU 的游戏服务器可提供服务器权威，而无需额外的中继跳跃。像 Edgegap 的编排网络这样的平台使跨全球 615 多个地点的分散部署成为可能，它结合了中继式设置的可访问性与直接连接的延迟特性。

跨平台联机或模组：二选一

双重配置带来了一个运营商需要提前规划的后果：跨平台联机和模组无法共同运行。

被广泛使用的模组加载器 BepInEx 挂载到 Valheim 的 Steam 网络层。启用跨平台联机会用 PlayFab 堆栈替换该层，导致 BepInEx 无法加载。这两个网络堆栈没有共同的抽象层，因此没有混合选项。

Iron Gate 对于模组的态度很直接。由于他们不提供官方模组支持，他们“无法保证任何模组都能正常运行”，而且主机版本根本不提供任何模组支持。1.0 引擎升级让那些在发布周对照不断变化的目标重新构建模组列表的运营商切实感受到了这一点。

这一决定直接对应了您的玩家群体。Steam 上的团队可以在 Steam 后端运行带模组的服务器。包含主机玩家的团队需要跨平台联机，随之而来的则是纯净版服务器。这是一个实际的限制，而不是设计上的失败。

—

[编者按] 与本系列中的其他文章不同，本文源自 Iron Gate Studio 的官方专用服务器文档、Valheim 1.0 常见问题解答和补丁说明以及 Valheim 社区百科，而非开发者大会演讲或事后剖析。架构事实是有档可查且可验证的。关于为什么要做出这些决定的解释是我们自己的，并非由 Iron Gate 直接陈述。

本文基于并引用了 Iron Gate Studio 在 valheimgame.com 上发布的原始文档和补丁说明，并得到了 James A. Chambers 的网络分析支持。原内容的所有权利归其各自所有者所有。