常见问题

可以用 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

  • Linux、*BSD

  • Android（实验性）

  • 网页版（实验性）

导出游戏：

  • Windows

  • macOS

  • Linux、*BSD

  • Android

  • iOS

  • Web

同时支持 32 位和 64 位的二进制文件，默认为 64 位。官方 macOS 版本原生支持 Apple Silicon 以及 x86_64。

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

由于游戏主机制造商施加的许可条款，Godot 团队无法提供开源的主机导出项。但是无论使用哪种引擎，在主机上发布游戏始终是一项繁重的工作。更多相关内容见 Godot 的游戏主机支持。

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

备注

Godot 3 还支持通用 Windows 平台 (UWP)。但由于缺乏维护，该平台端口已在 Godot 4 中被删除，并已被 Microsoft 弃用。对于感兴趣的用户来说，它仍然可以在当前的 Godot 3 稳定版本中使用。

Godot 支持哪些编程语言？

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

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

请注意，加入 C# 支持的时间相对较短，因此你可能会遇到一些问题。Web 平台目前也缺少 C# 支持。我们友好而勤奋的开发社区随时准备在出现新问题时解决这些问题，但由于这是一个开源项目，我们建议你先自己进行一些评估。通过搜索关于未解决问题的讨论来排除问题。

对于新语言，可以通过第三方使用 GDExtension 获得支持（请参阅下面关于插件的问题）。目前工作正在进行，例如，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 高性能来源于 LuaJIT，但是创建与面向对象系统的绑定（通过使用回退）是非常复杂且缓慢的，并且需要大量代码。在用 Python 进行了一些实验后，它也被证明是难以嵌入的。

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

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

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

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

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

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

  6. 难以与代码编辑器集成从而提供代码补全、实时编辑等功能（其他语言都这样）。

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

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

你可以在 导入 3D 场景 文档中找到有关支持的格式、如何从 3D 建模软件导出以及如何导入 Godot 的详细信息。

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

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

正因为 Godot 是开源和模块化的，所以没有什么能阻止你或其他任何感兴趣的人将这些库添加为模块，并以开源或闭源的方式在你的游戏中使用他们。

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

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

如何扩展 Godot？

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

另外，可以看看官方的博客文章，了解 GDExtension ，一种为Godot开发原生扩展的方法：

你还可以查看 GDScript 的实现，Godot 模块以及 Godot 的Jolt 物理引擎集成。这个将是你了解如何将第三方库整合到 Godot 中的一个很好的起点。

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

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

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

Windows

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

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

  • 将创建的快捷方式移动到 %APPDATA%\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 平台上，较小的文件大小是低端设备上快速安装和加载的首要条件。同上，在许多国家，高速网络并不普及。并且这些国家往往有严格的网络流量上限。

基于上述原因，我们必须选择哪些功能作为 Godot 的核心功能。这就是为什么我们计划在 Godot 的未来版本里，将转移一些核心功能到官方支持的附加组件中。在文件大小方面，这也算是一个优点，你的项目可以精简掉没有实际使用过的功能（目前，你可以通过编译自定义导出模板、禁用未使用的功能来优化项目的发布大小。）

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

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

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

  1. 为游戏选择单一的基础分辨率。即使有分辨率高达 1440p 的设备和低至 400p 的设备，设备中的常规硬件扩展也可以在很少或没有性能成本的情况下解决这个问题。分辨率最常见的选择是接近 1080p (1920x1080) 或 720p (1280x720)。请记住，分辨率越高，资产越大，所需的内存就越多，加载所需的时间也就越长。

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

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

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

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

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

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

新项目应该使用哪个版本的 Godot？

我们建议在新项目中使用 Godot 4.x，但是取决于你所需的功能，也许使用 3.x 更好。具体可参阅 新项目应该使用哪个版本？。

是否需要将我的项目升级到Godot的新版本？

新版本在某些方面更安全。一般来说，是否升级取决于你的项目环境。详见 我应该把项目升级到新版本的引擎吗？。

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

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

开始为 Godot 做出贡献的最佳方式是使用它并报告你可能遇到的任何问题。一份带有清晰重现步骤的好 bug 报告可以帮助其他贡献者快速有效地修复 bug。你也可以在在线文档中报告你发现的问题。

如果你准备提交你的第一个 PR，请从上面的链接之一中选择你感兴趣的任何一个问题，并尝试解决它。你将需要学习如何从源代码编译引擎，或如何构建文档。你还需要熟悉 Git，这是 Godot 开发人员使用的版本控制系统。

我们在 贡献者文档 中解释了如何使用引擎源代码、如何编辑文档以及其他形式的贡献方式。

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

我们一直在寻找关于如何改进引擎的建议。用户的反馈是我们决策过程背后的主要驱动力，你在为自己的项目工作时可能遇到的限制是我们在考虑如何增强引擎时的重要依据。

如果你遇到可用性问题，或者当前版本的 Godot 缺少一项功能，请首先与我们的 社区 讨论。社区成员可能会提出其他更好的方法来实现期望的结果。你可以了解其他用户是否遇到过同样的问题，并一起找出一个好的解决方案。

如果你对引擎有一个明确的改进想法，请随意打开一个 提案 issue 。在描述你的问题和建议的解决方案时，尽量具体和明确——只有可行的建议才会被考虑。这不是必须的，但如果你想自己实现它，我们会非常感激！

如果你只有一个大致的想法，没有具体的细节，你可以开启一个 提案讨论 。讨论可以包含你想要的任何内容，并允许自由形式的讨论以寻求解决方案。一旦找到了一个解决方案，就可以打开提案 issue。

在创建提案之前，请阅读 自述文件，以了解有关该过程的更多信息。

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

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

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

请查看 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 使用 SCons 构建系统？

Godot 使用 SCons 构建系统。近期没有改用其他构建系统的计划。我们选择 SCons 而不是其他构建系统的原因有很多，例如：

  • Godot 可以针对多种不同的平台进行编译：所有 PC 平台、所有移动平台、各种游戏主机、WebAssembly。

  • 开发者们经常需要同时将代码编译到多个平台上，或者同一个平台的不同架构上，但他们负担不起每次都要重新配置和重构项目。SCons 可以毫不费力地完成此任务，而不会破坏构建。

  • 无论对项目做出多少修改、配置、增加、删除之类的事情，SCons 都不会 把构建工作搞砸。

  • Godot的构建过程并不简单。几个文件由代码生成（绑定器），其他文件被解析(着色器)，而其他文件则需要提供自定义（ 模块）。这需要复杂的逻辑，而该逻辑更容易用实际的编程语言（如Python）编写，而不是使用基于宏且仅限于构建过程的语言。

  • Godot的构建过程大量使用了交叉编译工具. 每个平台都有特定的检测过程, 需为每个平台编写特殊代码, 将这些作为特殊情况处理.

如果你想要自己构建 Godot，放宽心态， 至少稍微熟悉一下这个构建系统。

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

像许多其他库一样（Qt 就是一个例子），Godot 没有使用 STL（例外是使用了一些多线程基础设施之类的东西）。我们相信 STL 是一个强大的通用库，但我们对用于Godot上的库有特殊的要求。

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

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

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

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

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

为什么 Godot 不使用异常？

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

此外，异常会显著增加可执行文件的二进制大小，并且导致编译时间增加。

Godot使用 ECS（实体组件系统）吗？

Godot不使用 ECS 而是依赖于继承。虽然没有一种普遍的更好的方法，我们发现使用继承的效率已经可以满足于绝大多数使用场景。

也就是说，没有什么能阻止你在项目中通过使用脚本创建子节点来使用组合。这些节点可以在随后的运行时中添加和删除，以实现动态添加和删除。

可以在这篇文章中找到更多有关 Godot 设计抉择的信息。

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

尽管 Godot 的内部实现中尽可能的使用了缓存一致性，但我们认为不应该强迫用户使用 DOD。

DOD 主要是缓存一致性优化，只有在每帧需要处理数以万计的对象，并且做出的修改较少时，才能够提供显著的性能提升。假如你每帧要移动的精灵或敌人只有几百个，那么 DOD 并不会带来有意义的性能提升。在这种情况下，你应该考虑别的优化手段。

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

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

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

见贡献方式。

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

见 Godot 官网上的相应页面。

Previous Next

© 版权所有 2014-present Juan Linietsky, Ariel Manzur and the Godot community (CC BY 3.0). Revision b1c660f7.

Built with Sphinx using a theme provided by Read the Docs.