Godot3游戏引擎入门之零一：【翻译】为什么要选择 Godot 引擎

2018-08-24 by Liuqingwen | Tags: Godot 翻译 | Hits

一、前言

本文作为我的 Godot 系列文章的第二篇，是一篇翻译文作为 Godot 的优点说明吧，虽然文章发布于去年，但还是很有借鉴意义，翻译的不是很好请海涵！

作者简介：
Rock Milk

来自 Brasil 的另一个游戏开发高手。在此体验 Reakt 游戏：https://play.google.com/store/apps/details?id=co.rockmilk.reakt
发布时间：2017 年 9 月 27 日
原文链接： https://medium.com/@rockmilkgames/why-godot-engine-e0d4736d6eb0

二、原文：我们为什么选择 Godot 引擎

现在是开发游戏的最好时机。第一个理由就是：你还活着，你如果挂了那就不能再开发游戏了。第二个理由是：获取开发工具从没有这么民主过啊。（哭）

那段美好的回忆

我仍然还记得在 2004 年，那是我的计算机毕业课程的第一堂课。一个长大了的男孩，非常激动的学习如何开发并开始尝试创建一个模糊地存在我头脑中的蹩脚小游戏。我并不是想说我有多老或者多怀旧（尽管两者都有），但是回溯到那个时代，既没有推特（ Twitter ），没有脸书（ Facebook ），更没有其他所谓你现在正在使用的“信息分享”工具。

在巴西我们所拥有最好的东西就是那些隐蔽的网络论坛，聚集了一大堆有着共同兴趣爱好的匿名伙伴们，互相分享着那点点滴滴游戏开发的经验和知识。我都不知道那个时候我是怎么开始使用谷歌搜索去学习游戏开发的。尽管 GameMaker 已经有 17 岁了，而且 RPG Maker 都已经 24 岁了（！），我还从未听说过他们或者使用过他们的某些产品。

我在大学里的第一堂课就是计算机编程基础，教的是 C 语言。那个时候我学会了一点基本的语法，兴奋而又傻逼的我就决定做一个 Zelda 游戏：类似过去的克隆 / 启发型游戏。确实，每一个初学者都有点傻傻的。

这门课程的期末考试是要求使用 Allegro 克隆一个 Pac-Man 吃豆游戏，但其实并不止于此！在我内心来说，贪婪的游戏开发者会觉得吃豆游戏又简单又单调，我想要做的是一个 Zelda 类型的大游戏！后来我发现，对于我这种才学会一个 for 循环的人来说（这都可以作为另一个文章主题来讨论了），吃豆子游戏竟然是一个非常耗时的任务。

像我这种情况，无知就是幸运，没有什么东西可以阻挡我下载 Zelda 游戏中的射击图片，在一个我自己创造的简单粗暴的地图里，用来做移动和碰撞实验（这已经让我感觉自己就像程序上帝了）。不必说，我的吃豆子游戏从未见过天日，开发一个 Zelda 游戏简直有趣多了。

游戏引擎……到处都是游戏引擎

回到现在的日子，到处有着上亿数量的书籍、文章、开发日志，社交网络传播着相关的各种知识和各种引擎。一切都是免费或者类似免费的。按某种分类列举一些我头脑里所能想到的引擎：

Unity / Unreal / CryEngine / Lumberyard
Scirra’s Construct / Stencyl / GameMaker / RPG Maker
Love2D / HaxeFlixel / Cocos2D / Phaser
我还能持续列举下去好几年……我没有开玩笑哦……

因为太多的选择，我们内心通常是矛盾的，到底应该选择哪个呢？

屌丝： Godot 引擎

在自我拼搏的这些年里，我和 Matheus 在引擎和编程语言上积累了大量的经验，不得不说，我们必须提到 Unity 这个引擎，我敢说这是目前在小工作室和独立开发者中最流行的引擎了。 2013 年，在我们深爱的 Critical Studio 工作室，我们使用它开发了 Dungeonland 游戏，在当时来看，相对于其他引擎， Unity 是非常棒的选择。

Some Dungeonland gameplay! Go play with 2 more friends, it's fun and free!

现在来看它仍然是一个很棒的引擎，特别是在 3D 方面。但是在 Critical Studio 工作室关闭后，我需要一个更为简单的工具来做开发。 Unity 体积膨胀大了，加载速度变得缓慢，开发 2D 游戏要 hack 很多东西。

接着我发现了 HaxeFlixel （它更像一个框架而不是引擎），它非常适合快速高效地进行原型设计和小游戏开发，我也能够在多平台上重用同一个代码集，另外它还能够使用 Flash 快速地发布游戏，给我的朋友们进行玩赏尝试。

但是，我觉得还是有什么东西缺失了，或许是某个本地平台和游戏框架之间的桥梁？我想要一个简单地类似 HaxeFlixel 的工具，但是却又拥有更多的自定义控制，就像 WYSIWYG 编辑器或者像 Unity 编辑器那样。

godot

接下来的事情，一个名不见经传的新屌丝出现在城里，它就是 Godot 引擎。 Godot 于 2007 年开始作为一个私有引擎被开发，一直到 2014 年开源。经过 10 年的沉淀，已经变得非常成熟。

当我们发现它的时候，我们的感觉是它很可能拥有我和 Rock Milk 所正在搜寻的一切。我们把 Reakt 打造成了 Godot 测试用的实验项目，并定义了一套全新的产品开发流程。最终我们喜欢上了它，因为我们发现在其他引擎上的缺点都在这里完美解决了。

声明

Starting a Flame War 101

我并没有引发与其他编程语言、框架或者引擎口水战的意思，因此：

我们并没有表示 Godot 比其他引擎更好、更强；（即使如此，也是个人观点而已）
我们并没有表示其他引擎就很差
我们并没有表示对于他们的缺点并不是没有任何解决方案
我们并没有表示 Godot 的解决方案是完美无缺的

这里的关键点在于：说明我们为什么喜欢它，以及它为什么更适合我们的商业和程序风格。如果我有冒犯的地方，请谅解，真的。（但是请不要动怒，没必要，是吧）

OK ，开始吧……

开源和社区

Godot 开源并永久免费。通俗点说就是：

没有个税，也没有所谓的年度、季度收入上限要求
不强求使用它们的启动画面、他们的附加服务或者使用它们的云服务托管你的项目

在 2015 年， Godot 加入了软件自由保护协会 Software Freedom Conservancy ，可以看出 Godot 对此非常关注。

它的开发社区非常活跃，更别说它们的仓库提交量了，经常会有新的文章和进度报告。在 Discord 上能看到大家发挥出的热情互助，也有他们自己的一些游戏讨论。

跨平台编辑和发布

Godot 针对每一个操作系统都有一个对应版本的编辑器： Windows, Mac 和 Linux 。甚至还有一个由 cam12win 放出的树莓派实验版本。

其他一切如常：

桌面发布平台： Windowx, Mac, Linux
手机发布平台： Android, iOS, Windows Phone （实验阶段）以及黑莓系统（我没有开玩笑哦）
网页版发布，使用 Emscripten （ WebGL 2.0 和 WebAssembly 正在开发中）

当然还有一些其他平台的构建计划，甚至 Shin-Nil 已经让他的 2D 平台展示游戏在他的 XBox One 中运行了：

并且 Deponia Playstation 4 也是使用的 Godot 制作。

轻量级

构建好的 Godot 只需要占用你的硬盘的 30M 空间，包含（几乎）了所有内容。如果你需要构建手机版本，你需要下载额外的 200M 的构建模板，仅此而已。

这里我并不是因为下载速度快或者因为其他引擎占用了 3 到 30GB 的大空间而提出这点，而是为了说明 Godot 团队对性能的关注程度。 Godot 打开只需要一眨眼的功夫，我那用了 4 年的旧笔记本打开或者加载时间甚至都没超过 5 秒钟。我所等待过的最长时间大约是 1 分钟，那是发生在点击一个按钮发布到安卓手平台的 Debug 版本之间的时间开销。

当然，最重要的是：它能反应出你的游戏的性能。当我发现 Godot 引擎本身就是一个 Godot 开发的游戏的时候，我被深深地震惊了！

友好的版本控制

你是否曾经遇到过在使用 Unity 或者 Unreal 的时候发生了场景或者预制体或者其他的对象文件在仓库的版本冲突问题？如果有的话，难么你应该知道这是多么痛苦的一件事了，特别是在大型团队里。

在 Godot 中任何对象都是以文本文档的形式保存，对于合并冲突来说是绝对是一种非常友好而且可读性强的文件格式。因为我们能非常轻松地区别开多个场景中的多个对象（关于这个之后会谈论更多），使得每一个团队成员都能够专注于自己的工作。

动画系统

Godot 的动画系统是我见过的最强大而又简单易用的一个系统，我曾经使用过的所有动画工具具有的功能设置它都包含了。你可以对某个对象的任意属性进行动画设置，甚至包括函数的调用。除此之外，它还包含了一个非常简易的动画创建工具。

动手比解释更能体会它的工作原理，我推荐你访问 GDQuest 和 Heartbeast 的视频，两位大牛利用他们的业余时间讲授创建游戏相关经验的视频，大部分是免费的。他们俩各自做了一个关于 Godot 的动画系统的介绍视频：

动画工具介绍

使用剪切动画技巧打造一个蝙蝠动画

真实2D vs 假2D

经常会遇到 Rock Milk 的哲学理论问题。为了弄清楚这个东西，我们创建了一个小而简单的游戏，尝试突破未开发的那些区域和一些创新机制。由于我们是两个家庭的普通人，经常一天只能抽出个把小时来开发我们的游戏，所以我们只专注于 2D 游戏开发。

Godot 的 2D 引擎可圈可点，它不是假的 2D ，就像在 3D 空间把 Z 轴平放一样的假 2D 。对于 Godot 来说这意味着什么呢？

像素作为坐标和单位使用，包括物理引擎中的使用
更加高效、更加易用地 API ，无需在第三个轴上处理逻辑或者数学问题
某些其他引擎上的典型解决方案在这里都变得没必要（例如：把 1 个像素设为一个单元，完美像素渲染， Z 轴分层和相机缩放问题等）

换句话说，我们能很好的控制每个游戏物体的尺寸、位置、速度和碰撞，包括皮肤（ HUD ），这经常是需要进行一个完整的 PITA 设置。（不过我们还是蛮喜欢 Unity 的新 GUI 系统的说）

GDScript 脚本和 API

GDScript 是 Godot 中代码处理的默认编程语言，能和引擎的相关特性非常吻合的结合在一起。

通常只需要编写一点点代码就能做出一大堆动作效果，这是由于它那丰富的 API 。我曾以为每个对象都需要从头开始创建，但是 Godot 已经帮我们做好了，包括每一个操作和我所需要的自定义功能。

另外，我觉得 GDScript 是让新用户拒而远之的最主要原因。我重点列举以下我所听见的抱怨中的几条：

我是不是必须要学习一门只能在 Godot 中使用的编程语言？

是的，朋友，但是这并不会多花费你多于两天的时间。这门语言非常简单，就像 Python 的兄弟版。

最糟糕的情况是：至少你也将会学会另一门编程语言，而且学习新的语言能有助于你进行和别人不一样的思考方式（那是更好的方式）。

我讨厌编程语言

好吧，没有理由一定要尝试，我也没有什么可抱怨的。但是，如果你愿意的话，你可以完全使用 C++ 模块来编写代码然后轻松地导出为 GDScript 脚本。

或许，你可能更希望等待 Godot 3.0 版本的发布（其实它就在 Godot 的社区……开个玩笑），因为 3.0 版将会支持 C# 以及 GDNative 脚本，也就是说到时候你可以使用 Python ， Go ， D ， Rust 甚至 Nim （或者任意其他你想绑定的编程语言）等语言编写代码。

那么它的性能怎样呢？游戏代码如何？额

一般对于你所能想到的 95% 的游戏我相信性能都足够满足了。如果你还是持有怀疑态度，那么像我刚才提到的，你完全可以使用 C++ 模块编写然后获得 C++ 的性能。

如果在你的游戏里，某个部分算法有着极高的性能需求，那么你可以在此部分上单独使用 C++ 进行编程，在其他部分继续采用 GDScript 脚本。

你可以阅读更多 Shin-Nil 的关于性能测试之类的文章。

我的编程工具和软件并支持 GDScript 脚本

Godot 有一个集成的代码编辑器，而且除了基本的脚本编写之外它还具有漂亮的智能代码提示功能（也就是说代码自动完成功能），以及强大的 debug 功能，另外包括运行时编辑功能，你可以看看 Juan Linietsky （也叫 Reduzio ）的视频，他是 Godot 的主要开发者，视频地址在此：

到目前为止，对于外部代码编辑器，完全支持的只有 Visual Studio Code ，使用的是 Godot 工具，由 Geequlim 开发，但是其他软件包括 Sublime Text ， Atom 以及 GEdit 都能支持语法高亮功能。

我的建议是：在批评之前先尝试使用 GDScript 脚本吧。如果你在一周之后还是不能顺利上手，效率也不高，那我赔你一颗糖吧。哈哈。（？）

到这里还是不相信？那看一看 Juan 关于创造 GDScript 脚本的理由吧，或许它能让你改变主意：

https://www.redditmedia.com/r/gamedev/comments/36u80q/godot_engine_11_out/crhjrw6/?embed=true&context=0&depth=1&showedits=false&created=null&uuid=null&showmore=false

节点和场景系统

节点是游戏中能够进行属性编辑的一个基本对象。它可以使一个 2D 精灵，一个 3D 模型，一些 GUI 控件元素或者仅声音的播放功能。 Godot 包含了大量节点可供使用和扩展，因此你可以完全创建属于你自己的节点类型。场景是由一组节点有层次的组织在一起构建而成，如同一棵大树。

这也是我们最喜欢的特性，关于节点这个图做出了最好的解释：

抱歉，对于这门语言（我撒了个谎）

Godot 中一切都是场景。每一个场景都能包含其他场景和节点。你可以轻松地提取子节点作为一个场景，提高它的复用性， fracteed 先生在管道上就聪明地利用了这个特性：

Sceneception = a scene within a scene within a scene. Nested scenes are perfect for items such as pipes #GodotEngine #gamedev #indiedev #b3d pic.twitter.com/KkxC2kAUcK
— fracteed (@fracteed) September 3, 2017

为了让你更好的理解，我这里拿 Unity 来作对比：

在 Unity 中一个游戏物体的行为是通过添加多个组件实现的。每一个组件都是一个脚本，所以一个对象可以有很多个脚本；（噢）
在 Godot 中，每个节点只能拥有一个脚本，当然它本身已经拥有了一些基本的功能。你可以在场景中定义一个游戏物体，它由多个节点和其他的场景组成。这也就意味着默认情况下你可以使用预制体嵌套（ prefabs ）。下面这个例子来自 Godot 的官方文档，表示的是一个 Player 游戏物体：

如果你想要阅读更多相关的内容，你可以读一下官方文档页面的：从 Unity 到 Godot > 场景系统

小缺陷，但是解决方案已经在进行中

在 Reakt 的开发过程中，我们使用 Godot 2.1.3 版本，发现了一些小的 Bug 和一些怪异的地方：

我有一台 13 寸的 Macbook Pro Retina 。鉴于我所使用的 Godot 软件工具，有些 GUI 面板显得非常紧凑，一些按钮出现在了其他的 GUI 元素的上层，但是没有任何东西可以阻止继续使用它们
当关闭动画工具的时候，它会把当前的编辑节点的默认状态设置为最后我所使用过的状态，我们不得不多次进行重置节点到原始的配置状态。最新的解决方案是，我们在关闭动画工具之前会先创建了一个默认状态并选中它。

除了这点，我们的开发瓶颈在于整合手机平台第三方库，主要有：分析工具、广告中间网络以及崩溃报告。在 Godot 中创建原生模块非常繁琐：你不得不下载引擎源码，在指定的文件夹中创建并包含原生模块，编译 Godot 引擎，接着编译测试版和发布版。如果没问题的话，这些操作会生成一个可以在你的游戏中使用的手机平台模板，如果有问题，那么你不得不使用 USB 接头继续连接到你的手机上重新 debug 测试你的代码模块。啊哈……

所有程序设置好之后你就可以使用它了，重新生成所有模块还是非常快的。在我们的第一个游戏上我们仅仅使用了 Frog-Square 创建的 Godot-Firebase 模块（感谢帮助和支持！）。

我们想实现我们自己的中间网络层（鉴于 Firebase 只含有 AdMob ），但是投入-产出比暂时还是不值得我们这么去做，因为我之前已经提到过， Reakt 仅仅是一个实验项目，而且 GDNative 已经在 Godot 3 引擎中开始使用了，它也修复了一个我们遇到的一个问题，将来我们可以直接使用它，而不需要像我之前提到的那样从头到尾进行一次手动的编译过程。