“逃离”Unity只需三天？———Godot，用.NET6开发的“下一款Unity”将成为新宠儿？...

GameLook 报道/

    随着 Unity“下载收费”乌龙越闹越大，不少同行都已经在着手寻找替代引擎。那么，其他的选项到底好不好用呢？

　　最近，一位独立游戏开发者在 GD 博客中分享了他将自己的游戏从 Unity 切换至 Godot 的引擎，并且表示整个过程只用了一个周末。

　　以下是 Gamelook 编译 GD 的完整内容：

　　作为《Oni Hunters》、《Minimon》系列的创作者，我在过去十年里看到了游戏研发领域的急剧发展，从我们大多数人都有内部引擎的旧时代，到 Unity 成为独立游戏领域引擎王者的现代，研发工具一直在变化。

　　周末的时候，我完成了一个具有挑战性的任务，将我最新的游戏从 Unity 移植到了 Godot 引擎。接下来介绍一下其中的方法、原因，以及学到的经验：

　　为什么要选择 Godot？

　　多年来，Unity 对我们很多人都是很有帮助的。然而，他们最近决定追溯性地改变服务条款（TOS），尤其是早期做出与开发者对立的保证之后，严重侵蚀了包括我在内的许多开发者对他们的信任，迫使我们不得不寻求替代方案。

　　再来说 Godot，这是一个对 C# 语言支持很好的新星。作为一个完全的 Godot 新手，我非常好奇自己的 Unity 使用经验如何能够转变过来。

　　快速移植背后的“魔法”

　　把一个完整的游戏只用一个周末的时间移植到另一个引擎上？看到这里，我可以想象到很多同行惊叹的深呼吸声。

　　尤其是考虑到《Oni Hunters》的规模，它有着 10 年的历史，4GB 的庞大包体，包含近 3000 个资产（sprites、音频、地图等），以及 500 多个 C# 脚本。听起来是不是几乎不可能？但是，有一种方法可以解决这个几乎算是疯狂的问题，有一个“秘籍”使一切成为了可能。

　　这个秘密存在于引擎抽象层（abstraction layer）。在过去，我经常被棘手的移植经验所折磨，我对《Oni Hunters》的未来持坚定态度。通过将 Unity 特定的 dependencies 限制为 3 个源文件和一个整洁的场景架构，就为无缝移植体验奠定了基础。这可能并不会对所有人适用，但对于像我这样聚焦 2D 复古型游戏的开发者来说，简直是一座省时间的潜在金矿。

　　如本质上讲，我的策略主要是创造自己的 API，这是个位于我的游戏和引擎之间的保护层，使我的游戏逻辑与任何引擎的细节分隔开来。简单地说，这就像是为你游戏的需求量身定制的一个自定义界面。以 2D RPG 游戏为例，这个 API 将包括简单的 Methods，例如 LoadMap（）、CreateActor（）、StartBattle（）等等。

　　对于资产方面的事情，我使用 Tiled 在 Unity 之外制作地图，使它不需要引擎调用。对于像 Sprite Sheet 这样的东西，我确保每一个都遵循特定的尺寸习惯，这使得自动将它们分割成单独的帧并使设置动画变得简单。

　　我看到这种方法在游戏研发圈子里有不同的名称，比如“代码驱动的研发”、“场景极简主义”或者“Runtime 场景生成”。其要点是，保持 Unity 场景大部分为空，然后通过 C# 脚本驱动大部分游戏逻辑和内容。当你继续利用 Unity 的核心功能时，重点将从编辑器稍微偏移。尽管如此，编辑器对于实时检查和修改仍然是至关重要的。

　　虽然这个方法需要提前的时间和规划投入，但它在长期范围内带来的灵活性和独立性是无价的。无论一个引擎在行业内的嵌入有多深，只要有了对的抽象，我的游戏就可以保持自由和灵敏，我知道这不是一个适合所有人的方法。

　　深入了解 DIY 解决方案

　　现在，可能会有一些人反问，“Unity 给我们带来的那些不错的功能怎么办？”我相信会有很多人问这个问题，接下来我们来谈谈。

　　碰撞检测（Collision detection）？在 2D 游戏世界里，相交的线、圆和长方形背后的数学运算都非常直接简单，除非你的游戏需要大量的物理模拟（否则是用不到这个功能的）。

　　粒子系统？在像素风游戏里，依赖手绘粒子效果很常见，它们由美术师创作，并且无缝集成到动画帧当中。

　　寻路（Pathfinding）？像A*这样的经典算法可以在大约 50 行 C# 简洁脚本中快速生成。

　　GUI？很多大程度上取决于游戏，但很多独立游戏对于真正复杂的 GUI 并没有需求。另外，如果你已经做到了从引擎抽取 sprite，那么在此之上打造一个基础的 GUI 也是可行的。

　　这个列表还可以很长。有些时候，独立游戏开发者可能视为必备“引擎功能”的东西，通常都是可以被一系列的创意所取代的，而且往往比我们认为的更容易。如果你能确保代码良好的抽象性，你可以继续在未来所有的项目上使用。

　　Godot 指南：一个独立游戏开发者的第一步

　　对于那些像我一样的 Godot 新手，我们先拆解一些基础东西：

　　场景与节点（Scenes & Nodes）：想象你的 Unity 场景充满了游戏物体。在 Godot 中，主要是带有节点的场景，尤其是 2D 游戏的 Node2D，这是非常相似的。

　　最重要的 Methods：_Ready 和_Process 相当于 Unity 的 Start 与 Update。

　　2D Sprites：Sprite2D 已经涵盖了。

　　处理输入：只要输入_Input Method 即可。

　　音频：AudioStreamPlayer 用起来非常简单。

　　我遇到最主要的麻烦是程序化音频，这是我使用很多的功能，既用于音乐合成播放，也用于随机怪物音效。虽然 Unity 提供的 OnAudioFilterRead 深得我心，但 Godot 也提供了一个叫做 AudioStreamGenerator 的东西，虽然我在使用的时候遇遇到了一些问题，但对于寻找动态化音频解决方案的人来说，它还是很好用的。

　　这个列表主要是根据我移植《Oni Hunters》的需求列出的，你自己的需求可能与上面的差别很大。

　　Godot 是很有前景的，但它也并不完美。我在 4.1 版本尝试的 AudioStreamGenerator 就是证明。幸运的是，这时候我们可以用开源社区的能力。经过一番调查，我找到一个能解决该问题的 PR，打造了我的定制化 Godot 版本，随后就再也没有遇到音频制作的问题了。想要告诉那些害怕从源头打造移植版的人：它用起来比你想象的更简单，只要尝试一下 Godot 的资料文档就行，他们对每一个必要步骤都有很好的资料文档解释。

　　总结

　　Godot 可以当做新的 Unity 吗？目前还不太行，它有着自己的魅力和优势，例如可以获得完整源代码。但也有一些需要追赶的地方。比如，Godot 的 Profiler 并不支持C#，即第三方 .NET 分析工具是必备的。可尽管有这些不方便，我也可以确定的说，Godot 正在成为独立游戏开发者越来越靠谱的选择。

　　而且，我还看到了性能方面的一些增强。这可能是因为 Godot 使用了 .NET 6，而 Unity 仍在使用 Mono 旧版本。

　　从 Unity 切换到 Godot 是一个具有启发意义的过程，我很高兴看到了 Godot 的未来走向。虽然它不可能成为所有人的 Unity 替换引擎，但至少对于那些愿意拥抱新事物的独立开发者是令人兴奋的，敬我们更多的尝试和在充满活力的独立游戏开发者社区分享精神！