Godot4_文档学习2_关于Godot_常见问题

文章目录

前言
Frequently asked question 常见问题

前言

本文是 关于Godot（About） 章节的第二部分。
本部分由开发者/准备入坑的新人常常问到的问题组成，以问答的方式呈现，挑你感兴趣的看一下，或大致浏览一下即可。

Frequently asked question 常见问题

用Godot可以做什么？要花多少钱？许可条款是什么？

Godot是在OSI-approve的MIT许可下的免费开源软件。这意味着它是免费的。

简而言之：

你可以免费下载Godot并将它用于任何目的：个人，非营利，商业或其它。
你也可以随意修改，发布和混合Godot，以满足你的需求，无论是非商业还是商业原因。

本文档所有内容都在知识共享许可协议3.0（CC BY 3.0）下发布，署名为“Juan Linietsky, Ariel Manzur和Godot引擎社区”。

Logo和图标一般也在相同的知识共享许可协议下。注意，某些Godot源码包含的第三方库可能会有不同的许可。

详细信息，查看Godot存储库中的COPYRIGHT.txt，LICENSE.txt和LOGO_LICENSE.txt文件。

Godot支持哪些平台？

编辑器支持有：

Windows
macOS
Linux,*BSD
Android(experimental)
Web(experimental)

导出的游戏支持：

Windows（以及UWP）
macOS
Linux,*BSD
Android
iOS
Web

32/64位都支持，默认是64位的。官方macOS构建支持Apple Silicon和x86_64。

一些用户也报告说，他们成功地在基于ARM的Linux上构建和使用Godot，比如树莓派（Raspberry Pi）。

由于主机制造商强加的许可条款，Godot团队无法提供开源主机程序导出。无论你使用什么引擎，在主机上发行游戏总是需要大量的工作。你可以在Godot中阅读更多关于主机支持的信息。

Godot支持哪种编程语言

Godot官方支持的语言是GDScript，C#和C++。在脚本部分可以看到每种语言的子类别。

若你刚接触Godot或游戏开发，那么推荐学习和使用GDScript语言，因为它是Godot的原生语言。长远来看，脚本语言的性能并不如低级语言，但对于原型制作/开发最小可行产品（mvp，Minimum Viable Products）和快速进入市场（TTM，Time-To-Markets）来说，GDScript会为你提供一种快速，友好且有效的游戏开发方式。

注意，C#的支持相对较新，因此，你可能会在使用过程中遇到一些问题。在Android，iOS和Web平台目前不支持C#。虽然友好且勤奋的开发社区随时准备着解决出现的各种新问题，但由于这是一个开源项目，我们建议你在遇到问题时首先自己做一些应对调查。在公开问题的讨论中进行搜索通常是一种故障排除的好方法。

对于新语言，可以通过第三方用GDExtensions进行支持。（参见下面关于插件的问题）例如，目前正在进行Godot与Python和Nim的非官方绑定。

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

GDScript是Godot的集成脚本语言。它从头开始构建，以最少的代码最大化Godot的潜力，使新手和专家开发者都能尽可能地利用Godot的优势。如果你以前用过Python这样的语言写东西，你会觉得很熟悉。有关GDScript提供的功能示例和完整概述，查看GDScript脚本指南。

使用GDScript的原因有许多，尤其是当你正在制作原型，处于项目的alpha/beta阶段时，或者不是在制作下一代AAA游戏时。最主要的原因是总体上降低了复杂性。

为Godot创建一个紧密集成的定制脚本语言的初衷有两方面：

首先，它减少了启动和运行Godot所需的时间，为开发人员提供了一种快速的方式，使他们能专注到开发生产中；
其次，它减少了维护的总体负担，降低了问题的维度，并允许引擎开发者专注于消除漏洞和改进与引擎核心相关的功能，而不是花费大量时间来尝试在大量语言中获得一小部分增量功能。

由于Godot是一个开源项目，从一开始就必须优先考虑更集成和无缝的体验，而不是通过支持较熟悉的编程语言来吸引额外的用户，特别是当支持那些更熟悉的语言会导致糟糕的体验时。我们能理解你希望在Godot中使用其它语言（参考上面支持的语言）。不过，如果你还没尝试过GDScript，那就先用三天试试。就像Godot一样，一旦你看到了它的强大和它的快速开发，我们认为你就会喜欢上GDScript。

更多关于使用GDScript或动态类型语言的信息可在 GDScript：动态语言介绍 教程中找到。

设计GDScript的动机是什么？

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

为Godot设计一款自定义脚本语言的主要原因是：

大多数脚本虚拟机（VM）不支持线程，Godot使用线程（Lua，Python，Squirrel，JavaScript，ActionScript等）。
大多数脚本虚拟机中，类扩展支持很差，并且与Godot适配的运行效率非常低（Lua，Python，JavaScript）。
许多现有语言都有绑定到C++的可怕接口，导致了大量代码、bug、瓶颈和效率低下（Lua、Python、Squirrel、JavaScript等）。我们想要专注于一个伟大的引擎，而不是做大量整合。
没有原生的向量类型（vector3、matrix4等），导致使用自定义类型（Lua、Python、Squirrel、JavaScript、ActionScript等）时性能大大降低。
垃圾收集器（GC）导致停滞和不必要的大内存使用（Lua、Python、JavaScript、ActionScript等）。
难以与代码编辑器集成以提供代码补全、实时编辑等（以上所有脚本语言）。

GDScript旨在减少上述问题。

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

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

Godot是否支持[插入FMOD、GameWorks等封闭SDK]？

Godot的目的是创建一个免费和开源的MIT许可引擎，它是模块化且可扩展的。核心引擎开发社区没有计划支持任何第三方、闭源（closed-source）/专有的SDK，因为与这些SDK集成将违背Godot的精神。

也就是说，因为Godot是开源和模块化的，所以没有什么可以阻止你或其他有兴趣的人将这些库添加为模块，并以开源或闭源的方式发布你的游戏。

要了解如何提供你所选的SDK的支持，请看下面插件问题。

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

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

由于你不需要在系统上实际安装Godot来运行它，这意味着桌面集成不会自动执行。有两种方法可以克服这个问题。你可以从Steam（所有平台）、Scoop（Windows）、Homebrew（macOS）或Flathub（Linux）上安装Godot。这将自动执行桌面集成所需的步骤。

或者，你可以手动执行安装程序为你执行的步骤：

Windows

将Godot可执行文件移动到一个固定位置（即在你的下载文件夹之外），这样你就不会不小心移动它而破坏快捷方式。
右击Godot可执行程序并选择 创建快捷方式。
将创建的快捷方式移动到 %APPDATA%\Microsoft\Windows\Start Menu\Programs 。这是会出现在开始菜单中的快捷方式的用户位置。你也可以通过右键单击可执行文件并选择 固定到任务栏 来将Godot固定在任务栏中。

macOS
将提取的Godot的应用程序拖到 /Applications/Godot.app ，然后将其拖到Dock中。Spotlight会找到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是半便捷的（semi-portable）。它的可执行文件可以从任何位置（包括不可写的位置）运行，并且不需要管理员权限。

但是，配置文件将被写入用户配置或数据目录中。这通常是一种好方式，但是这意味着如果你复制包含Godot可执行文件的文件夹，那么配置文件会无法跨机器携带。更多信息，参阅 Godot项目中的文件路径 。

若需要完全的便捷式操作（例如在u盘上使用），请按照 自包含，Self-contained 模式的步骤操作。

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

Godot的首要目标是实现跨平台兼容性和开放标准。OpenGL和Vulkan是在（几乎）所有平台都开放且可用的技术。因为这一设计决策，在Windows上使用Godot开发的项目可以在Linux、macOS等平台上立即运行。

由于Godot只有几个人在处理/开发它的渲染器，我们希望在渲染后端的维护上花费更少的资源。最重要的是，在所有平台上使用单一API可以提高一致性，减少特定平台的问题。

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

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

Godot故意不包含那些通过附加组件能实现的特性，除非它们经常被用到。如，高级的人工智能功能。

这有几个原因：

代码维护和bug修复。每次我们接受Godot仓库中的新代码，现有的贡献者通常会承担起维护它的责任。一些贡献者在他们的代码合并后并不总是留下来，这使得我们很难维护有问题的代码。这可能会导致功能维护不好和难以修复的bug。最重要的是，需要测试和检查的API随着时间的推移会不断增加。
易于贡献 。通过保持代码库的小而整洁，能使编译源码更快更容易。这使得新的贡献者更容易开始使用Godot，而不需要购买高端硬件。
为编辑器保持较小的二进制文件 。不是所有人都有快速的互联网连接。确保每个人都能下载Godot编辑器，提取它并在不到五分钟的时间内运行它，这使得所有国家的开发人员都能很容易地访问Godot。
为导出模板保持较小的二进制文件 。这直接影响到Godot导出项目的大小。在移动端和网页端，保持较小的文件大小对于确保在低性能的设备上快速安装和加载非常重要。同样，在许多国家，高速互联网并不容易获得。初次之外，这些国家通常实行严格的数据使用上限。

基于上述原因，我们必须对Godot的核心功能进行选择。这就是为什么我们要在将来的版本中将一些核心功能转移到官方支持的附加组件（add-ons）中。就二进制文件大小而言，这样做还有一个好处，那就是你只需为项目中实际使用的内容付费（扩展功能以付费包的形式出现？）。（与此同时，你可以编译自定义的导出模板，禁用未使用的功能，以优化项目的发布大小）

如何创建能处理多种分辨率和宽高比的资源？

这个问题经常出现，这可能是由于苹果公司最初将其设备分辨率提高一倍时造成的误解。人们通常认为在不同的解决方案中拥有相同的资源是个好主意，所以许多人一直朝着这条道路前进。这种方法只适用于苹果设备，但后来出现了几种具有不同分辨率和宽高比的Android和苹果设备，它们的尺寸和DPI范围非常广。

实现这一目标最常见且最合适的方法是，游戏使用单一的基本分辨率，只处理不同的屏幕宽高比。在2D中非常需要这么做，因为在3D中只是相机XFov或YFov的问题。

为你的游戏选择一个单一的基本分辨率。即使有些设备的分辨率高达2K，有些设备的分辨率只能到400p，在设备常规硬件的情况下缩放也可以花费很少或没有性能成本来解决这个问题。最常见的选择是接近1080p（1920x1080）或720p（1280x720）。记住，分辨率越高，你的资源就越大，它们占用的内存就越多，加载所需的时间也就越长。
使用Godot中的拉伸选项；在保持纵横比的同时进行2D拉伸效果最佳。查看 多分辨率 教程，以了解如何实现这点。
确定最低分辨率，然后决定是否希望游戏以不同的宽高比垂直或水平拉伸，或者是否保持某种宽高比而用黑条填充多余部分。这点在 多分辨率 中也进行了解释。
对于用户界面，使用锚定来确定控件应停留和移动的位置。如果UI很复杂，可以考虑学习容器。

就按上面做，你的游戏应该就能在多分辨率下运行。

若你希望让你的游戏也能在小屏幕（宽度小于300像素）的远古设备上运行，你可以使用导出选项来缩小图像，并在 App Store 或 Google Play 中将其设为用于某些特定的屏幕尺寸。

如何扩展Godot？

要扩展Godot，例如创建Godot编辑器插件或添加对其它语言的支持，查阅 编辑器插件EditorPlugins 和 工具脚本tool script 部分。

另外，看有关GDExtension的官方博客，这也是一种为Godot开发本机扩展的方法：

介绍GDNative的继承器（successor），GDExtension

这边的successor大概是指一种扩展模块，开发者可以通过该模块去扩展Godot。

你还可以查看GDScript的实现、Godot模块以及对Godot的非官方Python支持。这是了解另一个第三方库如何与Godot集成的一个很好的起点。

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

当准备好时，参阅 下一个版本何时发布？ 章节可看到。

我在新项目中应该使用哪个Godot版本？

我们建议对新项目使用Godot4.x，但具体还是取决于你的需求，可能3.x会更好。

我应该升级我的项目以使用新的Godot版本吗？

升级到有些新版本比其他版本更安全。一般来说，是否应该升级取决于项目实际情况。

我想要做贡献，我应该如何开始？

Awesome！作为一个开源项目，Godot的蓬勃发展得益于像你这样的开发人员的创新和雄心。

开始为Godot做出贡献的最佳方法是使用它并报告您可能遇到的各种任何问题（使用体验？）。一份好的错误报告和清晰复现步骤可也帮助贡献者快速有效地修复bug。（相当于测试并上报bug）

如果你准备好提交一个PR(Pull Request)，请从上面链接中选择与你产生共鸣的任何问题，并尝试解决它。你将需要学习如何从源代码编译引擎，或者如何构建文档。你还需要熟悉Git，Godot开发人员使用的版本控制系统。

我们在为贡献者提供的文档上说明了如何使用引擎源代码、如何编辑文档以及其他贡献方式。

我对Godot有好的想法？该如何分享它？

我们一直在寻找有关如何改进引擎的建议。用户反馈是我们决策过程背后的主要驱动力，在考虑引擎增强功能时，你在项目工作中可能面临的限制对于我们来说是很好的数据支撑点。

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

若你对引擎有定义明确（well-defined）的想法，请随时开一个提案issue。在描述你的问题和建议的解决方案时，尽量具体且具象（不要讲的很抽象）——只有可行的建议才会被考虑。如果你想自己实现它，我们将不胜感激！（当然这不是必需的）

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

请在创建提案前阅读readme文档，以了解有关该流程的更多信息。

是否可以使用Godot创建非游戏应用程序？

是的！Godot具有广泛的内置UI系统，其较小的发型版可以成为Electron或Qt等框架的适当替代。

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

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

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

是否能将Godot用作一个库？

Godot旨在与其编辑器一起使用。我们建议你尝试一下，因为从长远来看，很可能会节省你的时间。目前还没有计划让Godot用作库，因为这会使引擎的其余部分更加复杂，并且对临时用户来讲会难以使用。

如果你想使用渲染库，请考虑使用建立好的渲染引擎。记住，与Godot相比，渲染引擎的社区通常更小。这将使你更难找到问题的答案。

Godot使用什么UI工具包？

Godot不使用GTK、Qt或wxWidgets等标准UI工具包。相反，Godot使用自己的UI工具包，使用OpenGL Es或Vulkan进行渲染。该工具包以控制节点（Control nodes）的形式公开，用于渲染编辑器（用C++编写）。这些控制节点还可以在Godot支持的任何脚本语言的项目中使用。

该定制工具包可以从硬件加速中受益，并在所有平台具有一致的外观。最重要的是，它不必处理GTK或Qt附带的LGPL许可警告。最后，这意味着Godot正在"eating its own dog food"，因为编辑器本身是Godot UI系统最复杂的用户之一。

eating its own dog food
这是一句英语俚语,常用于描述公司(尤指软件公司)使用自己生产的产品这一情况。
这边指的是Godot的UI工具包，Godot本身就是其用户。自己用自己开发UI工具包。

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

为什么Godot使用SCons来构建系统？

Godot使用SCons构建系统，
且没有计划在未来切换到不同的构建系统。选择SCons而不是其他替代方案的原因有许多。例如：

Godot可以针对十几种不同的平台进行编译：所有PC平台、所有移动平台、许多主机平台和WebAssembly。
开发人员经常需要同时针对多个平台甚至同一平台的不同目标进行编译。他们无法承担每次重新配置和重建项目的带来的改动成本。SCons可以毫不费力地做到这一点，而且不会破坏构建。
无论有多少更改、配置、添加、删除，SCons都不会破坏构建。
Godot的构建过程并不简单。代码（binders）会生成多个文件，其他文件被解析（着色器，shaders），而其他文件需要提供自定义（模块，modules）。这需要复杂的逻辑，用真正的编程语言（如Python）更容易编写，而不是使用仅用于构建的基于宏（macro-based）的语言。
Godot构建过程大量使用交叉编译工具。每个平台都有特定的检测流程，所有这些都必须根据具体情况进行处理。

如果你打算自己构建Godot，请尝试保持开放的心态且至少熟悉一下SCons。

为什么Godot不使用STL（Standard Template Library）？

和许多其他库（如Qt）一样，Godot不适用STL。我们相信STL是一个很棒的通用库，但我们对Godot有特殊要求。

STL模板创建大量符号，这会导致巨大的调试二进制文件。我们使用一些名称非常短的模板。
大多数Godot容器都得满足特殊需求，如Vector，它在写入时使用拷贝，并且我们用来传递数据，又或者如RID系统，它需要O(1)的访问性能。同样，我们的hashmap实现旨在与内部引擎类型无缝集成。
我们容器内置了内存跟踪，这有助于更好地跟踪内存使用情况。
对于大型数组，我们使用池化内存（pooled memory），它可以映射到预分配的缓冲区或虚拟内存。
我们使用自定义的String类型，因为STL提供的类型太基础并缺乏适当的国际化支持。

为什么Godot不使用异常？

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

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

为什么Godot不强制RTTI？

Godot提供了自己的类型转换（type-casting）系统，可以选择在内部使用RTTI（Runtime Type Identification）。在Godot中禁用RTTI意味着可以实现相当小的二进制文件，而且是在极小的性能成本下。

Godot使用ECS（Entity Component System）吗？

Godot不使用ECS，而是依赖于继承。尽管没有通用的更好的方法，但我们发现使用基于继承（inheritance-based）的方法可以带来更好的可用性，同时对大多数用例来讲也足够快。

也就是说，没有什么可以阻止你在项目中使用组合（通过创建带有独立脚本的子节点）。接着，在运行时可添加和删除这些节点以动态添加和删除行为。

为什么Godot不强制用户实现DOD（Data-Oriented Design）？

尽管Godot内部尝试尽可能多地使用缓存一致性，但我们认为用户不需要被迫使用DOD的方式。

DOD主要是一种缓存一致性优化，只有在处理成千上万个对象时才能提供显著的性能改进，这些对象每帧只有很少的改动。也就是说，如果你每帧移动数百个精灵或敌人，DOD不会对性能产生有意义的改进。在这种情况下，你应该考虑采用不同的方式进行优化。

绝大多数游戏不需要这个，Godot提供了方便的助手来完成大多数情况下的工作。

若游戏需要处理如此大量的对象，我们建议使用C++和GDExtensions来处理性能要求较高（performance-heavy）的任务，用GDScript（或C#）来处理其余部分。

如何支持Godot开发或做贡献？

参阅 贡献方式 章节。

谁在从事Godot开发？我该怎样联系？

查阅 Godot网站 的相应页面。