独立开发商Bit Dragon如何在《Hyper Jam》中实现跨平台联机游戏

大家好，我叫Geordie Hall，是位于墨尔本的Bit Dragon工作室的联合创始人。我要高兴地告诉大家，我们的第一个作品《Hyper Jam》——一款快节奏的电子合成风竞技场对战游戏，还具有动态的技能培养系统——日前在PC、PS4和Xbox One上发售了！

虽然我们只是一个小团队，但是我们发售的游戏具有本地对战、私密联机和跨平台对战模式（包括附加本地玩家），这让我特别自豪。这款游戏的制作过程是一个真正了不起的学习体验，我们不得不在几乎所有方面都逼出自己的极限。令我非常高兴的是，我们选择了使用虚幻引擎制作《Hyper Jam》，因为它为我们这个只有三名程序员的小团队提供了做出这款雄心勃勃的网络游戏所需的工具。


我跟你们说，它的节奏真的很快！

实现跨平台游戏之路

和许多独立网络游戏一样，我们最初的联机试验把重点主要放在使用点对点侦听服务器的私密游戏大厅方面。为了改进网络代码，我们最终决定测试一下专用的服务器，看看它们的对比。经过这次最初的试玩，我们都深感效果良好——特别是在澳大利亚的互联网上。在我们承诺跨平台发售之后，专用服务器的开销看起来也更合理了，而且跨平台联机对战的可能性使我们相信这是值得的。

跨平台对战本身就有一些重大的优点，最明显的就是可供选择的对战玩家变多了。对大型游戏来说，这应该会缩短排队时间和改善玩家体验，但是对小游戏来说，这也许就能决定玩家是找到对手还是失望离开。如果游戏在某个平台上表现不如其他平台，共享配对池还可以避免该平台的服务器变成“鬼服”，这就能缓和差评的影响，延长游戏寿命。如果你还成功支持了跨平台组队，那么你就真正拓宽了玩家范围！

那么作为独立团队，有多大可能实现跨平台联机？如果这是你第一次提供联机服务，那么你肯定会经历陡峭的学习曲线，而且需要克服的障碍之多必然会超过你的预期。但好的一面是，已经有那么多公司在努力整合和普及在线游戏服务，今后这个问题只会变得越来越简单！Epic自己甚至也要提供一整套跨平台联机服务，将在明年推广，让开发者获得更多选择。

如果你和我们一样，做了一个多平台的网络游戏，非常适合跨平台联机，就请继续阅读这篇文章，了解我们在工作过程中得到的经验教训。

专用服务器

跨平台联机的一个重要前提条件是专用服务器。如果你已经在使用点对点侦听服务器，那么你可能已经注意到，如果你只是简单地在一个平台上托管一台侦听服务器，那么从另一个平台连接是行不通的。通常每个平台都有自己的网络驱动程序，处理该平台上的NAT遍历（例如，SteamNetDriver使用Steam Sockets）。但是要进行跨平台联机，需要让每个平台都连接到同一台服务器并且“说”同一种语言（例如使用标准的IpNetDriver）。如果你还是想使用侦听服务器进行私密对战（就像我们做的那样），那么就需要更改运行时使用的网络驱动程序。

虽然P2P很适合玩家互相认识的私密对战，但它的一些固有缺点使它不适合用于对战匹配：

需要依靠主机的互联网连接来获得良好的玩家体验——即使有很好的QoS检查也不例外

主机有对战优势，作为一个客户端预测状态的游戏，这是我们很在意的问题

主机迁移很困难，但是如果不迁移，主机很容易毁掉他人的游戏体验

你不能信任主机，这就排除了排名模式

专用服务器可以解决所有这些问题，但也有显而易见的缺点，那就是需要花钱来托管。对于独立团队，这笔持续支出的成本很难说是合理的，但是在承诺跨平台发布之后，我们决定做这项投资。

如果你以前只使用过侦听服务器，那么专用服务器可能令你望而生畏，但它们其实是非常简单的。你可以构建一个兼有Windows和Linux的服务器，但是因为Linux实例运行起来往往比Windows实例便宜，所以也许把时间花在构建Linux上比较值得。好在UE4把这个过程做得非常简单！安装交叉编译工具链之后，你就可以将Linux作为目标平台之一了。以前Clang比起VC++要挑剔一点，不过现在两者正逐渐变得相似。你还需要检查自己使用的所有插件是否都支持Linux，并且严格控制Gameplay逻辑，使它与装饰性对象分开（因为专用服务器不会运行控件、声音等）。

默认情况下，专用服务器将无头运行并简单地将日志记录到文件，不过你可以添加“-log”参数使它另外启动一个日志窗口，这在开发期间可能非常有用。专用服务器也非常容易集成到你的持续集成（CI）管道中——只要加一个UAT参数就好！当你需要测试Linux服务器时，可以启动一个本地VM或EC2实例，不过一台Windows服务器应该足以完成大部分开发测试了。你甚至可以在PIE中使用专用服务器，这非常适合用来调试蓝图。

云托管

一旦有了专用服务器二进制文件，而且网络代码运行效果良好，你就需要找个地方托管服务器，好让客户端能够连接它！托管选项很多，包括Amazon GameLift、Google Cloud Compute/Kubernetes、PlayFab，等等。在这方面主要应该考虑的是成本、缩放和支持。

你必须能够根据玩家需求来缩放服务器，最好是在非高峰时间尽可能缩减。大多数这类系统会启动一个虚拟机，它分配了特定的IP，运行N个服务器进程，每个进程分别在不同的端口上侦听。然后服务器管理器可以对每个服务器进程分配游戏会话，持续跟踪哪些进程繁忙。一旦实例上的空闲服务器进程数量降到某个阈值以下，系统就会再启动一个VM，它将会再增加N个可用的游戏会话。缩放系统还应该智能地分配新会话，从而允许缩减并充分利用资源（例如，你不会希望五个游戏会话分布在五个机器上）。

大部分提供商具有某种类型的免费层级，你可以用来调试和尝试不同配置，这是试水的好方法。

作为独立团队，成本始终是个问题，你需要做好平衡，想清楚你为了降低服务器成本愿意付出多少额外努力。在计算缩放成本时，主要的公式是“每台服务器的玩家数x每个实例的服务器数x并发玩家数。”GameLift定价页面上有一个典型的玩家需求曲线示例，显示了玩家需求如何影响全天各个时段需要的实例数量，不过其中的数字对于独立游戏来说可能过高了。


针对CPU以及内存优化游戏将会提高你在每个实例上可以容纳的服务器数量，降低你的成本。请记住，你可能还要为网络流量付费，所以优化网络代码实际上能在改进Gameplay的同时改善你的服务器账单！

你需要在每个地区至少运行一个实例来接纳新玩家，但是根据你的可用性需求，你也许可以利用现货/可抢占实例来获得额外伸缩能力，这种实例是云提供商以很优惠的折扣价提供的，缺点是提供商可以在发出通知后短时间内终止它们。

在游戏发售前你还应该早早地根据估计的玩家数量预测成本，这样可以确保服务器为你增加的价值多于它们的成本。在发售之后的几个月或几年时间里，你还需要不断评估成本，有时甚至需要要考虑关服的可能性（例如，你可以退回到P2P服务器）。

如果你已经有了CI管道，可以使游戏服务器以及客户端版本的上传自动化。如果可以选择，最好设置一批用来测试半夜升级版本的服务器，不过你也需要注意主机的存储空间限制等因素。

选择用来托管服务器的地区可能很困难，特别是在发售前，需要小心平衡成本和需求。AWS和Google Cloud在全球覆盖方面都做得很好，AWS最近还在中国开了GameLift。如果你把玩家延迟数据上传到对战匹配器，就能更清楚地看到玩家需求来自哪里，哪些区域可以增加一些服务器。

在发售时你可能还需要进行超量供应，确保能处理任何“最佳状况”下的流量。在发售之日提供支持服务也是很重要的，因为你毫无疑问会犯错，你需要尽可能多的帮助来灭火——或许我现在就在做这样的事！

对战匹配

一旦有了一批可伸缩的专用服务器等待接收游戏，你就需要找到一个方法来将玩家配对。虽然大部分平台都有某种类型的第一方对战匹配API，或者支持跨平台联机，你还是需要一个能够与服务器管理器通信的集中式对战匹配器。

和托管一样，游戏后端有许多不同的选择，既可以使用托管/对战匹配/客户端SDK的完全集成解决方案，也可以让提供商处理服务器/对战匹配，但你仍然需要自己的后端来处理认证和客户端通信。

最低限度，客户端需要能够告诉后端，它们想找到符合某些参数的匹配。然后后端使用每种平台的认证令牌对其请求进行认证，并将它们添加到配对池。找到匹配之后，对战匹配器需要将游戏会话分配给服务器，向每个客户端通报服务器的IP和端口，告诉服务器应该允许哪些玩家加入，以及任何有用的配对数据，例如战队或游戏类型。

在评估不同的选项时，不要只考虑你的当前需求，还应该尽量考虑未来的可能，避免今后发生无法添加优秀功能的情况。例如，

你要的是基于规则的还是基于游戏大厅的对战匹配？

你打算逐步放宽规则吗？

你要考虑延迟信息吗？

你想允许多种游戏类型同时排队吗？

你想在对战匹配中支持派系战吗？

可以跨平台进行派系战吗？

你想支持多个本地玩家吗？

你想要组队战吗？不同派系可以组队吗？

你想不想要异步对战匹配，好让玩家在游戏中等待时可以干点别的事？

你需要限制哪些平台可以在一起对战吗？（希望这个问题最终的答案是“不！”）

你需要回避名单或黑名单功能吗？

你需要访问持久玩家数据来实现基于技能的对战匹配和/或排名模式吗？

你想不想支持回填功能，好让玩家在对战中途加入？

我们能够给出的任何具体建议都很可能会快速过时，但是有一条建议永远不会过时，那就是要尽早开始考虑。

在评估对战匹配功能时，还应该考虑每个后端提供商提供的其他服务，例如玩家身份、好友、上线情况、组队、排行榜、分析，等等。如果你最终使用了某个后端提供商，那么这些附加服务的质量也许能帮助你的游戏胜过竞争对手——而它们都需要花些时间才能很好地集成到你的游戏中。不要匆忙作出以后可能很难改变的决定！话虽这么说，但如果你已经在某些领域使用了某家提供商，却想使用别家来进行对战匹配，那么你也可以那么做。在线服务似乎不可避免要涉及多种经常变动的部分，从哪里采购完全取决于你自己。

版本控制和网络兼容性

一旦你有了专用服务器——特别是有了跨平台联机功能以后——你就需要考虑客户端/服务器版本控制，以及这对于对战匹配的影响。实际上在这方面我并没有看到多少集成得很好的解决方案，所以你可能要自己想办法解决。

如果你需要发布会影响网络兼容性的更新，会发生什么情况？可以发布兼容网络的新服务器版本而不必更新客户端吗？如果你确实需要取消某个平台的跨平台联机功能，可以仍然要求其他平台保持某个版本吗？

客户端更新可能需要花一些时间才会在所有平台和地区实施，所以你可能不希望立即关闭旧服务器，以免没有更新可用的玩家无法游戏。即使某些玩家确实可以更新了，你也不会希望在对战过程中将他们踢出游戏。

创造无缝的更新体验不一定很困难，不过确实需要预先计划。我们接受的设置是，在更新窗口期内使旧版本和新版本都可参加对战，保留旧的服务器，让玩家能够完成对战。我们允许客户端自行检查更新（并在开始新的对战之前应用更新），经过一段合理的传播时间后，我们会关闭旧服务器，并拒绝来自旧客户端的任何请求。如果我们需要部署仅用于服务器的补丁，对战匹配器将把所有新的对战请求都定向到打了新补丁的服务器，而且一旦旧服务器上的所有对战都结束，我们就可以在后台关闭它们。

测试客户端/服务器版本的网络兼容性也很重要，特别是在对现有发行版分支进行修正的时候。如果你使用蓝图原生化功能，从非原生化的客户端连接到原生化的服务器（例如PIE或实时转化）时，也可能遇到兼容性问题。如果你想避免在编辑器中测试时遇到“网络GUID不匹配（Net GUID Mismatch）”错误而跳出，可以将net.IgnoreNetworkChecksumMismatch CVar设置为1。

有一条相关的诀窍是检查TimeoutMultiplierForUnoptimizedBuilds配置变量，它可能会增大编辑器中网络驱动程序的超时阈值。因为我们的连接超时和“滞后”阈值相对较短，所以如果有什么东西的加载或编译时间超出预期，那么在编辑器中进行的测试就往往会发生超时。如果你做的是网络游戏，那么你肯定已经使用了多个PIE窗口和多进程PIE，但我认为花些时间确认一下这些功能与其它引擎中提供的功能相比有多么出色还是值得的。

平台要求

你在跨平台开发过程中应该已经了解到，每种平台都会提出一些很有特定性的要求，特别是在游戏联机的时候。在跨平台联机方面，这可能涉及指示（或不指示）其他玩家在哪个网络上，过滤有敏感词的玩家名称和处理冲突，验证玩家权限和调用其他特定于平台的API。

最好尽早与每家平台的有关人员进行对话，确保你掌握了满足这些要求的所有信息，避免打乱日程表的不快意外。

考虑跨平台联机！

独立网络游戏可能很难做，但跨平台联机是一种有助于扩大对战匹配和提高跨平台投资回报的方法。乍看起来，这需要独立工作室付出很大努力，但这可能成为游戏的大卖点，而且随着游戏服务提供商日渐成熟，各家平台逐步开放，实现跨平台联机只会越来越容易。

希望本文的概述能帮助你了解在为自己的游戏添加跨平台联机功能时需要考虑的问题！

《Hyper Jam》现已在Steam、PS4和Xbox One上发售！

作者：Geordie Hall
来源：虚幻引擎
原地址：https://mp.weixin.qq.com/s/Ph-QYQVlOVhi9Odfyg7Vdw