Attention: Here be dragons
This is the latest
(unstable) version of this documentation, which may document features
not available in or compatible with released stable versions of Godot.
Checking the stable version of the documentation...
常见问题
可以用 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（实验性）
Web（实验性）
导出游戏：
Windows
macOS
Linux、*BSD
Android
iOS
Web
在有意义的情况下，支持 32 位和 64 位二进制文件，默认为 64 位。官方 macOS 版本原生支持 Apple Silicon 以及 x86_64。
一些用户还报告在基于 ARM 的 Linux 系统（如树莓派）上成功构建和使用 Godot。
由于游戏主机制造商施加的许可条款，Godot 团队无法提供开源的主机导出项。但是无论使用哪种引擎，在主机上发布游戏始终是一项繁重的工作。更多相关内容见 Godot 的游戏主机支持。
有关这方面的更多信息，请参阅《导出》和《编译 Godot》章节。
备注
Godot 3 还支持通用 Windows 平台（UWP）。但由于该平台端口缺乏维护并已被 Microsoft 弃用，它已在 Godot 4 中移除。对于感兴趣的用户来说，它仍然可以在当前的 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 脚本指南。
There are several reasons to use GDScript, but the most salient reason is the overall reduction of complexity.
为 Godot 创建一个紧密集成的自定义脚本语言的初衷有两点：首先，它减少了启动和运行 Godot 所需的时间，让开发人员可以快速接触引擎并专注于提高工作效率；其次，它减轻了总体维护负担，降低了问题的维度，并允许引擎开发人员专注于修复错误和改进与引擎核心相关的功能，而不是花费大量时间尝试让一小部分增量功能在一大堆语言中生效。
Since Godot is an open source project, it was imperative from the start to prioritize a more integrated and seamless experience over attracting additional users by supporting more familiar programming languages, especially when supporting those more familiar languages would result in a worse experience. We understand if you would rather use another language in Godot (see the list of supported options above). That being said, if you haven't given GDScript a try, try it for three days. Just like Godot, once you see how powerful it is and how rapid your development becomes, we think GDScript will grow on you.
有关熟悉 GDScript 或动态类型语言的更多信息，请参阅《GDScript：动态语言入门》教程。
创建 GDScript 背后的动机是什么？
引擎早期使用的是 Lua 脚本语言。Lua 由于 LuaJIT 的帮助可以达到很快的速度，但是（通过使用回退）创建面向对象系统的绑定既复杂又缓慢，并且需要大量代码。使用 Python 进行了一些实验后，也证明了要嵌入 Python 确实很难。
为 Godot 创建自定义脚本语言的主要原因有：
Godot 使用多线程，而大多数脚本虚拟机对线程的支持不佳（Lua、Python、Squirrel、JavaScript、ActionScript 等）。
大多数脚本语言的虚拟机没有很好地支持类扩展，适配 Godot 的效率极低（Lua、Python、JavaScript）。
许多现有语言的 C++ 绑定接口都非常糟糕，会产生大量代码、错误、瓶颈，而且效率普遍低下（例如 Lua、Python、Squirrel、JavaScript 等）。我们希望专注于打造出色的引擎，而不是大量的集成。
没有原生的向量类型（Vector3、Transform3D 等），导致使用自定义类型时性能大大降低（Lua、Python、Squirrel、JavaScript、ActionScript 等）。
垃圾收集器导致停顿或不必要的大内存使用（Lua、Python、JavaScript、ActionScript 等）。
难以与代码编辑器集成从而提供代码补全、实时编辑等功能（全部如此）。
GDScript 的设计目的就是为了减少上述问题，甚至更多问题。
Which programming language is fastest?
In most games, the scripting language itself is not the cause of performance problems. Instead, performance is slowed by inefficient algorithms (which are slow in all languages), by GPU performance, or by the common C++ engine code like physics or navigation. All languages supported by Godot are fast enough for general-purpose scripting. You should choose a language based on other factors, like ease-of-use, familiarity, platform support, or language features.
In general, the performance of C# and GDScript is within the same order of magnitude, and C++ is faster than both.
Comparing GDScript performance to C# is tricky, since C# can be faster in some specific cases. The C# language itself tends to be faster than GDScript, which means that C# can be faster in situations with few calls to Godot engine code. However, C# can be slower than GDScript when making many Godot API calls, due to the cost of marshalling. C#'s performance can also be brought down by garbage collection which occurs at random and unpredictable moments. This can result in stuttering issues in complex projects, and is not exclusive to Godot.
C++, using GDExtension, will almost always be faster than either C# or GDScript. However, C++ is less easy to use than C# or GDScript, and is slower to develop with.
You can also use multiple languages within a single project, with cross-language scripting, or by using GDExtension and scripting languages together. Be aware that doing so comes with its own complications.
Godot 支持哪些 3D 模型格式？
你可以在《导入 3D 场景》文档中找到有关支持的格式、如何从 3D 建模软件导出以及如何导入 Godot 的详细信息。
Godot 会支持【如 FMOD、GameWorks 等闭源 SDK】吗？
Godot 的目标是创建一个自由开源、MIT 许可、模块化和可扩展的引擎。核心引擎开发社区没有计划支持任何第三方、闭源或专有 SDK，因为集成这些 SDK 会违背 Godot 的精神。
正因为 Godot 是开源和模块化的，所以没有什么能阻止你或其他任何感兴趣的人将这些库添加为模块，并以开源或闭源的方式在你的游戏中使用他们。
要了解如何继续提供对你选择的 SDK 的支持，请查看下面的插件问题。
如果你知道 Godot 尚不支持但提供自由和开源集成的第三方SDK，请考虑自己开始集成工作。Godot 不属于个人；它属于社区，它与像你一样雄心勃勃的社区贡献者一起成长。
如何扩展 Godot？
要扩展 Godot，比如创建 Godot 编辑器插件或添加对其他语言的支持，请参阅编辑器插件和工具脚本。
另外，请参阅有关 GDExtension 的官方博客文章，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 等平台上开箱即用。
While Vulkan and OpenGL remain our primary focus for their open standard and cross-platform benefits, Godot 4.3 introduced experimental support for Direct3D 12. This addition aims to enhance performance and compatibility on platforms where Direct3D 12 is prevalent, such as Windows and Xbox. However, Vulkan and OpenGL will continue as the default rendering drivers on all platforms, including Windows.
为什么 Godot 旨在保持其核心功能集较小？
Godot 有意不包含可以通过附加组件实现的功能，除非它们非常常用。不经常使用的一个例子是高级人工智能功能。
这有几个原因：
代码维护和 bug 表面。每次我们在 Godot 仓库中接受新的代码时，现有的贡献者往往会承担起维护它的责任。一些贡献者在合并他们的代码后并不总是坚持下去，这会使我们难以维护有问题的代码。这可能会导致维护不善的功能会带有从未修复的错误。最重要的是，需要测试和检查回归的“API 表面”随着时间的推移不断增加。
易于贡献。通过保持代码库小而整洁，可以保持快速、轻松地从源代码编译。这使得新贡献者更容易入门 Godot，无需他们购买高端硬件。
为编辑器保持较小的二进制大小。并非每个人都拥有快速的 Internet 连接。确保每个人都可以在 5 分钟内下载、解压缩并运行 Godot 编辑器，这使得所有国家/地区的开发人员都可以更轻松地访问 Godot。
保持导出模板的二进制大小较小。这直接影响到 Godot 导出的项目的大小。在移动和 Web 平台上，保持文件大小较小对于确保在性能不足的设备上快速安装和加载非常重要。同样，许多国家/地区无法轻松获得高速互联网。此外，这些国家/地区通常会实施严格的数据使用上限。
基于上述所有原因，我们必须谨慎选择哪些功能可以作为 Godot 的核心功能。这就是为什么我们计划在未来版本的 Godot 中，将一些核心功能移至官方支持的附加组件中。就二进制大小而言，这也具有让你只需为项目中实际使用的功能付费的优势。（与此同时，你可以编译自定义导出模板并禁用未使用的功能来优化项目的分发大小。）
应如何创建资产来处理多种分辨率和纵横比？
这个问题很常见，可能要归功于苹果公司。苹果一开始将它们的设备分辨率加倍，让人觉得不同分辨率使用相同的资产是个好主意，所以很多人就这么做下去了。起初只有苹果设备这么做，但 Android 和后来的苹果设备又有了不同的分辨率和宽高比，它们的大小和 DPI 变得多种多样。
最常见和最恰当的处理方法是，为游戏使用单一基本分辨率，并仅处理不同的屏幕宽高比。主要是 2D 游戏需要这么做，在 3D 游戏中它只是相机的垂直或水平 FOV 的问题。
为游戏选择单一的基础分辨率。即使有分辨率高达 1440p 的设备和低至 400p 的设备，设备中的常规硬件扩展也可以在很少或没有性能成本的情况下解决这个问题。分辨率最常见的选择是接近 1080p (1920x1080) 或 720p (1280x720)。请记住，分辨率越高，资产越大，所需的内存就越多，加载所需的时间也就越长。
使用 Godot 中的拉伸选项；画布项目在保持宽高比时拉伸效果最好。请参阅教程《多分辨率》来学习如何实现。
确定最小分辨率，然后决定是否希望游戏垂直或水平拉伸以获得不同的宽高比，或者如果有一个宽高比并且你希望显示黑条。这也在《多分辨率》中有所解释。
对于用户界面，请使用锚定来确定控件应停留和移动的位置。如果 UI 更复杂，请考虑学习 Container（容器）。
就是这样！你的游戏应该能够以多种分辨率运行了。
Godot 的下一个版本什么时候发布？
当它准备好的时候！详情见《下一个版本什么时候发布？》。
新项目应该使用哪个版本的 Godot？
我们建议在新项目中使用 Godot 4.x，但是取决于你所需的功能，也许使用 3.x 更好。具体可参阅《新项目应该使用哪个版本？》。
我是否应该升级我的项目以使用新版本的 Godot？
某些新版本在某些方面更安全。一般来说，是否应该升级取决于你的项目的情况。详见《我是否应该升级我的项目以使用新的引擎版本？》。
Should I use the Forward+, Mobile, or Compatibility renderer?
You can find a detailed comparison of the renderers in Renderers.
我想要贡献！ 该如何开始？
太棒了！作为一个开源项目，Godot 的发展得益于像你这样的开发者的创新和雄心。
开始为 Godot 做出贡献的最佳方式是使用它并报告你可能遇到的任何问题。一份带有清晰重现步骤的好 bug 报告可以帮助其他贡献者快速有效地修复 bug。你也可以在在线文档中报告你发现的问题。
如果你准备提交你的第一个 PR，请从上面的链接之一中选择你感兴趣的任何一个问题，并尝试解决它。你将需要学习如何从源代码编译引擎，或如何构建文档。你还需要熟悉 Git，这是 Godot 开发人员使用的版本控制系统。
我们在《贡献者文档》中解释了如何使用引擎源代码、如何编辑文档以及其他形式的贡献方式。
是否能用 Godot 创建非游戏应用？
是的！Godot 具有广泛的内置 UI 系统，其较小的软件包可以使它成为 Electron 或 Qt 等框架的合适替代品。
当创建一个非游戏的应用程序时，确保在项目设置中启用低处理器模式以减少 CPU 和 GPU 占用。
请查看 Material Maker 和 Pixelorama，以了解用 Godot 制作的开源应用程序的例子。
是否能将 Godot 作为库使用？
Godot 旨在与其编辑器一起使用。我们建议你尝试一下编辑器，因为从长远来看，它很可能会节省你的时间。目前尚无计划把 Godot 作为库使用，因为这会使引擎的其余部分更加混乱，难以为普通用户使用。
如果你想使用一个渲染库，那就使用一个已经建立的渲染引擎来代替。需要注意的是，与 Godot 相比，渲染引擎通常拥有更小的社区，这将会使你解决问题的难度加大。
Godot 使用的用户界面工具包是什么？
Godot 不使用 GTK、Qt、wxWidgets 等标准的 GUI 工具包，而是使用自己的用户界面工具包，使用 OpenGL ES 或 Vulkan 进行渲染。这个工具包以 Control 节点的形式暴露出来，用于渲染编辑器（用 C++ 编写）。这些 Control 节点也可以在 Godot 支持的任何脚本语言的项目中使用。
这个定制的工具包使它能获益于硬件加速，并在全平台上拥有一致的外观。最重要的是，它不必处理 GTK 或 Qt 所带来的 LGPL 许可注意事项。最后，这意味着 Godot 在“自产自用”，因为编辑器本身就是 Godot UI 系统中最复杂的用例之一。
这个自定义 UI 工具包不能作为一个库使用，但你仍然可以通过使用 Godot 编辑器来创建非游戏应用程序。
为什么 Godot 使用 SCons 构建系统？
Godot 使用 SCons 构建系统。近期没有改用其他构建系统的计划。我们选择 SCons 而不是其他构建系统的原因有很多，例如：
Godot 可以针对多种不同的平台进行编译：所有 PC 平台、所有移动平台、各种游戏主机、WebAssembly。
开发者们经常需要同时将代码编译到多个平台上，或者同一个平台的不同架构上，但他们负担不起每次都要重新配置和重构项目。SCons 可以毫不费力地完成此任务，而不会破坏构建。
无论对项目做出多少修改、配置、增加、删除之类的事情，SCons 都不会 把构建工作搞砸。
Godot 的构建过程并不简单。一些文件由代码生成（绑定器），另一些文件需要解析（着色器），而还有一些文件则需要提供定制（ 模块）。这需要复杂的逻辑，而该逻辑更容易用实际的编程语言（如Python）编写，而不是使用基于宏且仅限于构建过程的语言。
Godot 的构建过程大量使用了交叉编译工具。每个平台都有特定的检测过程，需要为各个平台编写特殊代码，将这些作为特殊情况处理。
如果你想要自己构建 Godot，放宽心态， 并至少稍微熟悉一下 SCons。
为什么 Godot 不使用 STL（标准模板库）？
像许多其他库一样（Qt 就是一个例子），Godot 没有使用 STL（除了线程原语等少数例外）。我们相信 STL 是一个强大的通用库，但我们对用于Godot上的库有特殊的要求。
STL 模板会创建大量符号，产生巨型的调试二进制文件。我们使用一些名称很短的模板来代替。
我们的大多数容器都是针对特定需求设计的，例如 Vector 使用写时复制，我们用它来传递数据，而 RID 系统则需要 O(1) 访问时间来提高性能。同样，我们的哈希表实现旨在与内部引擎类型无缝集成。
我们的容器内置了内存跟踪，有助于更好地跟踪内存的使用情况。
对于大型数组，我们使用内存池，它可以被映射到预先分配的缓冲区或虚拟内存。
我们使用自定义字符串类型，因为 STL 提供的版本过于基础，并且缺乏适当的国际化支持。
为什么 Godot 不使用异常？
我们相信，无论如何，游戏都不应该崩溃。如果发生意外情况，Godot 将打印一条错误（甚至可以追溯到脚本），但随后它将尝试尽可能优雅地恢复并继续运行。
此外，异常会显著增加可执行文件的二进制大小，并且导致编译时间增加。
Godot 使用 ECS（实体组件系统）吗？
Godot 不使用 ECS，而是依赖于继承。虽然没有普遍更好的方法，但我们发现使用基于继承的方法可以获得更好的可用性，同时对于大多数用例来说速度仍然足够快。
That said, nothing prevents you from making use of composition in your project by creating child Nodes with individual scripts. These nodes can then be added and removed at runtime to dynamically add and remove behaviors.
可以在这篇文章中找到更多有关 Godot 设计抉择的信息。
为什么 Godot 不强制用户实现 DOD（面向数据设计）？
尽管 Godot 的内部实现中尽可能的使用了缓存一致性，但我们认为不应该强迫用户使用 DOD。
DOD 主要是一种缓存一致性优化，只有在每帧需要处理数以万计的对象，且几乎不做任何修改时，才能够提供显著的性能提升。假如你每帧要移动的精灵或敌人只有几百个，那么 DOD 并不会带来有意义的性能提升。在这种情况下，你应该考虑别的优化手段。
绝大多数游戏都不需要这个，并且 Godot 提供了方便的辅助工具来完成大多数情况下的工作。
如果游戏的确需要处理如此巨量的对象，那么建议使用 C++ 和 GDExtensions 处理那些需要高性能的部分，使用 GDScript（或 C#）来负责游戏的其它部分。
如何支持 Godot 开发或做出贡献？
见贡献方式。
谁在为 Godot 工作？如何联系？
见 Godot 官网上的相应页面。