Survival Kids Multiplayer 网络基础设施
今年夏天 , 《 Survival Kids》作为 Nintendo Switch™ 2 的首日发行。该游戏完全使用Unity 6制作,这是Unity有史以来第一个与发行商合作伙伴KONAMI密切合作的端到端开发项目。
在第一天为新平台开发游戏是一项巨大的挑战，但是构建这个项目的内部小团队中有经验丰富的 Unity 开发人员，他们中的许多人已经在 Unity 和游戏领域工作了几十年。本文属系列文章的一部分,深入探讨了游戏是如何制作的,这项工作如何推动Unity对生产验证的承诺,以及其他Unity游戏开发者可以学习并应用到自己的项目中的经验教训。
《Survival Kids》团队工作经历的幕后挖掘是系列的第一部
Nintendo Switch 是 Nintendo 的商标。
《Survival Kids》是由Unity的一个很小的团队制作的。核心小组由大约 10 名各学科的开发人员（美术师、工程师和设计师）组成。高峰时我们只有 20 岁左右，其他 Unity 团队的人也加入了进来。例如，我们的渲染工程师 Steven 经常与我们合作，但他并不总是参与该项目。
不过，作为一个小团队，我们有一些优势。工程师们经验丰富——我们大多数人已经做了20多年的游戏开发，大多是在3A领域，所以我们吸取了很多教训，也犯了很多错误。当然，我们使用 Unity 的经验非常丰富，因为我们中的大多数人已经在这里待过一段时间了。
我们中有些人还作为Unity支持团队的一部分参与过客户项目,例如专业服务/Accelerate Solutions, 现在变成Unity Studio Productions。我们为客户提供有关如何优化项目的建议，甚至与项目团队合作，帮助他们解决困难的技术问题，因此我们对工作室经常犯的错误以及如何修复它们非常熟悉。在开发《Survival Kids》时,我们可以从一开始就将项目设计到正确的轨道上,因为我们知道所有的陷阱都会在哪里,这为我们节省了大量的时间和资源。
今天，我想深入探讨下游戏的网络架构。我们利用Unity推动Multiplayer联网,《Survival Kids》为玩家提供了许多不同的游戏方式,所有玩家都来自同一个联网基础。让我们来深入了解下这些是如何组合而成的，希望它们也能为项目所用。
《Survival Kids》有几种玩法:单人游戏、本地合作游戏以及与朋友在线游戏。在Nintendo Switch™ 2上,玩家还可以使用GameShare将视频串流到另一台Nintendo Switch 2或甚至原版Switch上,然后与电视或设备上的玩家一起玩Multiplayer,这真的很酷。
我们希望我们的设置能够推动所有这些及其他组合。例如，您可以让两名玩家在一台电视上玩分屏游戏，而另一台电视连接着两名玩家在另一台电视上玩分屏游戏 - 这样四名玩家使用两台设备。这种灵活性是我们真正想在架构中设计出来的，它能以许多不同的方式运行。
为此,我们决定采用Netcode for Entities。在将《Survival Kids》的概念介绍给KONAMI后 , 我们直接开始制作原型来找到Multiplayer游戏的乐趣我们以一个现有项目作为启动点,我以前写过一个项目作为概念证明,说明如何将Netcode for Entities用作后端网络,然后在上面写一个GameObject层以利用预制件和动画。并不是团队中的每个人都有使用实体的经验,所以我们决定同时使用GameObjects和MonoBehaviour。
我们也希望GameObjects和MonoBehaviours保留游戏逻辑，因为它们能非常容易地做出原型——这种设置能让你把东西拼凑在一起，编写脚本，从网上下载脚本，或者使用Asset Store包来做出原型。我们想要快速的迭代和自由，但也喜欢Netcode for Entities为我们提供了一个高性能的网络层。我已经在几个客户项目和个人研究项目中使用过它，因此我知道它的质量水平可以推动我们想要的游戏水平。
大约三年前 , 当我们第一次开始时 , Netcode for GameObjects已经存在 , 但它仍然缺少我们想要的一些功能 , 尤其是客户端预测。通过客户端预测，如果服务器和客户端之间存在任何延迟，客户端会预测服务器将执行的操作并立即执行 -因此即使存在延迟，玩家的控件也会有响应感。你不必等待服务器告诉你某个玩家已经移动了或移动了什么 - ⁇ 你已经在移动了。Netcode for Entities从一开始就有这种功能。
对于原型设计，我们基本上先抓取一个已有的项目，然后立即行动。我们从拾取物体、砍树这些简单的事物开始，逐渐充实了游戏玩法。我们还在制作原型，因此代码质量并没有太大问题。我们试图找到游戏的乐趣，并审视我们的游戏支柱，包括“人人生存”。我们想要一款生存游戏，但不希望它过于艰难或具有惩罚性 - ⁇ 我们试图提炼出这种类型真正有趣和令人兴奋的东西。
我们问自己：人们喜欢哪些方面的创作和资源收集？他们不关心什么？这有助于我们确定玩家获取资源的方式、将资源从一处转移到另一处的方式以及制作方式。我们通过使用 GameObjects 和 MonoBehaviour 快速进行原型设计和迭代，就完成了这一切。
因为我们从那个小的概念验证演示开始，我们可以从“开始”就使用互联网地址进行连接。我们可以使用计算机 IP 进行连接,但我们还使用了 Unity 的 Relay 服务,让你能够在云端的 Relay 服务器上托管游戏。有了Relay，任何人都可以使用加入代码加入游戏，人们可以在家或办公室进行连接，而无需VPN或已知IP。这意味着我们可以有规律地每周进行游戏测试 -我们在工作场所和家庭网络上进行测试，这让我们可以使用各种不同的连接速度在游戏玩法的同时对我们的网络架构进行压力测试。最终，Relay被投入生产。
我们尽量贴近公开发布的资源包。如果我们发现其中一个包中存在错误，我们会将其找出来，将其本地导入并尝试修复。有时我们会在之后转到 Slack 并通知 Unity 的 Netcode 团队解释问题和我们的修复程序，以便他们能够接受并开展项目审核 - ⁇ 有时还会将其导入最终版本。我们不一定参与修复，但在生产环境中，我们发现了一些他们尚未发现的问题（尽管他们有时已经有了比我们想出的任何更好的修复方法，或者他们会告诉我们我们用错了）。
因为我们是通过Relay远程开发的，所以直到临近发布时我们才添加离线模式。离线模式不会打开任何网络套接字，它使用一种称为进程内驱动程序的功能。它的行为实际上就像一个网络，有服务器和客户端，但它们在同一进程中执行并相互通信。它们不是通过网络发送，而是直接发送到客户端。这被称为进程内连接，它的速度非常快，因为你不必等待实际字节在网络上传输，而是通过与我们的游戏玩法相同的所有流程。
通过这种方式 , 我们不需要编写不同的版本 - 这是我们的单人模式和Multiplayer模式。单人游戏和离线游戏仍然是个网络游戏，只不过我们没有使用网络 - 一切都在内部发生。
这基本上意味着我们有一个可在任何地方使用的代码架构。但这样做的代价是，在托管游戏或单玩家游戏时，需要模拟服务器和客户端，这就给同时运行这两个服务器和客户端带来了性能挑战。使用专用服务器时，服务器可能会关闭并驻留在服务器群的某处，因此您只需要所谓的客户端，它就可以让一切看起来漂亮并对服务器通信的任何内容作出响应。但在单人游戏方面，由于我们正在模拟，游戏必须两者兼备，不能只坐在专门的服务器上。
优化后的游戏服务器和客户端能在同一款游戏里、同一帧画面里，还能以高分辨率达到每秒60帧的目标，这成了性能上最大的挑战之一。这个指标对我们来说非常重要。
请查看深入学习Survival Kids制作的博客系列的其他部分:
- "Survival Kids的图形和渲染技巧"
- “Survival Kids中的关卡布局和地形工作流程”
请继续关注系列第四篇也是最后一篇博文,即Multiplayer故事的第2部分,该部分深入探讨了我们如何开发这种网络架构以在Nintendo Switch 2上实现分屏游戏和GameShare。
要了解有关Made with Unity项目的更多信息,请访问资源页面。