开发小规模合作游戏所需考虑的8个因素：特邀作品《Breakwaters》

多人游戏的开发相较于其它游戏类型可能需要更多的前期准备，包括专业开发知识、玩家通讯等长期服务以及其它维护成本。 

在下文，我们会介绍制作多人游戏时需考虑的八个因素，及其对小规模合作游戏的影响。并且，我们与Soaring Pixels Games的Phillip Heckinger讨论了工作室即将发布的作品《Breakwaters》，了解团队的开发方式及其背后的考虑。

在选择或开发多人游戏联网方案时，我们通常需要考虑以下八个关键因素。 

• 网络延迟：游戏可接受的延迟量。
• 同场玩家数：每场游戏中的网络玩家数量
• 同步模拟规模：需要在玩家间同步的模拟数据
• 精确性：玩家联网体验的数据准确性
• 运维成本：创建、维护和运营游戏的成本
• 复杂性：联网方案的复杂程度，应用方案对团队经验的要求
• 反作弊：防止玩家作弊
• 方案锁定：在未来替换方案的难度

在考虑好这八个因素、了解每种联网模式所提供的支持后，你就可以开始选择某个模式、开始游戏的开发了。

样板游戏《Boss Room》是此类游戏最好的例子，它的玩家和模拟规模较小，玩家多人合作，游戏房间托管于客户端。 

按照上方标准，《Boss Room》的表现如下：

• 延迟：延迟不超过200ms（包括从中转服务器上跳转）
• 同场玩家数：最多10人，游戏托管于常见PC上
• 同步模拟规模：所有玩家和AI的变换、动画和活动
• 精确度：休闲性战斗机制仅要求有适当的数据精度。
• 运维成本：服务器创建和维护零成本，游戏运行时可使用中转服务器降低成本。
• 复杂度：低复杂度，方便开发者学习多人游戏开发原则
• 反作弊：合作性PVE游戏不必特别担心作弊行为，因为作弊收益不大。
• 方案锁定：我们未来将在专用服务器上运行该样板游戏

你可以在这篇博文中详细了解该样板游戏是怎样根据这八个因素制作的。

需要注意的是，某些小规模合作游戏相比于其他游戏有着独特的需求。例如，《Overcooked！》背后的Team17工作室最初使用的是点对点直连（P2P），但在开发过程中又改成了专用服务器。

这样做的目的是为了满足游戏推出时的需求高峰和总玩家规模。 

那么，你该如何找到适合自己的联网模式呢？我们采访了Soaring Pixels Games的老板菲利普·赫金格（Phillip Heckinger）来了解为什么为这款游戏选择了当前的联网模式。

《Breakwaters》是一款以海洋世界为背景的动作冒险游戏，玩家需要用自己的双手建造建筑、制作物品，努力生存下去，游戏目前处于抢先体验阶段。我们采访了Soaring Pixel Games来询问以上八个因素在选择《Breakwaters》的联网模式时起了怎样的作用。

同场玩家数

该游戏的在线合作模式支持多名玩家一起探索海洋，并且允许四名玩家组队对抗巨人。根据玩家的喜爱情况，Soaring Pixels会考虑增加每场游戏的玩家数量。 

复杂性

《Breakwaters》是一款雄心勃勃的游戏，它带有一个高水准的水模拟系统。为了保证游戏的流畅性、减少加载时间，Soaring Pixels Games将不同的模拟分成了几个抽象层。 

水的模拟会根据水的空间位置和距玩家的距离来激活/禁用，这种激活系统已从单人游戏应用到了多人游戏。模拟、渲染和AI都由单独的系统处理。这不仅能优化单人游戏的性能，还能将多人游戏的模拟和主机数据更轻松地传输给其他玩家。 

精确度

《Breakwaters》使用了一个基于PhysX打造的定制伪确定性（pseudo-deterministic）物理引擎，并将模拟精度锁定在一定范围内。为了能做出直觉般的反应，游戏内的许多系统只需要知道某样东西的大致位置即可，低精度能让系统快速找到由某些事件或玩家行为产生的状态更新。

大部分时候，对象的旋转值甚至与模拟运算毫无关系。如果模拟需要有更高的精度，系统则会通过提高更新频率来增加精度。 

反作弊

由于游戏以玩家合作为主，Heckinger表示反作弊并非团队目前的重点关注事项。这使得游戏在其他因素上能投入更多考虑，比如以哪个设备作为头号模拟数据源。

“我们并不非常注重竞技性，如果游戏表现够好，竞技性可能会在以后被重视起来。我们更关心游戏的乐趣，就算玩家作弊，他们也完全可以继续玩下去，"赫金格补充说。

同步模拟的数据规模

在一个巨大的开放世界里，相互独立的游戏系统会根据玩家的位置来激活或禁用。这时玩家自己的设备决定了客户端的模拟结果，而多人游戏及游戏世界会由一台玩家设备创建。Soaring Pixel Games通过巧妙地设计单人游戏的游戏架构来完成模拟的共享。 

“得益于游戏的设计，许多潜在的网络问题我们都先在单人游戏中解决了，”Heckinger说。

多亏了游戏复杂的细节层级和空间位置系统，团队可在多人游戏中找出那些必要的模拟及直接影响玩家的游戏区域。 

他们可以在模拟出的世界中找出哪些内容需要用到网格组件，因为并非所有的东西都要有一张网格。非独立网络实体对象或不带联网组件的目标对象将被分配到一个带有独立可寻址联网组件的系统中。这些组件会关联到所有公共模拟的目标对象上，减少系统需要同步的数据。 

网络延迟

《Breakwaters》并不依赖低延迟或Twitch（某直播平台）输入。另外，由于Soaring Pixel Games决定将模拟权威下放给客户端，游戏的大部分系统都可以直接改变客户端的状态，无需通过服务器许可（远程调用）来改变状态。 

Heckinger说：“我们的游戏玩法相比其他类型的游戏能容许更多的延迟，它不算什么大问题。”

此外，Soaring Pixel Games经验丰富的工程师们能够优化数据大小、分段传输数据，并用一个自制系统预先标记好某次事件，在延迟最多半秒后再进行传输。Soaring Pixels Games希望玩家明白“方法不佳、结果也会不佳”。 

团队决定不限制世界各地的玩家们相互连接，让网络延迟随距离的变化而变化。他们也不会阻止玩家在一个地点砍下并丢掉1000棵树。Phillip承认，专门的托管服务可以极大地改善网络延迟和多人游戏体验，这就引出下一个因素：

运维成本

就预算和成本而言，Soaring Pixels Games认为客户端的监听服务器是项目初期最具性价比的选择。游戏的许多元素的确可以支持客户端的监听服务器，但即便如此，他们也更愿意使用专用服务器。这里的决定性因素是商务运营和成本。

“要不是市场上的服务器普遍很贵，我们一定会用服务器托管的方案，”Heckinger说，“我们不觉得服务器托管在这款游戏中能有多高的性价比，但我们打算在未来让用户能接入自己的服务器，让他们的游戏世界能保存地更久。 ”

方案锁定

在所有因素中，Soaring Pixel Games最关心的似乎是方案锁定。Heckinger他们经常会问自己：“怎样才能以最合理实惠的方式来避免系统依赖项？”

《Breakwaters》团队知道几个目标平台都有着各自的要求。对他们来说，更重要的是解决方案要有简单的集成方法，方便提取、封装代码，让游戏代码能更轻松地移植到不同的服务和堆栈。

与其只一种解决方案作伴，他们决定在客户端和主机/服务器端上用简化的C#建立自己的netcode层。 

最终决定

为了避免方案锁定以及考虑到其他因素，特别是游戏的基本架构里已经包含了类似的模式，Soaring Pixels Games最终选择了客户端——服务器联网模式。他们的联网模式包括一个由玩家设备运行的监听服务器，服务器可向玩家们广播游戏公共模拟的权威数据。 

如果有一天，游戏业务有了需要，他们也能将主机和服务器功能转移到专用服务器上。这就保证了游戏开发的灵活性，还允许游戏的联网模式在规模扩张、玩家变多后做出修改。 

你的游戏是否类似于《Breakwaters》呢？如果是，那建立使用监听服务器的客户端—服务器解决方案也可能是你的选择。 

你是否也想制作一款小规模合作游戏？那就快来用Netcode for GameObjects让游戏联网、用Relay和Lobby让玩家相互连接吧。

Netcode for GameObjects

Unity的新netcode解决方案Netcode for GameObjects可为类似《Breakwaters》客户端主持的多人合作游戏提供解决方案。此类游戏可容忍较高的延迟（约200毫秒），不需要有严格的反作弊措施，并且游戏较为缓慢。 

*你可以直接访问MIT许可下的开源GitHub代码库来了解其它游戏类型的联网方案。

Relay

经济又安全的Relay服务非常适用于小规模合作游戏的联机。目前处于Beta公测阶段的Relay服务可让玩家们直接联机进行游戏，无需用到昂贵的游戏服务器。 

Lobby

那玩家怎样互相共享游戏呢？处于Beta公测阶段的Lobby服务可能会给你答案。Lobbyᴮᴱᵀᴬ允许玩家用简单的游戏设置创建公开游戏房间，供其他玩家搜索、查找和加入。玩家还可以创建私人游戏房间，通过邀请的方式让指定玩家加入。

每款多人游戏的开发和运营都会有不同的需求（和解决方案）。我们将在未来围绕文中的八个因素及其在不同游戏类型中的影响作进一步讨论，敬请期待。 

想要了解下《Breakwaters》？游戏已于11月在Steam上开放了抢先体验。