可以用 Godot 做什么？需要花多少钱？有哪些许可条款？

Godot 是可在 MIT 许可证下使用，既自由又免费

• 你可以自由下载和使用 Godot，用于个人、非营利、商业等任何目的。

• 无论出于任何原因，商业还是非商业，您都可以根据自己的心之所向，自由地对 Godot 进行修改、分发、再分发、改版。

该附带文档的所有内容均在宽松的知识共享署名 3.0（）许可下发布，署名为“Juan Linietsky、Ariel Manzur 和 Godot 引擎社区”。

Logo 徽标和图标均在相同的 CC 共享许可下。注意，Godot 的源代码中包含的某些第三方库可能具有不同的许可。

有关详细信息，请查看 Godot 仓库中的 以及 和 文件。

Godot 支持哪些平台？

同时支持 32 位和 64 位的二进制文件，默认为 64 位。

一些用户也在 Linux 的基于 ARM 的系统上成功构建和使用 Godot，如树莓派。

此外，也有一些非官方的第三方正在进行在一些游戏主机平台上的构建工作。但是，目前默认构建脚本和导出模板中都不包含这些内容。

有关这方面的更多信息，请参阅和 章节。

Godot 支持哪些编程语言？

如果你刚开始接触 Godot 或一般的游戏开发，推荐学习并使用 GDScript 语言，因为它是 Godot 的原生语言。虽然从长远来看，脚本语言的性能往往不如低级语言，但对于原型设计、开发最小可行产品（MVP）和关注上市时间（TTM）来说，GDScript 将提供一种快速、友好、有能力的游戏开发方式。

请注意，加入 C# 支持的时间相对较短，因此，使用该语言可能会遇到一些问题。我们友好且勤奋的开发社区随时准备解决出现的新问题，但由于这是一个开源项目，我们建议你先自己做一些排查。搜索中的讨论是开始故障排除的好方法。

对于新兴语言，可以通过第三方使用 GDNative / NativeScript / PluginScript 获得支持。（请参阅下面关于插件的问题。）例如，Godot 非官方的 和 绑定正在开发中。

GDScript 是什么？为什么要用它？

GDScript 是 Godot 所集成的脚本语言。它是从头开始构建的，目标是用最少的代码让 Godot 的潜力最大化，使新手和专业开发人员都能尽可能快地利用 Godot 的优势。如果你曾经用像 Python 这样的语言写过任何东西，那么你会感到宾至如归。如果您想了解关于 GDScript 的示例、历史、以及完整的功能介绍，请查看 。

使用 GDScript 有不少原因——尤其是在进行原型设计时、在项目的 alpha/beta 阶段、或者项目不是 3A 大作时——但最突出的优势就是整体复杂度降低。

为 Godot 创建一个紧密集成的自定义脚本语言的原因有两点：首先，它减少了启动和运行Godot 所需的时间，使开发人员能够快速上手引擎，提高了生产力；其次，它减少了维护的总体负担，减少了问题的维度，并允许引擎的开发人员专注于排除错误并改进与引擎核心相关的功能——而不是花费大量时间来尝试在一大堆语言中获得一小组增量功能。

由于 Godot 是一个开源项目，因此从一开始就必须优先考虑更加集成和无缝的体验，而不是通过支持大多人熟悉的编程语言来吸引更多用户——特别是在支持那些大多人熟悉的语言会导致更糟糕的体验时。我们理解你更想在 Godot 中使用其他语言（请参阅上面支持的选项列表）。话虽如此，如果你还没试过 GDScript，先试三天。就像 Godot 一样，一旦你看到它有多强大并且开发多迅速，我们认为你将对 GDScript 刮目相看。

有关熟悉 GDScript 或动态类型语言的更多信息，请参阅 教程。

创建 GDScript 背后的动机是什么？

在早期，引擎使用 脚本语言。Lua 速度很快，但是创建到面向对象的系统的绑定（通过使用回退）是非常复杂且缓慢的，并且需要大量代码。在用 进行了一些实验后，它也被证明是难以嵌入的。

为 Godot 创建自定义脚本语言的主要原因有：

1. 大多数脚本语言（Lua、Python、JavaScript）的虚拟机没有很好地支持类扩展，适配 Godot 工作方式的效率极低。

2. 许多现有语言的 C++ 绑定接口都非常糟糕，会产生大量代码、错误、瓶颈，而且效率普遍低下（例如 Lua、Python、Squirrel、JavaScript 等）。我们希望专注于一个更好的引擎，而不是大量的缝合。

3. 在大部分解释型编程语言（Lua、Python、JavaScript、ActionScript 等）中，垃圾收集器会导致延迟或不必要的大内存使用。

4. 难以与 Godot 代码编辑器集成从而支持代码补全、动态编辑等（其他语言都这样）。但这方面 GDScript 支持得很好。

GDScript 是为了减少上述问题以及防止更多问题而设计的。

通过使用 Open Asset Import 库实现了 FBX 的支持。不过，FBX 是私有格式，所以如果你的工作流允许，我们推荐你使用上述其它格式。

Godot 的目的是创建一个遵循免费开源 MIT 许可的引擎，而且是模块化和可扩展的。核心引擎开发社区没有计划支持任何第三方，闭源或专有 SDK，因为集成这些 SDK 会违背 Godot 的精神。

正因为 Godot 是开源和模块化的，所以说没有什么能阻止你或其他任何感兴趣的人将这些库添加为模块并使用它们——无论是开源还是闭源——发布游戏。

如欲了解如何支持您使用的 SDK，请查看下面的插件问题。

如果您知道Godot不支持但是想提供免费和开源集成的第三方SDK, 请考虑自己开始集成工作.Godot不属于一个人；它属于社区, 它与像您一样雄心勃勃的社区贡献者一起成长.

Godot 致力于实现跨平台兼容性和开放式标准。OpenGL 和 Vulkan 是几乎在所有平台上都开放且可用的技术。由于这一设计决策，在 Windows 上使用 Godot 开发的项目将在 Linux、macOS 等平台上也能“开箱即用”。

由于 Godot 只有少数人在处理其渲染器, 因此我们希望维护较少的渲染后端. 最重要的是, 在所有平台上使用单个 API 可以提高一致性, 减少特定于平台的问题。

为什么 Godot 旨在保持其核心功能集较小？

Godot有意不包含可以通过附加组件实现的功能, 除非它们经常使用. 这方面的一个例子是先进的人工智能功能.

• 代码维护和表面 bug。每次我们在 Godot 仓库中接受新的代码时，现有的贡献者往往会承担起维护它的责任。一些贡献者在合并他们的代码后并不总是坚持下去，这会使我们难以维护有问题的代码。这可能会导致维护不善的功能以及从未修复的错误。最重要的是，需要测试和检查回归的“API 表面”随着时间的推移不断增加。

• 易于贡献。通过保持代码库小而整洁, 可以保持快速、轻松地从源代码编译。这使得新贡献者更容易入门 Godot，无需他们购买高端硬件。

• 为编辑器保持较小的二进制大小。并非每个人都拥有快速的 Internet 连接。确保每个人都可以在 5 分钟内下载、解压缩并运行 Godot 编辑器，这使得所有国家/地区的开发人员都可以更轻松地访问 Godot。

• 为导出模板保持较小的二进制大小。这直接影响到 Godot 导出的项目的大小。在移动和 Web 平台上，较小的文件大小是在功率不足的设备上快速安装和加载的首要条件。同上，在许多国家，用上高速网络并不容易。并且这些国家往往有严格的数据使用上限。

基于上述原因, 我们必须选择哪些功能作为Godot的核心功能. 这就是为什么我们计划在Godot的未来版本里, 转移一些核心功能到官方支持的附加组件中. 在文件大小方面, 还有一个优点, 即你的项目可以精简掉没有实际使用过的功能(与此同时, 你可以 来优化项目的发布大小)

如果要适配多种分辨率和纵横比，素材应做哪些处理？

这个问题很常见，可能要归功于苹果公司。苹果一开始将它们的设备分辨率加倍，让人觉得不同分辨率使用相同的素材是个好主意，所以很多人就这么做下去了。起初只有苹果设备这么做，但 Android 和后来的苹果设备又有了不同的分辨率和宽高比，它们的大小和 DPI 变得多种多样。

最常见和最恰当的处理方法是, 为游戏使用单一基本分辨率, 并仅处理不同的屏幕宽高比. 这主要是2D游戏所需要做的, 因为在3D游戏中它只是相机 XFov或YFov的问题.

1. 为游戏选择一个基本分辨率. 即使有高达2K的设备和低至400p的设备, 设备中的常规硬件缩放也会在很少或没有性能成本的情况下解决这个问题. 最常见的选择是接近x1080)或720p(). 请记住, 分辨率越高, 素材越大, 占用的内存就越多, 加载所需的时间也就越长.

2. 使用Godot中的拉伸(Stretch)选项；2D保持宽高比时拉伸效果最好. 参阅教程 来学习如何实现它.

3. 确定最小分辨率, 然后决定是否希望游戏垂直或水平拉伸以获得不同的宽高比, 或者如果有一个宽高比并且您希望显示黑条. 这也在 有所解释.

4. 对于用户界面，请使用 来确定控件应停留和移动的位置。如果 UI 更复杂，请考虑学习 Container（容器）。

就是这样！你的游戏应该能够以多种分辨率运行.

如果希望让您的游戏也适用于具有小屏幕(宽度小于300像素)的古老设备, 可以在导出选项中缩小图像, 并且在App Store或Google Play中将它设为用于特定的屏幕大小.

要扩展Godot, 比如创建Godot编辑器插件或添加对其他语言的支持, 请参阅 和工具脚本.

另外, 请参阅有关这些主题的官方博客:

您还可以查看GDScript的实现, Godot模块以及Godot的 . 这个将是您了解如何将第三方库整合到Godot中的第一步.

Godot 的下一个版本什么时候发布？

当它准备好的时候！详情见 .

我想要贡献！ 该如何开始？

太棒了！作为一个开源项目,Godot的发展得益于像您这样的开发者的创新和雄心.

开始的第一个地方是在 . 找到一个与您产生共鸣的问题, 然后继续阅读 指南, 学习如何使用更改派生, 修改和提交Pull Request (PR).

是否能用 Godot 创建非游戏应用？

是的! Godot 具有广泛的内置 UI 系统, 其较小的软件包可以使它成为 Electron 或 Qt 等框架的合适替代品.

当创建一个非游戏的应用程序时，确保在项目设置中启用 以减少CPU和GPU占用。

也就是说，我们不建议使用 Godot 来创建移动应用程序，因为移动平台还不支持低处理器模式。

请查看 和 ，以了解用 Godot 制作的开源应用程序的例子。

是否能将 Godot 作为库使用？

Godot旨在与其编辑器一起使用. 我们建议您尝试一下编辑器, 因为从长远来看, 它很可能会节省您的时间. 目前尚无计划把Godot作为库(library)使用, 因为这会使引擎的其余部分更加混乱, 难以为普通用户使用.

如果你想使用一个渲染库, 那就使用一个已经建立的渲染引擎来代替. 需要注意的是, 与Godot相比, 渲染引擎通常拥有更小的社区, 这将会使你解决问题的难度加大.

Godot 使用的用户界面工具包是什么？

Godot 不使用标准的 GUI 工具箱，如 GTK、Qt 或 wxWidgets。相反，Godot 使用自己的用户界面工具包，使用 OpenGL ES 或 Vulkan 进行渲染。这个工具包以控件节点（Control）的形式暴露出来，用于渲染编辑器（用 C++ 编写）。这些控制节点也可以在 Godot 支持的任何脚本语言的项目中使用。

这个定制的工具包使它能获益于硬件加速，并在全平台上拥有一致的外观。最重要的是，它不必处理 GTK 或 Qt 所带来的 LGPL 许可注意事项。最后，这意味着 Godot 在“自产自用”，因为编辑器本身就是 Godot UI 系统中最复杂的用例之一。

这个自定义 UI 工具包，但你仍然可以。

为什么 Godot 不使用 STL（标准模板库）？

像许多其他库一样（Qt 就是一个例子），Godot 没有使用 STL。我们相信 STL 是一个伟大的通用库，但我们对 Godot 有特殊的要求。

• STL 模板会创建大量符号，产生巨型的调试二进制文件。我们使用一些名称很短的模板来代替。

• 我们的大多数容器都是针对特定需求设计的，例如 Vector 使用写时复制，我们用它来传递数据，而 RID 系统则需要 O(1) 访问时间来提高性能。同样，我们的哈希表实现旨在与内部引擎类型无缝集成。

• 我们的容器内置了内存跟踪，有助于更好地跟踪内存的使用情况。

• 对于大型数组，我们使用内存池，可以映射到预先分配的缓冲区或虚拟内存。

• 我们使用自定义字符串类型，因为 STL 提供的版本过于基础，并且缺乏适当的国际化支持。

为什么 Godot 不使用异常？

我们相信无论如何游戏都不应该崩溃。如果发生意外情况，Godot将打印一个错误（甚至可以追溯到脚本），但之后它会尽可能优雅地恢复，并继续前进。

此外，异常会显著增加可执行文件的二进制大小。

Godot 提供了自己的类型转换系统，可以可选地在内部使用 RTTI（运行时类型识别）。在 Godot 中禁用 RTTI 意味着可以以较小的性能代价实现相当小的二进制大小。

为什么 Godot 不强制用户实现 DoD（面向数据设计）？

虽然Godot内部针对许多繁重的性能任务, 尝试尽可能地使用缓存一致性, 但我们相信大多数用户并不真正需要被迫使用DoD实践.

面向数据设计主要是缓存一致性优化, 它只能在处理成千上万个对象时获得显著的性能提升(每帧都经过少量修改). 比如, 如果你每帧移动几百个精灵或敌人, 面向数据设计不会帮您的, 您应该考虑一种不同的优化方法.

绝大多数游戏都不需要这个, 并且Godot提供了方便的辅助工具来完成大多数情况下的工作.

如果一个游戏的确需要处理较多数量游戏对象，那么我们建议使用 C++ 和 GDNative 处理需要高性能的部分，使用 GDScript（或 C#）负责游戏的其它部分。

如何支持或参与 Godot 的发展？

谁在为 Godot 工作？如何联系？

请参照 上的相应页面.