常见问题

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

Godot 是免费且开源的软件可在 OSI 认可的 MIT 许可证下使用，既自由又免费

简而言之：

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

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

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

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

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

还可以查阅 Godot 网站上的许可页面。

Godot 支持哪些平台？

编辑器：

  • Windows

  • macOS

  • X11（Linux、*BSD）

  • Web

  • Android (experimental)

导出游戏：

  • Windows（以及 UWP）

  • macOS

  • X11（Linux、*BSD）

  • Android

  • iOS

  • Web

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

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

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

有关这方面的更多信息，请参阅导出和编译 Godot 章节。

Godot 支持哪些编程语言？

Godot 官方支持的语言是 GDScript、Visual Scripting、C# 和 C++。请参阅编写脚本章节中的各个语言的相关段落。

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

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

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

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

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

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

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

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

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

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

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

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

  1. Godot 使用多线程，而大多数脚本虚拟机对线程的支持不佳（Lua、Python、Squirrel、JavaScript、ActionScript 等）。

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

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

  4. 没有原生的向量类型（vector3、matrix4 等），导致使用自定义类型实现时，性能大大降低（Lua、Python、Squirrel、JavaScript、ActionScript 等）。

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

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

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

Godot 支持哪些 3D 模型格式？

Godot 通过 OpenCollada 导出器（Maya、3DSMax）支持 Collada。如果你使用的是 Blender，可以试一试我们的 Better Collada Exporter。

Godot 从 3.0 版本开始支持 glTF。

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

Godot 会支持【此处插入 FMOD、GameWorks 等闭源 SDK 的名字】吗？

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

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

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

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

如何在我的系统上安装 Godot 编辑器（进行桌面集成）？

Godot 实际并不需要在你的系统上进行安装就能够运行，因此不会自动进行桌面集成。解决方法有两种。你可以通过 Steam（全平台）、Scoop（Windows）、Homebrew（macOS）、Flathub（Linux）来安装 Godot。这样就会自动执行桌面集成所需的步骤。

另外你也可以手动执行安装文件会帮你执行的步骤：

Windows

  • 将 Godot 可执行文件移动到稳定的位置（即你的 Downloads 文件夹之外），这样你以后就不会不小心对它进行移动、不会破坏快捷方式了。

  • 右键单击 Godot 可执行文件，选择创建快捷方式。

  • 将创建的快捷方式移动到 %LOCALAPPDATA%\Microsoft\Windows\Start Menu\Programs。这是针对用户的快捷方式存放位置，会显示在开始菜单中。你也可以将 Godot 固定在任务栏上，右键单击可执行文件并选择固定至任务栏即可。

macOS

将解压出的 Godot 应用拖拽至 /Applications/Godot.app，如果需要的话还可以再拖到 Dock 栏上。只要 Godot 在 /Applications 或 ~/Applications 中，“聚焦”就能找到它。

Linux

  • 将 Godot 二进制文件移动到稳定的位置（即你的 Downloads 文件夹之外），这样你以后就不会不小心对它进行移动、不会破坏快捷方式了。

  • 将 Godot 二进制文件进行重命名，然后移动到处于 PATH 环境变量中的某个位置。通常是 /usr/local/bin/godot 或者 /usr/bin/godot。这个操作需要管理员权限，不过能够让你通过输入 godot 直接从命令行运行 Godot 编辑器。

    • 如果你无法将 Godot 编辑器二进制文件移动到受保护的位置，你可以将它保存在你的家目录中的某个位置，然后修改下方链接的 .desktop 文件中的 Path= 行，让它包含指向 Godot 二进制文件的完整绝对路径。

  • 将这个 .desktop 文件保存到 $HOME/.local/share/applications/。如果你有管理员权限，你还可以把这个 .desktop 文件保存到 /usr/local/share/applications 中，这样所有用户就都能够使用这个快捷方式了。

Godot 编辑器是绿色应用吗？

默认配置下，Godot 是半绿色的。从任何位置运行都可以运行它的可执行文件（包括无法写入的位置），无须管理员权限。

不过，配置文件会写入到针对用户的配置或数据目录。通常来说，这是不错的做法，但也意味着将包含 Godot 可执行文件的文件夹复制到另一台机器上是无法带走配置文件的。更多信息请参阅 Godot 项目中的文件路径。

如果你需要真·绿色的操作（例如放到 U 盘上使用），请按照 自包含模式 中的步骤操作。

为什么 Godot 使用 Vulkan/OpenGL 而不是 Direct3D？

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

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

从长远来看，我们可能会为 Godot 开发 Direct3D 12 渲染器（主要用于 Xbox 的目的），但 Vulkan 和 OpenGL 仍将是所有平台（包括 Windows）上的默认渲染后端。

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

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

这有几个原因：

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

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

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

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

For all the reasons above, we have to be selective of what we can accept as core functionality in Godot. This is why we are aiming to move some core functionality to officially supported add-ons in future versions of Godot. In terms of binary size, this also has the advantage of making you pay only for what you actually use in your project. (In the meantime, you can compile custom export templates with unused features disabled to optimize the distribution size of your project.)

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

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

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

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

  2. 使用 Godot 中的拉伸选项；2D 保持宽高比时拉伸效果最好。请参阅教程 多分辨率 来学习如何实现。

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

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

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

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

如何扩展 Godot？

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

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

您还可以查看 GDScript 的实现，Godot 模块以及 Godot 的非官方 Python 支持。这个将是您了解如何将第三方库整合到 Godot 中的第一步。

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

当它准备好的时候！详情见 在编辑器中运行代码。

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

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

开始的第一个地方就是问题列表。找到一个与您产生共鸣的问题，然后继续阅读如何贡献指南，学习如何使用 fork、修改和提交 Pull Request（PR）。

我有个关于 Godot 的好主意，该如何分享它？

想要把一些想法带给Godot会很诱人, 比如导致大量核心变化的想法, 某种模仿其他游戏引擎所做的事情, 或者您想要在编辑器中构建另一种工作流程. 这些都是伟大的, 我们感谢有这些想要积极贡献的人, 但Godot的焦点是而且始终将是在 路线图 中概述的核心功能. 排查 bug 和解决问题, 以及与Godot社区成员之间的讨论.

Godot社区中的大多数开发人员都会更有兴趣了解以下内容:

  • 你使用该软件的经验和你遇到的问题(我们关心的不仅仅是关于如何改进它的想法).

  • 你希望实现的功能, 因为你需要它们用于你的项目.

  • 学习软件时难以理解的概念。

  • 你的工作流程中希望优化的部分。

  • 教程不全的部分或者文档不清晰的部分。

因此, 请不要觉得您对Godot的想法是不受欢迎的. 相反, 首先尝试将它们作为问题重新表述出来, 这样开发人员和社区会有一个功能依据, 可以为您的想法奠定基础.

与社区分享您的想法和问题的一个好方法是用案例来说明. 解释您想做什么, 您期望发生什么行为, 然后实际发生了什么行为. 以这种方式体现问题和想法, 将有助于整个社区始终专注于作为一个整体改善开发者的体验.

最好可以附上截图、具体数值、测试用例或示例项目（如果适用的话）。

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

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

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

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

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

是否能将 Godot 作为库使用？

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

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

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

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

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

这个自定义 UI 工具包不能作为一个库使用，但你仍然可以通过使用 Godot 编辑器来创建非游戏应用程序。

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

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

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

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

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

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

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

为什么 Godot 不使用异常？

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

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

为什么 Godot 不使用 RTTI？

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

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

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

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

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

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

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

请参阅 贡献方式。

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

请参照 Godot 官网上的相应页面。