Godot Game Engine：高级GUI应用程序的未来与复杂系统解析

近来，我仍然在试用GodotGameEngine，而我所听到的一切给我留下了深刻的印象。

虽然它被设计用于制做游戏，但它具有用于制画图形用户界面的非常复杂的系统。我觉得这是中级GUI应用程序的未来。不服气吗？

看下边的图片。这来自Godot编辑器。看上去很精美吧？你得到了：

·节点的画布联接了可视化编程系统中使用的节点（除其他几个受支持的编程系统之外）。

·资源管理。

·一个复杂的树小部件，用于处理场景图。

·具有可以过滤的属性的检测器。

·具有句型高亮显示，中级代码完成，跳转到定义，实时警告等的代码编辑器。

·瓷砖地图编辑器，动漫编辑器以及许多其他音频编辑器，还有许多我还没有时间探求的东西。

>TheGodoteditorisasophisticatedGUIapplicationmadeinGodotitself.

您怎么看待她们制做了这么复杂的GUI？是Qt吗？Coco？

不，所有那些都是由GodotGameEngine本身完成的。她们真的在吃自己的狗食。为此，您在这儿听到的所有内容都可以使用Godot在自己的应用程序中完成。

其实，您可以通过其他工具找到复杂的GUI。诸如。一些竞争引擎使用Qt进行编辑。

小小的

然而这儿是抬腿：

所有带有引擎端编辑器的Godot都只有31.1MB下载。一键安装，编辑器立刻启动。

当我打开包装并安装时，它依然只有70MB。相对于您获得的功能而言，这绝对是个很小的安装。让我们对此进行一些介绍。仅下载Qt5，须要5GB的可用空间！

考虑一下QtCreatorIDE，它特别简单，没有须要运行的Qt，它须要200MB以上的显存。

Xcode呢？下载超过5GB。安装后，它在我的硬碟上大概须要10GB。那是一个完全不同的联盟。AndroidStudio为500MB，AndroidSDK为1.5GB。虽然尚不清楚它们是否比Godot提供更多的功能，但这种功能还是很大的。

仅用于演示内容的主题讲演有433.5MB。它可能会排除共享框架。

让我们看一下Godot在大小上与哪种应用相比。1已安装用于管理密码的密码55.5MB。十分接近戈多。电邮约为30MB，相片约为50MB。

换句话说，Godot的大小十分接近具有极其窄小的功能集的应用程序。

使用上去很爆燃

与我曾经使用过的相比，GodotGUI设计的工作速率特别快。她们在建立UI时确实考虑了许多常见问题。

您将GUI建筑围绕以下所示的场景树居中。

>Add,duplicateandrenameGUIcomponentswithkeyboard.

您可以使用鼠标在该树上上下联通。所以我可以使用箭头键移至要向其添加GUI组件的容器或面板。之后，我可以按Cmd+A（在Mac上）以打开一个对话框来选择GUI组件。

您会弹出下边的对话框。

>CorrectGUIcomponentisquicklylocatedwithfiltering.

如今，您可以使用键盘展开一棵小树，显示成吨的节点。并且十分有效的是，当对话框打开时，您将立刻步入搜索栏。我可以开始输入"按键"来查看存在类似节点的按键。当我输入内容时，列表会被过滤。

在发生此类情况时，我可以同时用箭头键移入列表进行选择。虽然这样做，我也不会错过对搜索栏的关注。

为此，我可以选择所需的节点，之后按Enter。它作为子级添加到我当初选择的节点中。

这样，我完全将鼠标与箭头键，Cmd+A和Enter结合使用来建立GUI。假如我按下某个组件上的Enter键，则可以修改其名称。假如我按Cmd+D，则将其复制。为此，我不须要多次打开并搜索标签。假如我晓得我须要10个标签。我可以做一个标签，之后重复10次。

SaneUI组件选择

然而，使用该系统的效率并不止于此。

在各类UI设计工具中，对我来说最令人失望的事情之一就是选择由多个其他组件组成的UI组件。诸如。在QtCreator中，我常常会尝试选择一个包含子组件的布局，而只是意外地选择了一个子组件并将其拉出布局。

在Godot中，意外选择子组件不是问题。请注意，我在下边的MarginContainer门口用粉蓝色圈出的小图标。之所以切换此图标，是由于我先前单击了工具栏中的红色圆圈图标。这样可以防止在画布上选择宝宝。我依然可以在树中选择它们，而且假如单击布局正确的组件，则会得到父项。

>Blockingchildnodesfromgettingselectedbyaccident.

这确实很实用，由于它可以轻松处理布局。在其他编辑器中，选择布局可能很棘手。戈多的另一个重要细节。您无需在画布上修改父级关系，仅在节点树中即可。为此，您不会意外地从层次结构中提取组件。在这些情况下，您要做的就是将子组件相对于其父组件的相对位置修改。

UI组件的中级订制

在任何中级GUI中，您将须要以特殊形式配置的许多特殊的自定义GUI组件，以适宜您的应用程序。

这对传统的GUI设计人员来说从来都不是一件好事。您可能可以对组件进行子类化，但一般它只会在GUI编辑器中显示为白色菱形。

并且，假如确实显示，则不能对其进行太多配置。一切一般都必须用代码完成。Godot并非这么。

在右图中，您可以看见我们已将脚本附加到名为ColorPicker的节点上，该脚本的类型为OptionButton。将脚本附加到Godot中的节点等同于对该节点进行子类化。这就是为何您可以看见脚本代码说扩充OptionButton的诱因。

OptionButton是一个下拉菜单。开箱即用Godot在GUI中没有任何机制可以指定应包含的元素。

然而，我们可以将自己的属性添加到Godot编辑器的任何场景节点对象的检测器中。您会在突出显示中看见我已编撰以下代码行：

export(Array,String)varitemvalues=["red","green","blue"]

这告诉Godot成员变量itemvalues应当在Godot编辑器中可见。我也告诉它这是一个带有String元素的字段。GDScript使用的语言是动态键入的，因而它们更像提示。

这样的结果是，您可以看见选择了ColorPicker时，检测器将显示itemvalues的条目，我可以在其中更改元素。您可以看见在此示例中，我将最后一个值从"blue"修改为"cyan"

组件已加载到场景中并打算使用时，将调用_ready函数。在这些情况下，我们借助机会来读取用户将itemvalue设置为何，并将每位条目添加到下拉菜单框中。

聪明并不止于此。假如我复制此组件并在其他地方使用它，则将使用相同的附加脚本。假如我修改一个组件上的代码，它将修改所有其他组件上的代码。为此，它们不会轻易脱离同步。假如我确实想要自定义行为，则可以在特定组件上分离脚本。或则，我可以使用泛型扩充它以改善行为。

编辑和更改正在运行的应用程序

我可以继续讲其他几十个小细节，这使GUI编辑在Godot中显得轻而易举。但我希望我能理解她们对人体工学的真正看法。

过去遇见的许多问题妨碍了我有效地使用她们虽然意料到的GUI。

然而，真正的杀手级功能可能是您可以在运行应用程序时运行其应用程序并更改其GUI布局和附加脚本的代码，但是这种修改会立刻反映在正在运行的应用程序中。

确保可以在运行时编辑代码的这些功能以某种方式存在于许多地方。并且，假如您的经历像我的一样，这么您都会晓得，假若您使用编译语言，这么这种东西一般会很脆弱而且很有限。

Godot使用一种动态语言，该动态语言具有称为GDScript的Python句型，该语言专门为与编辑器集成而设计。这意味着它借以处理重新加载和同步。并且您可以说它确实运行良好。

这是一种极其容易学习的语言。我基本上是在三天之内捡上去的。它与底盘的集成度十分好。

您可以命令单击任何内容以跳至其定义文档。您可以挺好地完成命令。虽然它不是真正的静态类型语言，它在弄清楚类型方面也十分出众。如同现代Python一样，您可以在任何想要改善推测的地方添加类型提示。

它除了完成类型名称和函数名称。当您在场景图中写入到节点的路径时，它甚至会完成字符串。

那赛事呢？

其实，取代方式是使用例如Electron，QtWidgets，QtQML或Cocoa之类的东西。代替方案的第一个问题是它们是巨大的肿的笨拙野兽。

假如有人想查看您正在使用的GUI，可以考虑一下，您可以将它们发送给Godot项目文件，而且距离她们31MB的下载距离。哦，我是否告诉过您，Godot是完全免费的开放源代码，并获得了MIT的许可？

没错，任何人都可以免费下载它，并通过Godot进行任何所需的操作。

Qt小部件

尝试让他人瞧瞧您制做的Qt设计。"糟糕，您须要5GB的下载量能够做到这一点。哦，顺便说一句，您须要在网站上注册一个账户，登陆和搜索真的很难找到免费版本。"

>ScreenshotofQtCreatorinactiondesigningaGUIusingdesktopwidgets.

更不用说，假若您使用的QtWidgets应当用于小型专业GUI应用程序，这是我在这儿讨论的主题，这么您必须使用谦逊地说很糟糕的GUI设计器。实际上，这就是为何我制做了自己的标记语言ERML的缘由，只是为了容许对Qtui文件（而非QtCreator的GUI）进行更合理的编辑。

QtCreator为何会吸引您的要求？本文提及的许多事情。选择和使用组件的嵌套布局几乎是不可能的。并且对象树结构未能让您做任何有用的事情。

它基本上是一个"只写"系统。您可以使复杂的GUI相争当，并且祝您稍后运回并进行重大更改。您将见到布局的喙，而且您将不记得怎样将其放回原先的状态。

但是，没有一种合理的方式来定义要在编辑器中使用的自定义组件。在Godot中，这很简单。您可以制做由其他组件组成的任意复杂组件，并轻松地重用它们。其实，您可以在QtCreator中复制粘贴GUI组件的集合，而且假如您决定要进行更改，就很麻烦。

相反，在Godot中，您可以使用作为模板制做的GUI组件的集合。也基于该模板修改来修改模板和所有其他GUI组件。

更不用说您不能修改用户界面的生活。QtC++项目很容易获得很慢的周转时间，这在制做GUI时完全失去了生产力。

QtQML搜救了吗？

这么QML呢？它解决了许多问题，并借助动态语言简化了动态修改类型。

老实说，我不记得QML的工作细节。我只记得它不像我希望的那样直观。编辑器花了我好多时间来封住我的头，它真的一点也没有磨光。

好多东西觉得很慢。我制做的GUI疗效不佳。当我调整窗口大小时，虽然是相当简单的东西也很难重画。其实由于它是为联通设备设计的，因而并未针对修改规格的窗口进行优化？我不晓得。

虽然进行了各类测试，但我在绘图中未能获得令人满意的性能。而且，最大的杀手可能是没有全面的中级小部件来建立中级GUI应用程序。

Coco和SwiftUI

在Swift中使用Xcode的iOS应用程序时，我早已使用基于约束系统的布局管理器。这是一个十分强悍和先进的系统。

原本，我觉得这确实是前进的公路。并且按照我的经验，它太复杂了，难以使用。虽然对于简单的屏幕，有时我也遇见了极其复杂的约束，很难调试。

其实我在Xcode和Swift上耗费了好多时间，但其实对它的疗效的最终测试是在离开Xcode和Swift一段时间后，又花了多少时间重新步入它。

这对我来说疗效不佳。我难以理解过去所做的好多事情。斯威夫特显得太复杂了。这是一种不错的语言，并且具有嘲讽意味的是，它正在开发一些与C++和Haskell相同的问题。类型系统的复杂性和严格性常常出现在您的面前。

这是一把双刃剑。当我开始使用Swift时，我很喜欢强类型键入怎么捕获许多错误。但这总是让人倍感mixed贬不一，由于与类型系统作斗争是时常发生的事情。如今虽然情况显得越来越糟，尤其是在处理闭包时。

整个设置很容易给您带来精神负担。我难以有效地使用该系统，由于我根本没法将您须要了解的所有内容都保存在脑海中。

SwiftUI其实是一个有前途的选择。它遵守与QML相同的技巧。我觉得这是一个很有前途的模型。我并不反对QML，由于我觉得这不是一个好主意，只是由于我觉得它执行得不好。

我只简单地使用过SwiftUI。对我来说，这显然是一个显著的改进，但恕我坦言，它始终不及Godot。当您获得GUI组件的GUI检测器面板时，依然不得不在很大程度上用代码编撰GUI。我觉得GUI编辑应当同时支持三者。GUI设计是十分直观的过程恕我坦承。

其实更重要的是，一直没有能力对正在运行的应用程序进行实时修改和更改。对于具有小型项目的复杂GUI应用程序，在您要进行测试之前必须先对其进行加载，这是一个杀手kill。

HTML5，CSS和JavaScript

我对Web技术的讨论须要一些免责申明。我对网路技术的经验甚少，但是我不太喜欢网路技术。我是一个老派的GUI工具包人，他在旧的Amiga1000上使用Intuition工具包进行了他的第一个GUI工作。

>ThisiswheremyGUIprogrammingstarted,onanAmiga1000runningWorkbench

我依然必须承认，我喜欢Web技术的许多方面。在浏览器中，您可以实时编辑和修改属性，还可以立刻查看对GUI的修改。

然而，我看见几个特别大的问题：

·这真的很复杂。我在学习现代HTML5，CSS和JavaScript框架方面的个人经验须要耗费大量时间。我企图概述不同的Web技术以及它们之间的关系可能会给人一种觉得。

·它是为网页而不是应用程序制做的。当尝试为应用程序制做GUI时，我发觉我时常遇见假定我们处于某个可滚动网页中而施加的限制。

·它不是为可重用的组件（如真正的GUI工具包）而制造的。

前者须要一些解释。创建可重用组件的Web方式是通过某种模板。基本上，您只是几次复制粘贴一段HTML来代表新的自定义组件。

这意味着您一般在通过模板引擎进行工作，而且在编撰的内容与Web浏览器中发生的事情之间没有一对一的映射。

这与诸如Godot相反。从开发的角度来看，我可以创建一个自定义组件并将其实例化。当我在应用运行时进行实时更改时，这种事情是一回事。在实时应用程序中，我得到了与编码时相同的节点。这有助于整个往返行程，并增加了与此相关的心理复杂性。

如今，使用游戏引擎制做应用程序虽然有些疯狂，由于因为须要持续渲染，它确实泄露了更多的CPU周期。并且，与基于资源的基于Web的应用程序相比，在许多方面它变得惨白无力。

VSCode和Atom之类的编辑器表明，可以使用网路技术来制做一些很棒的东西。并且，我们也有像InsomniacGames这样的公司，她们尝试使用网路工具制做游戏引擎编辑器。

那主要是一次失败的实验。她们看见的问题是，它的工作太糟糕，难以制做复杂的自定义GUI组件。现在，大多数网路技术的使用都没有问题，由于它们不使用自定义组件。原子比如没有色轮的颜色选择。

为何游戏引擎是未来？

使用游戏引擎制做GUI应用程序虽然很疯狂。人们可能会认为这样做是本能的。

但我觉得，世界有可能以这些方法结束，这有挺好的理由。这一切都与金钱在那里以及激励作用有关。

游戏业是巨大的。现今的游戏具有巨大的复杂性，可以与大多数实际应用程序媲美。游戏开发面临一些残酷的生存条件。

它们必须容许开发特别高性能的代码，因而压缩计算机的每一分性能。她们必须在进行迭代的同时执行此操作，而且制做游戏时必须十分快速，轻松地进行实验。游戏几乎就是定义，不是您可以预先明晰定义的东西。为了使游戏正确，须要进行大量的调整，实验和玩法。

这造成游戏引擎解决了我们这些在小型复杂GUI应用程序上工作的人们所面临的问题。运行代码的实时更改在游戏引擎世界中是很正常的事情。它一定要是。每次要在特定级别尝试调整某项内容时，都未能重新加载整个可恶的内容。

将此与引起问题的大量资金结合上去。小型而复杂的GUI应用程序只是一个冷门市场，游戏不是。

这就是为何为机器人制做模拟器的人最终转而使用游戏引擎的诱因。引擎市场意味着游戏引擎在质量，性能和易用性方面远远超过机器人模拟器。

这些借助规模经济看似无关的古怪事物的方式并不是哪些新事物。诸如。特斯拉构建在这样一个看法上，即她们不使用订制车辆电瓶制造车辆，而是选择了使用7000电脑电瓶为车辆供电的看似疯狂的看法。

看来这是一个愚蠢的解决方案，但之所以奏效，是由于标有标记的电脑笔记本十分庞大，这使电脑笔记本的电瓶确实十分实惠。

这将通过传统的GUI工具箱来实现：它们将落后于竞争激烈的游戏引擎世界中正在发生的一切。

使用游戏引擎的关键缺点是不断渲染，这会造成较高的恒定GPU和CPU使用率。虽然阅读本文的许多人反复向我强调，但Godot实际上确实具有低CPU使用率模式。其实，仅当须要重新渲染对象时才渲染。其实我们也可以吃一块面包吗？

我写了这个故事，觉得Godot是解决小型复杂GUI的人们的挑战的答案。但这其实实际上是每位人的解决方案。据我所知，Godot引擎为解决方案降低了20–30MB的花销。对于中等大小的应用程序，可以接受。虽然与我的日常编辑器TextMate相比，前者的大小为30MB。并且，与500-600MB的Atom编辑器相比，实在是太实惠了。

这么，为何要跳到Web技术上以获得跨平台的GUI应用程序呢？我们有一个Godot工具，它可以在所有主要平台上运行，它使用最少的资源，任何人都可以快速开始使用它。

简而言之，现实是网路技术广为人知，并将保持其主导地位。并且，我觉得对于小型复杂的GUI应用程序，我们仍然盼望选择，而Web技术根本没法解决问题。假如Godot要攻入应用程序开发市场，她们可能必须像特斯拉那样做，从高性能街车开始，之后逐渐发展到日常用车。

现实世界的事例

眼见为实。不确定是否可以使用Godot进行真实的应用程序？瞧瞧那些家伙。我们约请了AlfredReinoldBaudisch，他很愿意分享他使用Godot制做Trello克隆的经验。

我们有安德鲁·沃尔德里奇（AndrewWooldridge）撰写了有关在Godot中制做RSS阅读器的详细手册。

但是我相信还有更多示例，可是我是Godot的初学者，但是没有完整的概述。

(本文翻译自ErikEngheim的文章《IsMakingAdvancedGUIApplicationswithGodottheFuture?》，参考：