- 常见问题
- 可以用Godot做什么?需要花多少钱?有哪些许可条款?
- Godot支持哪些平台?
- Godot支持哪些编程语言?
- GDScript是什么?为什么要用它?
- 创建GDScript背后的动机是什么?
- Godot支持哪些3D模型格式?
- 能否在Godot中加入闭源SDK,比如FMOD、GameWorks等?
- 为什么Godot使用Vulkan/OpenGL而不是Direct3D?
- 如果要适配多种分辨率和纵横比,素材应做哪些处理?
- 如何扩展Godot?
- Godot的下一个版本什么时候发布?
- 想要贡献! 如何开始?
- 有关于Godot的好主意。如何分享它?
- 是否能将Godot作为库使用?
- 为什么Godot不使用STL(标准模板库)?
- 为什么Godot不使用异常?
- 为什么Godot不执行运行时类型识别(RTTI)?
- 为什么Godot不强迫用户实践DoD(面向数据设计)?
- 怎样支持或参与Godot的发展呢?
- 谁在为Godot工作?如何联系?
常见问题
可以用Godot做什么?需要花多少钱?有哪些许可条款?
Godot是 Free和开源的软件 可在 OSI认可的 MIT许可证下使用。这里的 free 就像“言论自由(free speech)”和“免费啤酒(free beer)”里的 free 一样,它是自由且免费的。
简而言之:
- 您可以出于任何目的,个人、非营利、商业或其他目的,下载和使用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)
导出游戏:
- 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创建自定义脚本语言的主要原因是:
- 大多数脚本语言(Lua、Python、Squirrel、JS、AS等)的虚拟机(VM)对线程的没有很好的支持,但Godot需要使用线程。
- 大多数脚本语言(Lua、Python、JS)的虚拟机没有很好地支持类扩展,适配Godot工作方式的效率极低。
- 许多现有语言具有绑定到C ++的糟糕接口,会导致产生大量代码、错误、瓶颈和普遍的效率低下(Lua、Python、Squirrel、JS等)。我们希望专注于一个更好的引擎,而不是大量的整合。
- 没有原生向量类型(vector3、matrix4等),导致使用自定义类型实现时性能大大降低(Lua、Python、Squirrel、JS、AS等)。
- 垃圾收集器导致停顿或不必要的大内存使用(Lua、Python、JS、AS等)。
- 难以与Godot代码编辑器集成从而支持代码补全、动态编辑等。(所有这些语言)。但这方面GDScript支持得很好。
GDScript为减少上述问题以及更多问题而设计。
Godot支持哪些3D模型格式?
即便如此,Godot对Collada的支持非常好,如果您在用Maya或3DS Max,请使用 OpenCollada 导出,以便得到最大程度地兼容。如果您使用的是Blender,可以用我们的 Better Collada Exporter。
Godot从3.0版本开始支持gITF。
FBX可以通过开源的插件来支持。因此,我们建议您在适合您的工作流程的情况下使用上面列出的其他格式。
能否在Godot中加入闭源SDK,比如FMOD、GameWorks等?
Godot的目的是创建一个遵循免费开源MIT许可的引擎,而且是模块化和可扩展的。核心引擎开发社区没有计划支持任何第三方、闭源或专有SDK,因为这些SDK的集成会违背Godot的精神。
也就是说,正因为Godot是开源和模块化的,所以没有什么能阻止你或其他任何感兴趣的人将这些库添加为模块并使用它们——无论是开源还是闭源——发布游戏。
如欲了解如何支持您使用的SDK,请查看下面的插件问题。
如果您知道Godot不支持但是想提供免费和开源集成的第三方SDK,请考虑自己开始集成工作。Godot不属于一个人;它属于社区,它与像您一样雄心勃勃的社区贡献者一起成长。
为什么Godot使用Vulkan/OpenGL而不是Direct3D?
Godot的首要目标是实现跨平台兼容性和开放标准。 OpenGL和Vulkan是在所有平台上都开放且几乎可用的技术。 由于这一设计决定,在Windows上使用Godot开发的项目在Linux,macOS等平台上同样可用。
由于只有少数人开发Godot的渲染器,我们更倾向于只有少数几个渲染后端需要维护。在此之上,所有平台使用单一的API,这样可以有更好的一致性和很少的平台特定的问题。
未来一段时间后, 我们可能会为Godot开发一个Direct3D 12渲染器(主要面向Xbox),但是Vulkan和OpenGL将仍然是包括Windows在内的所有平台的默认渲染后端。
如果要适配多种分辨率和纵横比,素材应做哪些处理?
这个问题很常见,可能要归功于苹果公司。苹果一开始将它们的设备分辨率加倍,让人觉得不同分辨率使用相同的素材是个好主意,所以很多人就这么做下去了。起初只有苹果设备这么做,但安卓和后来的苹果设备又有了不同的分辨率和宽高比,它们的大小和DPI变得多种多样。
最常见和最恰当的处理方法是,为游戏使用单一基本分辨率,并仅处理不同的屏幕宽高比。 这主要是2D游戏所需要做的,因为在3D游戏中它只是相机 XFov或YFov的问题。
- 为游戏选择一个基本分辨率。即使有高达2K的设备和低至400p的设备,设备中的常规硬件缩放也会在很少或没有性能成本的情况下解决这个问题。 最常见的选择是接近1080p(1920x1080)或720p(1280x720)。 请记住,分辨率越高,素材越大,占用的内存就越多,加载所需的时间也就越长。
- 使用Godot中的拉伸(Stretch)选项;2D保持宽高比时拉伸效果最好。参阅教程 多分辨率 来学习如何实现它。
- 确定最小分辨率,然后决定是否希望游戏垂直或水平拉伸以获得不同的宽高比,或者如果有一个宽高比并且您希望显示黑条。 这也在 多分辨率 有所解释。
- 对于用户界面,请使用 锚定 来确定控件应停留和移动的位置。 如果UI更复杂,请考虑学习容器。
就是这样!您的游戏应该能够以多种分辨率运行。
如果希望让您的游戏也适用于具有小屏幕(宽度小于300像素)的古老设备,可以在导出选项中缩小图像,并且在App Store或Google Play中将它设为用于特定的屏幕大小。
如何扩展Godot?
要扩展Godot,比如创建Godot编辑器插件或添加对其他语言的支持,请参阅 编辑器插件 和工具脚本。
另外,请参阅有关这些主题的官方博客:
您还可以查看GDScript的实现、Godot模块以及Godot的 非官方Python支持 。这个将是您了解如何将第三方库整合到Godot中的第一步。
Godot的下一个版本什么时候发布?
当它准备好的时候!详情见 在编辑器中运行代码。
想要贡献! 如何开始?
太棒了!作为一个开源项目,Godot的发展得益于像您这样的开发者的创新和雄心。
开始的第一个地方是在 问题列表。找到一个与您产生共鸣的问题,然后继续阅读 如何贡献 指南,学习如何使用更改派生、修改和提交Pull Request (PR)。
有关于Godot的好主意。如何分享它?
想要把一些想法带给Godot会很诱人,比如导致大量核心变化的想法,某种模仿其他游戏引擎所做的事情,或者您想要在编辑器中构建另一种工作流程。这些都是伟大的,我们感谢有这些想要积极贡献的人,但Godot的焦点是而且始终将是在 路线图 中概述的核心功能。排查bug和解决问题,以及与Godot社区成员之间的讨论。
Godot社区中的大多数开发人员都会更有兴趣了解以下内容:
- 您使用该软件的经验和您遇到的问题(我们关心的不仅仅是关于如何改进它的想法)。
- 您希望实现的功能,因为您需要它们用于您的项目。
- 学习软件时难以理解的概念。
- 您的工作流程中希望优化的部分。
- 教程不全的部分或者文档不清晰的部分。
因此,请不要觉得您对Godot的想法是不受欢迎的。相反,首先尝试将它们作为问题重新表述出来,这样开发人员和社区会有一个功能依据,可以为您的想法奠定基础。
与社区分享您的想法和问题的一个好方法是用案例来说明。解释您想做什么,您期望发生什么行为,然后实际发生了什么行为。以这种方式体现问题和想法,将有助于整个社区始终专注于作为一个整体改善开发者的体验。
最好可以附上截图、具体数值、测试用例或示例项目(如果有的话)。
是否能将Godot作为库使用?
Godot旨在与其编辑器一起使用。我们建议您尝试一下编辑器,因为从长远来看,它很可能会节省您的时间。目前尚无计划把Godot作为库(library)使用,因为这会使引擎的其余部分更加混乱,难以为普通用户使用。
如果你想使用一个渲染库,那就使用一个已经建立的渲染引擎来代替。需要注意的是,与Godot相比,渲染引擎通常拥有更小的社区,这将会使你解决问题的难度加大。
为什么Godot不使用STL(标准模板库)?
像许多其他库一样(Qt就是一个例子),Godot没有使用STL。我们相信STL是一个伟大的通用库,但我们对Godot有特殊的要求。
- STL模板会创建大量符号,这会产生大量的调试二进制文件。 我们使用名称很短的少量模板来代替。
- 我们的大多数容器都满足特殊需求,例如 Vector,它使用写时复制,我们用它来传递数据,或RID系统,这需要O(1)访问时间来提高性能。同样,我们的哈希映射实现旨在与内部引擎类型无缝集成。
- 我们的容器内置了内存跟踪,这有助于更好地跟踪内存使用情况。
- 对于大型数组,我们使用内存池,可以映射到预先分配的缓冲区或虚拟内存。
- 我们使用自定义字符串类型,由于STL提供的版本过于基础,并且缺乏适当的国际化支持。
为什么Godot不使用异常?
我们相信无论如何游戏都不应该崩溃。如果发生意外情况,Godot将打印一个错误(甚至可以追溯到脚本),但之后它会尽可能优雅地恢复,并继续前进。
此外,异常会显著增加可执行文件的二进制大小。
为什么Godot不执行运行时类型识别(RTTI)?
Godot提供了自己的类型转换系统,可以可选地在内部使用运行时类型识别(RTTI)。在Godot中禁用运行时类型识别,意味着可以以较小的性能代价实现相当小的二进制大小。
为什么Godot不强迫用户实践DoD(面向数据设计)?
虽然Godot内部针对许多繁重的性能任务,尝试尽可能地使用缓存一致性,但我们相信大多数用户并不真正需要被迫使用DoD实践。
面向数据设计主要是缓存一致性优化,它只能在处理成千上万个对象时获得显著的性能提升(每帧都经过少量修改)。比如,如果你每帧移动几百个精灵或敌人,面向数据设计不会帮您的,您应该考虑一种不同的优化方法。
绝大多数游戏都不需要这个,并且Godot提供了方便的辅助工具来完成大多数情况下的工作。
如果一个游戏确实需要处理如此庞大的对象,我们建议在游戏的高性能部分使用C++和GDNative,而其余部分使用GDScript(或C#)。
怎样支持或参与Godot的发展呢?
参阅 贡献方式。
谁在为Godot工作?如何联系?
请参照 Godot官网 上的相应页面。