独立开发者：如何在3天内将整个游戏从Unity迁移到Godot？

【GameLook专稿，转载请注明出处】

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替换引擎，但至少对于那些愿意拥抱新事物的独立开发者是令人兴奋的，敬我们更多的尝试和在充满活力的独立游戏开发者社区分享精神！