Godot: 事件表样式可视化脚本

为当前的可视化脚本赋予更多更好的功能，难道不能缓解很多这种情况吗？

许多示例在 UE4 的蓝图中都是微不足道的。 “在按键 W 上，向前移动这个演员”。
您可以在蓝图中以非常相似的方式构建其中的大部分，甚至视觉差异（这将是唯一的差异）也将是最小的。

我们应该专注于使我们拥有的可视化脚本可用，并以直观、流畅的方式工作，IMO。 事实上，我们已经拥有的可视化脚本感觉有点被遗忘了，似乎并没有得到太多的爱。 拥有两个可视化脚本系统将如何改善这种情况？

一个插件的好主意。 但是正式维护两个可视化脚本系统会很痛苦，而且收效甚微。

@mhilbrunner不幸的是，蓝图是一种完全不同的可视化脚本方法。 对你来说，它们是微不足道的，但我敢你在 clickteam 的论坛或construct 的论坛上这么说。 这些人被他们使用的引擎卡住了，因为他们非常喜欢这种方法并且相信我——他们中的许多人已经尝试过 Unity、虚幻和其他引擎中的蓝图——包括 godot。 他们仍然坚持使用construct2 或clickteam fusion，因为他们更喜欢事件表而不是蓝图。 他们仍然要求在统一论坛上使用事件表方法。
在他们的论坛上提到了 Godot 的可视化脚本，那里的用户仍然更喜欢事件表。 我个人过渡到 gdscript 并且更喜欢使用 gdscript 而不是蓝图 - 因为 gdscript 在其优势方面比蓝图更接近事件表。

这就像告诉喜欢香蕉的人吃西红柿一样——这是一个口味问题:)

@groud我有一段时间也这么想，但我什至不知道从哪里开始——甚至作为插件——有人必须维护插件。

@reduz似乎对 facebook 上的这个想法感到更忙于更重要的事情

无论如何，我在此处发布此文档以作为文档 - 概述事件表系统 - 它的作用以及它与蓝图的不同之处。 如果其他人有兴趣在 godot 或插件中实现它，请告诉我们。 我肯定会卷起袖子提供帮助，传播新闻并从 clickteam/construct 用户那里获得反馈。

到目前为止，我什至不知道如何正确实现其与 godot 的 GUI 类的接口。 您必须能够在同一列的单元格之间拖动逻辑块。 也复制/粘贴块/行 - 嵌套行和
其他独特的东西。 我不认为这是一项小任务

@blurymind是的，非常感谢您指出这一点并花时间进行详细的撰写。 仍然认为这作为插件可能会更好。

开发人员：以最小的复杂性添加它的最佳方法是什么？ 也许我会抽出一些时间来研究当前的可视化脚本是如何工作的。 想知道是否有可能主要替换 Visual Scripting UI 或生成 GDScript 或其他动态执行此操作的方式。

不过还没有研究过，所以欢迎指点。 :) 没有零指针，拜托！

@mhilbrunner我们也许可以在跟踪器上打开另一个问题，其中列出了

我在这里的帖子是对替代方法的建议，而不是对当前实施的方法的更改。 无论如何，事件表都太不同了

我相信这样的事件表可以通过 Nativescript 实现，但我看不出它需要依赖与可视化脚本相同的代码库的任何理由。

@groud这实际上是一个好点。 当前的可视化脚本代码库中有多少可以重用？ 它对节点图接口的具体程度如何？

@blurymind是的，您正在为 VS 编写这样的列表，并且会这样做，但需要一些时间。

需要调查 NativeScript :)

我们现在有多种脚本语言选择（C++、C#、甚至 python）。 为什么不也有不止一种可视化脚本选择:)

我想这也可能取决于 godot 的 api 用于构建可视化脚本界面的灵活性。
应该重用可视化脚本代码库 - 还是应该用 Nativescript (c++) 编写一个完全替代的代码库？
这可以作为 gdscript 插件实现吗？

为什么不也有不止一种可视化脚本选择:)

因为我们已经内置了太多语言。 大多数用例已经涵盖，因此没有太多理由添加新语言来维护。 我们有一种用于基本编程的语言（GDscript），两种用于表演（C# 和 C/C++），一种用于艺术家/游戏设计师（视觉脚本）。 没有理由仅仅因为某些人无法处理学习新语言而添加另一种语言作为内置语言。

老实说，我绝对不认为这应该被添加到核心。 最好像任何其他语言绑定一样通过插件添加。 我们已经有足够的工作来维护当前的语言。

不，我不认为我们可以重用可视化脚本的代码。

@groud这是一个很好的观点，但请考虑游戏开发中程序员与艺术家的比例。 一些最伟大、最美丽的复古 2d 游戏是由艺术家使用 fusion 2 制作的，他们希望以符合他们思维方式的直观方式制作游戏。 这是 Fusion 制作的游戏的有点过时的节目：
https://www.youtube.com/watch?v=3Zq1yo0lxOU

他们在 Steam 上有许多成功的 kickstarter 项目和游戏——许多平台上的游戏。 人们喜欢在可视化编程中使用这种方法——甚至是专业团队。 如果我没有看到扩大用户群的潜力，我不会在这里展示它

好吧，也许，但他们中有多少人能够理解事件表而不是 VisualScripting？ 你是说“那些人被他们使用的引擎卡住了，因为他们非常喜欢这种方法并相信我——他们中的许多人都尝试过 Unity、虚幻和其他引擎中的蓝图——包括 godot”，但你实际上是第一个问这个的。

如果这是一个受欢迎的需求，是的，我们可以将其添加到核心中。 但直到现在还不是。

对我来说，我们已经涵盖了所有用例。 至少对于最先进的专业游戏引擎而言。 而且由于我们的目标不是孩子或业余爱好者，而是公司，因此不值得花时间在上面。 Fusion 2、Construct 甚至 RPGMaker 都专注于其他观众，即使他们制作了精美的游戏，但其中只有一小部分是专业项目。

@groud这些统计数据很难获得。 有多少人在使用当前的可视化脚本？

我还指出了为什么事件表方法比蓝图更有优势 - 例如更少的点击来让事情工作，更清晰的演示和更好的学习过渡到 gdscript。

如果你问我，rpg maker 引擎真的是一个关卡编辑器。 它没有 Fusion 和construct2 相同级别的灵活性

向某人解释事件表的工作原理比在蓝图中解释相同的示例更容易——他们必须学习更少的概念——不需要教节点之间的连接类型、输入和输出的类型- 如何设置流量。
相反，事件从上到下流动，左边是条件，右边是动作。 您无需连接任何东西。

做这个

看起来这么难理解？

当然，godot 会使用更多的事件块来实现，但它仍然会比节点图更清晰。
甚至 gdscript 在我看来也比这更清晰。 乍一看，我们当前的可视化脚本系统看起来很复杂

我作为一个使用过这两种系统并且现在正在比较它们的人发言 - 两者都同样强大，一个显然更容易学习和进入
请试一试。 您可以在这里免费试用您的网络浏览器中的construct3：
https://www.scirra.com/
如果您有儿子或弟弟妹妹，请让他们尝试一下，然后尝试 godot's - 看看他们能做什么以及在没有给出指示的情况下他们需要多长时间才能做到 - 这里有更多学校采用 godot 的潜在市场- 使可视化脚本更好地学习编程概念，我们将使用引擎获得更年轻的人​​口统计

有多少人在使用当前的可视化脚本？

我不知道，但我现在相信不多。 大多数人现在似乎都在使用 GDScript，因为我在 Facebook 或 Youtube 上没有看到很多关于 VisualScripting 的问题/内容。 在确保 VisualScripting 不能回答所有用例之前添加事件表将是一个大胆的赌注。 现在让我们看看 VisualScripting 是否足够，如果人们大量要求另一个系统，我们可能会在以后添加它。

如果我们可以在学校环境中测试 godot 的可视化脚本， @groud会很棒——让孩子们学习基本的编码概念。
construct2 最大的卖点之一是教孩子们编码，他们多年来一直在销售特殊的教育许可证。

我的论点是，目前 godot 中的可视化脚本对非编码人员来说不是很有吸引力，并且并不能真正帮助人们学习如何编码——因为它的方法纯粹以状态机为中心，并且基本的编程概念会因附加节点图而变得更加复杂中心规则在上面。

经验丰富的程序员真的不是最好的销售对象——因为他们会将事件表视为我们已有的 gdscript 的简化，并将蓝图视为设计师可以用作状态机的新工具。

我很想尝试在 gdscript 中编写一个基本的事件表插件，我真的没有足够的经验来制作一个原生脚本插件。 如果这是可能的，并且您有一些从哪里开始的指示 - 我很想听听他们
也许如果有足够的兴趣，有人可能会用 nativescript

因为它的方法是纯粹以状态机为中心的

什么 ？ 我不知道你为什么会这样想。 VisualScripting 与状态机无关。

目前哪个更容易使用 - 蓝图或 Gdscript？ 可视化脚本的目标是什么以及目标用户是谁

对于艺术家/游戏开发者来说，VisualScripting 应该比 GDscript 更简单。 我不得不承认现在还不是真的，可能一堆节点可能会被简化/变得更有吸引力。 但老实说，您认为事件表比 VisualScript 更容易理解是错误的，但对我来说并非如此。

唯一真正使您展示的示例有所不同的是使事情更容易理解的文本和图标。 是文本和图标使事情更加明确和直接，而不是垂直组织。 如果我们添加这样的图标，如果我们为大多数常见操作制作更好的 GUI，并将功能分组到相关类别中，那么 VisualScripting 将是可以理解的。

@groud它也是执行顺序和连接类型。 在节点图中需要注意的概念比事件表要多得多。 即使您将图标添加到节点，您仍然必须解释事件的顺序由白线决定，以及其他颜色的含义。 你仍然会得到一个难以阅读的意大利面条图 - 你的眼睛必须四处走动才能弄清楚其他人的图表中发生了什么

您不是正确的目标受众——您是一位经验丰富的 c++ 程序员。 请与非程序员的人一起进行测试，您将开始明白我的意思。

来吧，这并不难理解，我们再一次不是针对孩子的。
关于代码组织，事件表的问题也是一样的。 如果您不费心对节点进行分组和组织代码，那么您最终会得到不可读的代码，无论是由于冗长的事件表还是巨大的节点图。

@groud我们甚至可以像在搅拌机中那样对可视化脚本节点进行分组吗？ 我不记得看过那个。 也许@mhilbrunner应该将它添加到他的列表中
https://github.com/godotengine/godot/issues/12418
另一个重要的一点是，通过 gdscript 创建可重用的更高级别的动作/条件逻辑块对于事件表系统或蓝图系统非常有益。 蓝图系统已经有了它 - 但我没有看到为它制作的任何插件..

再次——construct2 遥遥领先于我们。 他们的社区创建了许多易于安装的插件，这些插件添加了自定义条件和动作 - 他们的 api 注册动作和条件非常简单
https://www.scirra.com/forum/completed-addons_f153
https://www.scirra.com/manual/19/actions-conditions-and-expressions

完全符合blurymind
对我来说，理解 Construct and Fusion 事件系统要容易得多，它也比一个充满线条的系统更快地开发任何游戏

笑是怎么这更容易比gdscript阅读

@groud我们甚至可以像在搅拌机中那样对可视化脚本节点进行分组吗？ 我不记得看过那个

我不知道。 但如果没有实施，我认为应该是。

大声笑这怎么比 gdscript 更容易阅读

这不是重点。

@groud是的。 为什么游戏开发人员要使用事件表，因为它比简单的 gdscript 代码更杂乱/难以阅读？ 这就是这个功能建议的全部症结不是吗

@groud是的。 为什么游戏开发人员要使用事件表，因为它比简单的 gdscript 代码更杂乱无章？

不，不是，VisualScripting（或事件表）和 GDscript 的目标不是同一个人。 VisualScripting（或事件表）适用于艺术家或游戏/关卡设计师，而 gdscript 需要编程经验。

比较事件表和 GDscript 没有任何意义。

比较事件表和 GDscript 没有任何意义。

好吧，这就是我们不同的地方：P，因为我认为比较它们是非常合理的。 特别是因为 gdscript 在更简单的级别上完成了他们所做的一切。

另外，我不同意“需要编程经验”。 如果关卡设计师正在创建动作块_在事件表或可视化脚本中_，他们_已经有了基本的构建块_来使用 gdscript。

话虽如此：JIT 编译的 gdscript 在路线图上，并且比事件表或可视化脚本添加更有益（因为大多数 godot 开发人员已经可以从中受益匪浅）。 VS/Event Sheets 的潜在用例目前非常低。 所以我要问的只是请谨慎对待领导开发时间，因为你最近的帖子已经提到过

@girng 您在什么时候决定我试图窃取路线图上其他重要功能的优先级？ 这篇文章正在通过一种替代方法来探索可视化脚本的好处，而不是我们目前所拥有的方法。
它甚至不在路线图上，但你跳起来就好像它是来吃你的早餐一样。 :p
探索一个想法并不等同于花费时间。

你显然从未接触过construct或clickteam fusion，如果你想讨论它——至少使用事件表一段时间——用它制作一个平台游戏。
我链接到construct3的在线演示，它不需要您注册帐户或登录。
https://www.scirra.com/
只需点击三下

尝试事件表，用它做点什么。 然后使用godot拥有的visualscript蓝图

Gdscript 很简单——是的，我同意并且也喜欢它。 一个 jit 编译的 gdscript 会很棒！ 同意它也更重要。
但是这个讨论根本不是关于那些事情的

好吧，这就是我们不同的地方：P，因为我认为比较它们是非常合理的。 特别是因为 gdscript 在更简单的级别上完成了他们所做的一切。

你不明白的是，对于很多人来说，编码和不编码之间存在思维障碍。 我不得不承认 VS 现在有点难以入门，但在未来它应该比 GDScript 更容易，因为可能已经创建了很多学习材料并且应该对 VS 进行一些改进。

另外，我不同意“需要编程经验”。 如果关卡设计师已经在事件表或可视化脚本中创建动作块，那么他们已经拥有使用 gdscript 的基本构建块。

是的，作为一名程序员，我也非常同意，但这不是经验所显示的。
虚幻就是一个完美的例子：很多人在虚幻中使用蓝图，尤其是在专业领域，因为它们允许非程序员以更受欢迎的方式编写代码。 即使它与实际代码没有什么不同（在我看来），它也会在人们心中产生差异。 如果专业人士使用它，这意味着它是一种真正的需求，而不是我们应该放弃的小工具，因为我们认为它们是相同的东西。 这就是为什么比较它们是没有意义的，两者都应该可用并且正常工作。

无论如何，我将在这里停止讨论。 关于 VS 与否 VS 的讨论已经得到处理。

@blurymind我很佩服你的精力，你提出了很好的观点。 我之前在构造中尝试过事件表，起初它们很酷，但我的游戏越先进，我立刻想回到代码。 所以是的，我过去曾尝试过。

@groud对他们提出了很好的论据，因为 Marvel Heroes 是 AAA aRPG，他们使用了带有Unreal 的蓝图。

我不反对他们有自己的用例，我只是认为根据以下标准很难证明是合理的：

• 开发人员有限
• 当前问题的数量已经
• 杂乱无章/难以阅读（见这里）
• 我觉得大多数 godot 开发人员宁愿使用 gdscript
• gdscript 与 godot 的关系非常好
• 如果添加到 core ，可能会出现围绕事件表的新问题，这可能会消除 gdscript 问题
• 对目前已经使用 gdscript 的 90% 的 godot 开发人员不公平（如果开发时间可以用于 jit 编译的 gdscript，它可以满足活动用例）

作为一个我可以完全支持的插件，但我的心是如果它得到官方支持可能不是一个好主意

@girng谢谢。 再一次 - 这不是替换 gdscript 或可视脚本的请求。
它更多的是对一般可视化脚本的观察，以及目前 godot 的可视化脚本对非编码人员的用户友好性如何。

Gdscript 可以与任何可视化脚本系统（事件表或蓝图）完美结合。
正如我在第一篇文章中所指出的——事件表方法也使用表达式——gdscript 已经可以使用这些表达式。 更高级的逻辑块可以通过 gdscript 和 godot 的插件系统创建——它与可视化脚本系统完美结合。

事实上，事件表系统可以更好地与 gdscript 结合，而不是当前的蓝图系统——其中表达式是用十亿个节点图完成的，而不是简单的文本字段输入。 如果你想做 1+1- 使用节点。 如果您想在表达式中处理一个简单变量，请使用另一个节点。 你最终会得到一个由十亿个基本节点组成的意大利面条式的混乱，用于一个简单的表达式，它可以在一个很小的文本字段中更容易、更清晰地写出来，而且省力和冗长。

我们当前的可视化脚本需要太多的点击、节点和冗长来做最简单的事情。 这是 gdscript 更直接 imo 的另一个原因 - 一行代码而不是 10 个节点和 100 个连接。

这基本上是事件表系统的另一个优点 - 您可以在代码块输入字段中编写表达式。 construct2 和 fusion 甚至都具有自动完成和表达式编辑器，可以轻松访问节点具有的所有方法，其中包含工作表在范围内可以访问的所有节点的列表。

在做同样的事情时，Godot 可以很容易地简单地将 gdscript 用于表达式 - 但这些表达式放置在一个简单的电子表格结构中。

把godot中的一个方法想象成一个逻辑块。 就像它的方法一样——该块采用相同的参数——但你不需要将它连接到节点。 您可以在其输入字段中输入一些 gdscript。
godot 中的节点可以充当construct2 中的行为，godot 中的事件表将比construct2 更灵活和强大。 它不会有他们的引擎所具有的任何缺点

Construct 配对对象的方法很糟糕——除其他外——但这与事件表设计无关

我们当前的可视化脚本需要太多的点击、节点和冗长来做最简单的事情。

这不是 VS 的固有缺陷，而是它目前有限的实现。 这应该是固定的，而不是用作在它旁边实现另一个可视化脚本方法的参数。 否则，当前的 VS 应该报废。

此外，讨论 GDscript 的 JIT 是题外话。 功能的优劣只能通过以下方式衡量：

• 与可能对同一用例有用的其他类似功能相比，它的实用性
• 它的实用性与它带来的复杂性、增加的技术债务和 Godot 的维护负担

所以这是否应该做与我们是否为 GDScript 实现 JIT 无关。 否则，我们应该关闭 99% 的所有功能请求，直到所有主要错误都得到修复，即永远。 对于 GDScript，这些甚至比 JIT 更重要。

GDScript 的 @mhilbrunner JIT 实际上会发生，它已经在官方路线图上：P。 我只是说这可能会占用开发时间。 并且很难证明这是因为 90% 的 godot 开发人员已经使用 gdscript（而且很多人认为它比事件表更好，并且有自己的感受）。 对不起，如果我没有正确地表达自己。 是的，我知道这并不能取代它，但我要更多地谈论开发时间。

话虽如此， @blurymind我不能不同意你所说的任何话，因为它们真的很好。 在 Godot 中拥有事件表会是一个很好的功能吗？ 是的，但它很快就会在现实中发生吗？ 我不太确定。 （自 2014 年以来只是一个狂热的用户，这只是我的看法）

我自己之前使用过 Action Game Maker 和 Game Maker 事件表，我同意它比 VisualScript 更容易使用和理解（你从上到下阅读，而不是逐行阅读），不占用太多屏幕空间，并且可以实现有限状态机更容易（通过过滤在事件完成后可以触发哪些事件）。

这将是一个非常好的补充。 我自己可能不会使用它，因为 GDScript 对我来说已经足够了，但是如果 GDScript 不是一个选项（初学者和非程序员可能正在经历），我可以想象自己使用它就好了。

好吧，我是 Godot 用户大约一年了。 我喜欢 GDScript，它的语法很简单。
但是我使用 Construct 已经 8 年多了，我可以说我从来没有见过比 Event Sheets 更简单的可视化脚本。我不喜欢 Blueprint，我使用了其他一些 VS Blue Prints 样式，比如 blender 和 Unity，我不喜欢不明白人们怎么会说 Blue Print 比 Event Sheets 更容易。也许是因为艺术家习惯于使用节点来设置着色器和图形，他们习惯了这种美学。 但我敢打赌，如果你将事件表系统放入像 Unreal 这样的引擎中，人们会放弃蓝图。

我在一所向儿童和青少年教授编程逻辑的学校工作。 对于孩子们，我们使用 Construct 2，因为他们很容易使用 Event Sheets 创建一些东西。 对于青少年，我们使用 GDScript，并取得了不错的效果。 在 Godot 3.0 出来的时候，我们研究了放弃 Construct 2 使用 Godot VS 的想法，但是我们放弃了这个想法，因为现在 VS 比 GDScript 更难，理解和使用都非常复杂。 如果 Godot 有类似 Event Sheet 的东西，我们会让我们的课程完全基于 Godot，因为我们倾向于在学校支持开源解决方案。

我认为 Event Sheets 会带来的其他好处是，它将增加 Godot 用户群，因为在 GDC 中，我们看到大中型工作室更喜欢 Godot，但小型工作室更喜欢 Unity 和其他解决方案。 我认为来自 Construct、Fusion 和 Game Maker 的用户会开始迁移到 Godot。

嗯，作为一名教师，我看到了 Event Sheets 的巨大价值，因为它很容易掌握，而且当学生转向 GDscript 时，他们已经形成了逻辑思维，而且 Event Sheets 结构更像是代码而不是 Blue Prints。

无论如何，我喜欢 Godot 正在做的事情，也喜欢 GDscript，我只是想分享一下我的经验，因为我同时使用 Event Sheet 和 GDscript 进行教学。 保持伟大的工作！

在 Godot 3.0 出来的时候，我们研究了放弃 Construct 2 使用 Godot VS 的想法，但是我们放弃了这个想法，因为现在 VS 比 GDScript 更难，理解和使用都非常复杂

这是一个非常有趣的反馈。 :)
事实是 Construct2 形式的事件表比 VS 或 GDscript 低得多。 事实上，他们可以帮助孩子们进入游戏编程领域，但这不是 Godot 的目标。 我相信这样的系统不应该作为内置的，而应该通过插件提供。 我想reduz的这条评论也表达了这一点。

@DrZanuff感谢您提出这一非常重要的观点——kidscancode youtube 频道和@NinkuX也注意到了同样的

也许 Godot 可以像游戏制作者那样处理这个问题——他们的拖放可视化代码被直接翻译成 gml 代码，甚至可以实时预览。 这样，非编码人员可以在使用引擎的可视化脚本系统时学习 gml - 这是 yoyo 游戏用来让非编码人员逐渐了解 gml 的确切策略
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changeing_dnd.html

无论是在使用一些 gml 作为表达式时，还是在他们预览他们的可视化编程正在做什么时

即使作为一个插件 - 我一直认为 godot 的事件表对象最终应该被翻译成 gdscript。 事件表可以成为教非编码人员如何使用 gdscript 的工具——通过为他们提供一个简单的界面，该界面仍然允许使用 gdscript 进行表达式，并最终生成和预览 gdscript。

Godot 的 API 有一种生成 gdscript 文件并将它们附加到节点的方法。 因此，可以在运行游戏时将事件表转换为 gdscript，甚至在编辑事件表时也可以像游戏制作者那样进行转换。

clickteam fusion 和construct2 使用的附加学习辅助工具是基于单击的内置节点方法/成员的菜单列表

当学生单击列表中的任何项目时，相应的语法将添加到输入字段中。 当他们开始学习时，他们会点击，但当他们点击时，他们会学习并记住语法和方法。 后来他们没有点击，而是使用自动完成输入，却没有意识到已经学习了 api

从这个意义上说，Godot 的 Event Sheet 系统实现的主要目标是向非编码人员介绍 gdscript 和基本编程概念，而不会用任何语法使他们感到困惑 - 然后它将把 Godot 放在更多的学校向青少年教授编程。 随着他们的进步，他们将学习gdscript和godot的api，而不是construct2或game maker

我想我没有解释清楚...... :(

当我说线条时，我指的是可视化脚本，指的是连接节点的线条

构建和融合事件系统比 Godot 可视化脚本更直观、更容易、更快速地创建游戏

探索这种类型的替代方案会很好

@groud godot可视化脚本蓝图中的更高级别功能也可以编写为插件 - 但蓝图仍会增加我们所讨论的设计复杂性。
为当前蓝图系统创建和维护更高级别的功能所需的工作量要比从头开始编写更高级别的功能事件表功能和一个全新的事件表基础系统作为插件要少得多。

如果我们有一个事件表系统的低级别实现，那么为它创建和维护更高级别的操作/条件会容易得多。
我想即使是作为一个插件——我会首先制作一个只有低级访问和接口的基本事件表插件——它遵循 godot 的架构，而不用任何新方法使其膨胀。 然后可以在其他插件的顶部编写用于更高级别内容的单独可选插件。

资产存储库可以有一个用于可视化脚本插件的特殊部分

我为 7 到 17 岁的孩子教授编程。 目前，年轻的学生正在使用 Cosntruct，而年长的学生正在使用 Godot，但如果我所有的学生都可以使用 Godot，我将非常感谢孩子们从他们在这个游戏开发者世界的旅程开始就使用 Godot。

不仅是事件表系统。 这也是 plugins/behaviours/families 、 UIDs 和 objects 属性的工作方式。

例如，在 C2 中，在一个对象精灵中，我可以拥有所有游戏艺术，包括装饰、玩家、敌人等的静态/动画……所有这些都包括它们的碰撞等……并放置在布局中，选择开始时的帧并在对象上使用一个名为“type=”的实例变量来判断是否是敌人、玩家、对象、可破坏等……在事件中设置他的行为。 此外，对于每个精灵，您都有一些基本的绘画程序、动画师属性等......

在 Godot 中，我尝试了可视化脚本中的 Pong 示例，当我看到它使用一个精灵作为玩家，另一个精灵对象用于碰撞时，我想，什么！？ . C2 也有一个“猜测多边形形状”，只需单击一下，就可以使用 8 个点来碰撞你的精灵。 之后，您可以添加更多点并调整为更精确，或者使用一些插件或技巧来获得像素精度。

我的意思是，如果 godot 像在 C2 中那样应用事件表系统，但不遵循相同的理念以使其易于使用，那将是浪费时间，因为不可行。 好吧，在实际的 Godot 引擎中完成所有这些工作可能是一项非常疯狂的工作。

如果继续前进，也许他们应该向 RexRainbow、R0j0hound 等 C2 的大人物询问/雇用……他们知道什么是最好和最坏的事情，并制作一个非常好的事件表系统，而不会出现所有 C2/C3 错误. 但正如我所说，这将意味着大量的工作和金钱。

@matriax我认为您在这里不正确。
Godot 的架构比 Construct2 更灵活、更直接。
如前所述，对象配对是构造中的一个痛苦，除此之外，我们可以拥有比构造更清晰的事件顺序。 我们可以将事件表附加到任何节点 - 允许比构造更好的组织'2。
对于类型/族——在 godot 中，我们有“组”——godot 的组实现实际上比构造的更好。
将行为附加到对象 - 您可以仅附加子节点并将它们用作包含附加事件表的根父节点的行为。 这实际上又比 Construct 更好。
在 godot 中，您必须使碰撞形状节点成为发生碰撞的节点的子节点。 这不是火箭科学，实际上更适合教孩子编程

您要求的一些事情应该作为插件完成并且已经作为插件制作（例如猜测多边形形状）

在 godot 中实现一个符合 godot 当前架构的事件表系统将产生比构造更好的事件表系统/学习平台 - 因为 godot 允许在编码样式方面具有更大的灵活性并且具有更好的架构。 通过插件扩展具有更高级别功能的系统将使其像construct2's一样用户友好

让 godot 像 Construct 2 一样用户友好需要 imo 的共同努力——godot 的核心开发人员和它的社区。 社区需要通过事件表插件创建更高级别的功能。 请不要试图让 godot 与construct2 完全相同。 它在很多方面都更好。

@blurymind我并不是说应用与 C2 中相同的架构，这是没有意义的，我也不知道 Godot 已经拥有的所有东西，比如组、子节点等。你说。

我的意思是在 Godot 上添加一个事件表系统而不遵循相同的理念以像在 C2/C3 中那样简单的方式完成所有工作将是浪费时间。 就像我说的那样，为精灵/碰撞或所有游戏艺术设置一个对象，而不是为每个事物设置一个对象。

也许他们应该向社区询问有多少人在使用实际的可视化脚本，有多少人会更喜欢事件表系统，然后做出决定。

@matriax，您需要在做出此类声明之前学习 Godot :)

这里的提议是针对事件表，而不是针对construct2 的整个引擎副本。

了解这两种引擎——我坚信事件表可以以 godot 为中心的方式完成，它会使 godot 成为一个很好的工具，如果不是更好的工具，可以教年幼的孩子学习编程。

从这个意义上说，事件表实体将等于脚本文件 - 类似于游戏制作者中的 DND 所做的，引擎中的任何内容或其工作方式都不需要更改。 如果您想要其他construct2功能，您可以制作一些插件

即使作为插件实现 - godot 中的事件表除了创建另一个用于生成 gdscript 文件的接口之外什么也不做

@blurymind再说一遍，好吧，忘了。

@matriax反馈是个好主意。 你在这一点上是对的。
最好询问目标人群——不仅仅是互联网上的任何人。 目标群体可以是年轻的学生和教师——这实际上是事件表系统的完美目标。
老师们会非常了解他们的学生在努力解决什么问题，同时也会了解 Godot 和 Construct。 学生和非编码人员可以提供良好的反馈

如果您只是在此处的 godot 跟踪器上询问-您将获得大多数经验丰富的中级程序员-已经了解并喜欢 gdscript、引擎的 api 甚至 c++ 的人
他们会做出保护性反应——正如你在文章开头看到的那样——认为你提出的不是他们需要的和引擎需要的——自然是因为我们已经知道如何在 gdscript 中编写代码并看到更重要的目标发动机比这个。 确实有更重要的目标。
如果你幸运的话，他们中的一些人会在来到 godot 之前开始使用construct/game maker/clickteam fusion，并且会知道它对那些还不懂任何编程语言的人的价值在哪里。

有人提出了一个很好的观点，3d 艺术家喜欢蓝图，因为他们已经知道如何制作着色器。 这是一个很好的观点——3d 艺术家不是程序员——但仍然是一个学习了节点图系统概念的技术人员。

回到这里的价值——如果 Godot 也许在未来的某一天成为更多孩子的第一个引擎，那不是很好吗？
为什么不尝试在学校替换 Construct :) Scirra 开发人员现在太容易了。 看看他们如何吹嘘与学校合作
https://www.construct.net/gb/blogs/construct-official-blog-1/construct-3-a-year-in-review-947?utm_campaign=blog1postemailsub&utm_medium=email&utm_source=947&utm_term=txt4-read-laura_d% 2527s-post&utm_campaign=marketing&utm_source=sendgrid&utm_medium=email

在尝试将这个想法作为插件进行方面，我制作了一个 WIP 概念证明 gui。 目前它没有做任何事情——它只是为了弄清楚界面如何工作并与 godot 的架构相结合。 不确定如何拖动以随机播放单元格内的元素并缩进

如果godot中的richtextlabel节点可以使用内部的godot编辑器图标那就太酷了

当我有时间时，我将为条件/动作编辑器制作另一个模型 :)
动作/条件编辑器将是编辑单元/逻辑块的工具。 我正在考虑类似于 Construct2 的方法，使用 godot 的内部代码编辑器作为表达式编辑器。
也许以后可以添加一些辅助辅助工具-例如construct2或fusion中的辅助工具

一旦创建了界面，剩下的就是让它在场景中保存/存储数据并能够生成干净的 gdscript- 但我可能会遗漏一些东西

@blurymind很好，我喜欢这个概念。
也许添加动作和条件的按钮应该没有背景按钮，就像在构造 2 中一样

而且我认为将条件与动作分开会很好

我喜欢这样的结果。

这是一个非常整洁的模型。 一开始我并没有真正理解你在说什么。 现在真的很清楚......在编程和我们已经拥有的那种可视化脚本之间的中间步骤？

@DrZanuff感谢您的反馈
@Zireael07谢谢 :)
没错——这个工具可以帮助我们在使用这两种引擎来教授编程的学校中用 Godot 完全取代 Construct2。
在它下面只是一个用于生成 gdscript 文件的可视化界面——类似于 Game maker 2 中使用 DnD 的方式。我不要求对 godot 的优秀架构进行任何更改。
事件表可以是 Godot 中的可视化脚本选项，对于非编码人员（蓝图不是）和学习编程概念的幼儿来说是用户友好的 - 将它们轻松放入 gdscript

Godot 已经有很多元素可以使这项工作顺便说一句，但它不能与 Construct2 中的完全相同。 以戈多的方式，如果发生这种情况，它会在很多方面变得更好。 Construct2 的事件表允许一些非常糟糕的代码组织实践，并且有一些可怕的限制/怪癖。 实际上，我们可以制作比他们更好的事件表，它对用户友好并且可以更好地教授编程 - 没有怪癖。

正如我所看到的 - 很多工作都是在创建编辑事件表的界面 - 我有更多想法如何更好地利用 godot 的特权 - 但我需要一些时间来开发概念证明这解释了它。 有时候，一张照片比文字更有价值。 一个插件 - 不仅仅是一张图片

喜欢你在这方面的工作。 您是否愿意在您处理它时将其提供在回购协议中（如果您愿意）？ 想看看，戳一下，玩一玩。

@mhilbrunner当然可以-如果你们四处闲逛，我真的会喜欢它。 只是需要一些时间使它更美观。 :)

我正在将 gui 作为 gdscript 插件集成到 godot 的编辑器中——它的交互性还不够:)

当我让基本 GUI 以交互方式工作以传达设计理念时，将在 github 上发布它：) 今天我将事件表 gui 作为选项卡加载 - 从 sketchfab 插件中获得一些灵感：

也许应该从其他地方访问事件表？

将发布更多更新截图并最终链接到 github - 更新了我的第一篇文章，其中包含一些规划说明和其他事件表引擎的在线演示的链接

• 你们知道通过bbcode在富文本标签节点内显示godot节点图标的简单方法吗？
  在我之前的模型中，我使用了 [img] 标签 - 但这是一种非常糟糕的方法，因为它需要我下载 godot 编辑器使用的所有节点图标并将它们与插件一起存储

• 我也在努力弄清楚如何通过插件 api 注册新的事件表脚本类型资源

@blurymind非常好！ 现在它更具可读性。 我们需要考虑操作列表将如何显示给用户。

我喜欢旧 Construct Classic 的一件事是可以选择在不打开操作或条件的情况下编辑事件表中的值，但双击该值进行编辑：

如果有人想添加这个（通过插件、插件、gdnative 等自己添加），那么，没有伤害，没有犯规。否则，我同意可以改进可视化脚本，使其变得多余。 GDscript 很简单，真的很简单。并且可能比一些简陋的可视化脚本（甚至基于蓝图）更有用。如果有人需要构造，那么我说，鼓励他们继续使用构造。 Godot 不需要在其核心中模拟所有其他系统。让软件保持专注，不要因为注意力分散而成为“万事通，无所不能”。

@spyres取决于@reduz和
我个人认为我们可以完全用godot代替学校中的construct。
当前的蓝图系统不适用于此。 它比 gdscript 使用起来更复杂，而且如前所述——这不是向某人介绍编程范式的最佳方式——因为它有自己的一套规则。
这样做的目的不是要取代 gdscript 或当前的蓝图系统，而是相反，通过帮助孩子们来学习 gdscript。 这就是 yoyo 游戏如何使用他们的 DnD 可视化脚本系统逐步向非程序员介绍 Gml 顺便说一句。
我认为拥有一个对非程序员更容易访问并且更好地将它们转换为 gdscript 的可视化脚本系统没有任何害处。 你为什么？

我正在尝试将其作为一个插件，但在缺乏文档或 api 方面我遇到了一些限制。 我想注册一个新的脚本资源类型，并且我想在脚本选项卡中注入我的事件表编辑器 - 用于编辑 myscript.es 文件。
有谁知道如何做到这一点 - 或者有一个例子吗？
它有自己的选项卡是丑陋的 imo，并且不遵循编辑器的原始设计 - 我希望我的插件以与 godot 的设计无缝的方式集成。

@DrZanuff Godot 有一种方法可以列出节点中存在的所有方法，但我还不确定如何将它们过滤为操作或条件。 可能必须想出一个更以godot为中心的方式来做到这一点。 仍在探索它，并对想法持开放态度:)

无论如何，我们可能永远不会有一个功能齐全的插件。 这只是为了探索如何在这里以 godot 为中心的方式完成它的想法——至少现在是这样

视觉脚本不能（或不会）得到很大改进，或者年幼的孩子不能使用它，或者从构造中成长为 gdscript 的假设似乎真的有点愚蠢。 尤其是视觉脚本是相当新的。

如果针对非常年幼的孩子的解决方案_（我从未见过开发人员将其作为 Godot 的主要人群）_有那么大，让他们使用构造或其他一些专注于儿童的解决方案，然后通过 GDscript 继续进行实际编程他们准备好了。

如果您想将其创建为附加组件并支持该附加组件，那就欺负您。 但作为一些重复的东西，膨胀核心并（可能）浪费有限的官方开发时间与未来的支持、集成等，_不，谢谢。 _

@spyres您自己是开发人员吗？ 还是老师？ 你有没有在你自己的项目中使用过 Godot 的可视化脚本？ 如果是这样，如何改进它成为一个更好的教人们编程的工具？

@blurymind我认为你的想法很好。 另外，你似乎已经对它有相当深刻的认识。

但是，我认为“用 Godot 代替学校中的构造”并不是拥有此功能的正当理由。 我不记得 Godot 有取代 Unity、Unreal 等其他引擎的愿景。 Godot 并没有试图粉碎其他工具。 如果是为了提高生产力，我同意。

我也同意@spyres 的观点，即 Godot 不必针对教育领域。 如果 Godot 不适合作为编程（甚至游戏开发）教学工具，那就这样吧。 它从来没有想过要排在第一位。 但是，如果有人可以以某种方式使用/转换 godot 成为编程教学工具，我对此没有任何问题。

不过，我认为这个事件表是一个有趣的想法。

@blurymind我想你忘记了

@zaniar @ni-code 你是对的。 确实，我个人更感兴趣的是创建一种比我们当前的蓝图方法更高效、更清晰的可视化脚本工具——使用起来更愉快。 我不喜欢Construct2-所以我想把Godot变成它是不正确的。 正如我之前提到的 - 我发现它的设计和怪癖非常糟糕。 这就是为什么它让我如此沮丧，以至于找到事件表的唯一地方不如 Godot。

老实说，我认为即使改进了蓝图，它们也永远不会像事件表那样清晰和快速地构建——在这方面，事件表是一个经常被低估的快速原型设计的好工具。 但是由 Clickteam fusion 创建的标题应该自己说话。 有些人可能将其视为玩具 - 但对我来说，以这种方式构建游戏逻辑很有趣 :)

作为同时使用construct2和Fusion的人，我喜欢事件表方法，并且在godot的api中看到了一个漂亮的事件表系统候选者——没有激发它的引擎的缺陷。
Godot 的节点嵌套设计与 gdscript 对表达式的清晰性结合起来非常适合。
我并不指望它会在godot中实现，但我会在这里继续分享插件的进展，希望得到有用的反馈和对api的帮助。 这里的一些开发人员使用过 Construct2 并且非常了解 Godot，因此讨论中可能会产生好的想法。

实际上，我对事件表系统有一个想法，它将使我们比仅使用 gdscript 略胜一筹——即使对于有经验的用户也是如此。 它应该与 gdscript 一起使用，而不是代替 gdscript - 不要忘记

我期待不可避免的可视化脚本改进（因为它们完全集成/支持）比任何以“construct-lite”儿童为中心的插件更有用（并且可能更受欢迎）。

@spyres请保持语气文明。 你不需要告诉其他人他们的假设是“愚蠢的”，或者他们正在投资的潜在插件（免费！）工作将只是一个“以janky 构建-lite 小童为中心”的东西。

当然，人们可以随心所欲地度过他们的时间（我觉得这最终可能是无用的），尽管这可能不利于 Godot 的核心设计。

为了文明起见（尽管“以儿童为中心”正是 OP 在这里所要求的！）让我们将构造样式设计表描述为尴尬，而不是专注于 Godot 的核心人口统计，希望不会浪费核心开发人员的时间， 等等。

_当实际的构造引擎已经以稳健的方式提供了该功能时，为什么还要在 Godot 中重新创建构造

7 岁的儿童人口群体真的为这种重复而尖叫吗？

@mhilbrunner回复他的帖子感觉就像回复一个 7 岁的巨魔：D
他在这里点了我的大部分帖子——实际上所有点赞都是他的。
与他争论似乎没有意义，因为他实际上并没有回答问题——我确实问了他一些可以帮助我获得反馈的有效问题。 我得到的回报是一样的

如果有人滥用，github 是否有办法阻止他们发帖？

哇，虽然我确实质疑过一些想法，但我_从来没有_真正称呼过某人的名字。 _That_是相当辱骂我会说。

在 Godot 中复制构造的功能会提供什么，而呃……构造还没有很好地提供。

为了吸引 7 岁的孩子，将 Construct 的功能集（可能以较小的方式）复制到 godot 中是否有合法的好处？

为什么不直接使用构造？ 他们的设置（有些人似乎热衷于复制）真的那么缺乏吗？

是否有正当理由假设孩子一旦长大后就无法转向 gdscript 或可视化脚本？

@spyres您使用一般冒犯性的术语来描述使用事件表和事件表的人。
他们不是“小子”，系统也不是“笨拙”。 看在上帝的份上，请尊重那些社区。 这种精英主义态度从何而来？

Construct2 有很多非常有经验的 javascript 程序员——如果你不厌其烦地阅读我所写的内容并按照我提供的链接进行操作，那么这对你来说应该是显而易见的。 他们制作的一些插件将其与 babylon 和three.js 等3d 引擎集成在一起——所以是的——有经验的开发人员也喜欢使用事件表并用它来制作游戏。

Clickteam fusion 制作的游戏在 Steam、kickstarter 甚至应用商店的数量和收入方面远远超过 Godot 制作的游戏。 这是一个完全基于事件表的引擎，供 10-80 岁的人使用。 这是所有年龄段的混合体。 一些用户是电影制作人，另一些是艺术家——有工作的人花钱购买许可证、出口商等。 哎呀，到目前为止，我在他们的资产商店卖东西赚的钱比 godot 做的任何事情都多。
这里有一些例子——电影制作人 Alonso Martin 决定制作一款游戏：
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia
一群7岁做游戏
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game

看看这里
http://indiegames.clickteam.com/
那些七岁的孩子肯定知道怎么做游戏和赚钱诶
https://thinkgaming.com/app-sales-data/publisher/3107/scott-cawthon/

我将其作为更好的编程教学工具出售的角度不应成为这样错误标记它的理由。 随着更广泛的用户群体 - 你最终会有更多的人使用引擎制作游戏。 这不应该很明显吗？ 为什么这不明显：D

你需要我重复多少次我不是要 Construct2 的副本？ 就像您在没有实际阅读任何内容的情况下重复相同的信息。 我提议的是一个以 Godot 为中心的事件表，而不是construct2 中的一个副本

现在阅读您关于系统“janky”的帖子将如何激励我为 godot 制作免费插件？ 稍微考虑一下

哇！ 尽管转移球门柱...

让我澄清一下。

Construct 在它的工作上非常成功。 所以需要（？！）在一个完全不同的引擎中移植/复制其功能集（全部或部分）（没有明显的好处）让我逃脱了。

关于实际收益的问题保持不变，尽管有些人可能（莫名其妙地）认为它们“令人反感”。

将附加组件移植到完全不同的引擎上的建议是否会比使用构造更好？ 我们希望很多人在强大的解决方案（即构造）上使用某些东西（甚至通过附加组件）？ 我不信。

但是，嘿，为什么要停在那里？ 存在教孩子编程的优秀工具（超越构造）（例如Scratch 、 Styncl 、 code.org等）为什么不将它们也合并到 Godot 中！

或者也许不是...... ;-)

有没有人用过 Godot 的可视化脚本，而且看起来好到只使用 Godot 的可视化脚本？

@Zonacas我认为Godot的可视化脚本还不够成熟，但我可能错了。 请记住，此时 VS 仅发布了大约两个月。 :)

@Zonacas尝试查看不和谐服务器上的 VS 频道，我见过一两个自称是非程序员的喜欢它的人（但也有很多程序员说这对非程序员不好）。

大家好，我的概念证明插件有一个进展更新。

这是一个新鲜的 GIF 给你：

它所做的一些背景 - 基本上事件表是由单元格组成的。 一个单元格可以用于条件（getter/expressions）或动作（可以用 getter/expressions 提供的 setter）。
在 GUI 端，事件单元是通过富文本标签节点和从 gdscript 生成的 bbcode 创建的。 当你双击它时，richtextlabel 会变成一个包含实际 gdscript 表达式的编辑框节点。

因此，事件表单元格有 2 种模式：

• 编辑模式 - 可以使用 gdscript 输入的 textEdit 节点。
  唯一的区别是用户不需要输入 If/else/while - 如屏幕截图所示，这对父容器是上下文敏感的。 每一行都是一个新的条件，所以如果用户没有用“或”或其他东西开始这一行，解析器会自动知道一个新的行有“和”的借口

当点击离开时，切换到查看模式。

• 查看模式 - 富文本标签 - 切换到查看模式时，会从处于编辑模式的 gdscript 中解析 bbCode，并通过交互式富文本标签呈现。 除了具有交互性和易于更改之外，目标是以更清晰的方式呈现 gdscript 代码。 这意味着只显示节点的名称和图标（而不是整个路径），并在某些词很明显时去掉（例如 get_ 和 set_）。 由于每个可点击部分实际上都是一个 url 标签，例如，当将鼠标悬停在节点名称上时 - 用户可以获得一些信息，例如节点的完整路径。

关于添加新条件/操作菜单：
这就是为条件或操作创建新的 gdscript 代码行的原因。 它的优点在于它可以让您轻松浏览场景中的所有节点及其方法 - 它的工作方式与 gdscript 编辑器中自动完成的工作方式相反。 它显示了所有节点及其所有的 setter、getter 或这两种方法。 然后，您可以通过过滤器缩小到您想要的范围。
如果从条件单元格调用，此菜单仅显示 getter，如果从操作单元格调用，则显示 setter 和 getter 方法。

下一步要做的事情是：

• 我需要找到一种方法来拖动单元格 - 以便能够轻松更改事件顺序。
• 还在预览模式下复制和粘贴。
• 接下来，我必须创建一个表达式编辑器，当单击特定类型的预览模式单元格 url 时会弹出该编辑器
• 弄清楚如何处理占位符项目。 我想过发表评论，但不幸的是 godot 不支持内联评论： https :

这个想法正在演变成不仅仅是一种教学工具。 我想我可以为已经了解并喜欢 gdscript 的人提供一些真正节省时间的有用功能，但是我需要更多时间来开发这个功能，以便我可以向您介绍如何操作。

感谢大家的支持

一个插件的好主意。 但是正式维护两个可视化脚本系统会很痛苦，而且收效甚微。

XKCD:标准

我不明白为什么这不能是一个实际的插件/插件，而不仅仅是一个概念证明。 默认情况下，并非所有内容都必须与引擎捆绑在一起。 我的意思是，这不是开发 GDNative 的原因吗？

@Megalomaniak这是真的，相信我，如果我对 godot 的 api 有足够的了解，我会将其重写为 gdnative 插件。 但即使走到这一步，我也很挣扎，实际上我错过了一些关键元素，无法将它变成一个实际可用的工具。 我在这里提出了问题，但到目前为止，没有人真正告诉我任何答案或展示示例：

• 我们如何在 godot 编辑器中注册新的脚本资源类型并允许用户将其附加到任何节点？ 目前，插件是从场景的根目录和它的 hacky 运行的。
• 那么我们如何才能让 godot 打开我的事件表 gui - 与当前的蓝图系统一样集成
• 我们如何让 editText 节点表现得像 godot 的 gdscript 编辑器——启用语法着色和自动补全。 此外，我们如何给它自定义上下文？

对 API 了解非常低的人可以做到这一点。 那种东西不在文档中——也没有现有的例子。
我有设计理念，但还没有完成它的完整图片

到目前为止，我只能继续推动设计概念并了解更多有关 api 的信息，但不能坚定地保证这可以变成一个真正完全有效的插件。 到目前为止，人们似乎非常喜欢它

对于这样的事情，我更愿意尊重开发者的意愿：

https://godot.readthedocs.io/en/3.0/about/faq.html

我有一个好主意，可以让 Godot 变得更好。

你的想法肯定会被忽略。

让我们这样做，因为它会让戈多变得更好
让我们在 Godot 中执行此操作，因为另一个游戏引擎会执行此操作
让我们删除它，因为我认为它不需要
让我们去除杂乱和臃肿，让 Godot 看起来更漂亮
让我们为喜欢它的人添加一个替代工作流程

@spyres我实际上正在做这个，并在API上寻求其他godot用户的支持，了解我在文档中找不到的东西——试图为godot做出贡献。
你在这里做什么？

你是唯一一个在每篇文章中都翻阅并重复相同内容的人。 这很像巨魔所做的，你不同意吗？ 您在讨论设计理念时只是在跟踪对话

@blurymind一个人的“贡献”是另一个人（或引擎）的分心。 很抱歉，不同意见的概念（即使是那些他们认为重要到可以作为官方文档的一部分发布的开发人员）对您来说似乎如此令人反感。

祝你的插件好运。 :咧嘴笑:

@spyres但你真的做了什么吗？ 你有没有为 godot 创建过插件？ 你用戈多吗？

你为什么在这？ 你不是想为讨论做出贡献

@blurymind哇，不同的意见真的让你很困扰吗？ 多么为你难过。

@spyres这里的每个人都可以看到你的意见——你正在用它来发送垃圾邮件。 这里的每一个拇指都是你的。 它不是意见 - 它是垃圾邮件。 至少在设计和具体事情上挑剔？ 我之前问过你一些问题 - 你从来没有回答过任何问题

需要明确的是，我完全支持任何人利用他们的时间，但是他们希望创建这样的东西作为附加组件，可以被像我这样没有发现价值的人和平地忽略。

作为替代工作流实际上集成到 godot 核心中？ 呃，请不要。 我同意开发人员对这类事情的看法。

@spyres是的，你已经说过了。 向上滚动并再阅读 5 遍。 你们中的一个..但是很多次

@blurymind它似乎在某种程度上困扰着你？ 哇，其他意见等等。

我想_你_没有重复任何正确的事情吗？ （你是谁，你为什么在这里，为自己辩护 dagnabbit！）。 :咧嘴笑:

我猜开发人员写的那一点官方文档评论引起了一些消化不良吧？

是的，它超级暖心

@blurymind谢谢，到处拥抱！

我真的和你一起祝你好运，通过 gdnative 实现这一点，届时它将为那些想要这样非官方的东西的人提供（我怀疑很少有人）。

但是，如果您无法获得实现这一目标所需的信息和帮助，也许是时候重新评估这种替代语言的可用性对您的真正意义了。

@spyres请停止发送垃圾邮件。 我不需要这些电子邮件和通知。 你表达了你的意见，这很好，但你不需要一直重复。

@mhilbrunner如果我的不同意见让你如此困扰，请点击我的头像，然后选择“阻止用户”。 任何因阅读我的评论而引起的痛苦都会立即停止。 :笑脸:

@spyres我在之前的文章中已经注意到这个插件旨在使用 gdscript，而不是作为替代语言。 是的，似乎没有人在审核这个跟踪器

那么你越早完成，我们就会越快乐，对吧？ 我相信它对于一些真正想要它的人来说会很棒，就像许多其他附加组件一样。 很难看到这会给你带来太多不必要的痛苦，所以请照顾好自己，不要让缺乏信息/进展让你失望。 我敢肯定，如果有压倒性的公众支持，您很快就会获得所需的所有信息/帮助。

用智者的话来说，“别担心，要快乐”。 :咧嘴笑:

或者“这一切都很有趣和游戏，直到有人把他们的眼睛射出来！” （嗯，等等，我不认为那是我正在寻找的报价......）

哇。 老实说，这太棒了！

当我第一次阅读您的帖子时，我同意了，但有点担心会引起巨大的争论，但是当您出现并表明您并非全都吠叫并且不咬人并且实际上开始开发插件时，我印象深刻。

我喜欢与 GDScript 的交互，因为这是 gamemaker studio 中的一个重要功能（可视化和适当脚本的可互换性），这在基于节点的系统中实际上是不可行的。

一旦完成，它将帮助很多人

在过去的 6 年里，我一直是 Construct 用户，我可以肯定地说这是实现最快和最简单的可视化脚本的最佳方式。

好主意！

这将非常有用。 我等不及要发布了！

绝妙的主意，与 SnailOn 合作。

1. 他是天才。
2. 他使用 Godot 大约 3 年。
3. 他从 TGF 开始就使用 Clickteam 引擎
4. 理想的候选人。

@boruok我从早期就一直是 snailon yt 频道的粉丝。 😄 他的教程很久以前就帮助我学习了融合。 他有github账号吗？ 我很想在一些事情上了解他的想法。

顺便说一句，我必须承认，我倾向于使用更像 Fusion 的点击菜单，而不是 Construct2 用来决定如何填充单元格的菜单。 更新 1 中显示的帮助菜单肯定受到 Clickteam 设计的影响。 在这个插件中，您将看到我不是在创建任何引擎的复本，而是借用一些想法，这些想法会更好地用于事件表的 godotesque 方法。 还有一点 Game maker - 视觉脚本可以无缝切换到实际脚本的方式 - 更高级的用户可能会喜欢

感谢大家关注此插件的进展。 最初的反应是非常积极的
这极大地激励了我继续推动这个想法，同时也努力保持它的简单和优雅。

如果没有内联注释，很难在 gdscript 和 visualscript 之间轻松切换，但我有一些关于如何克服这一点并进行试验的想法 - 所以我正在研究那个 atm。
我需要一些方法在 gdscript 中定义一个空占位符，其中需要一个表达式。
由于表达式会返回一个类型的值，所以我想到了只使用 godot 中的值转换方法来标记占位符：
float() ## this will turn into a bbcode item that expects an expression resulting in a float
但这可能有点难看，因为它会在最终生成的 gdscript 中生成许多不必要的变量类型转换方法

如果 godot 可以进行内联注释，我将能够将它们解析为从 gdscript 创建 bbcode 的方法。 这将允许我为它提供一些额外的信息

最好的方法就是让我该死的 gdscript 到 bbcode 解析器方法更智能——这就是我现在想要做的

@blurymind我不知道 git-account。 顺便说一句，他又打开了视频。 我已经通过 youtube 和 facebook 向他发送了几个下午。 让我们希望他会出现在这里。

@blurymind我 100% 支持这个！
（提前抱歉英语）

如果我们仔细查看一下关于页面的

开发人员感兴趣（例如）：

您使用该软件的经验和您遇到的问题（我们更关心这一点，而不是如何改进它的想法）。
您希望看到实现的功能，因为您的项目需要它们。
为了学习软件而难以理解的概念。
您希望优化的工作流程部分。
您错过了清晰的教程或文档未达到标准的部分。

牢记这一点：

• 如果您知道如何真正编码，则只能使用当前的可视化脚本。 并且变得比硬代码更快更混乱。 这是在帮谁？ 除非您有非常具体的技术背景，否则蓝图也没有那么有用。

• 更高级别的事件表确实可以很好地工作。 正如上述所有应用程序的成功所见。 如果做得好，对于非编码人员来说，它们确实更容易掌握和使用。

• 为什么 Godot 会迎合非编码人员？
  我看到许多从事专业项目的人对此有很多用途。
  在许多小型、中型和大型项目中，团队的一部分将负责编码，而另一部分则负责自己的事情。 音乐和声音、视觉/动画/SFX/UI、游戏设计、作家等...
  有时甚至是一个人的团队，或者像这个电影制作人这样的行业之外的人在做一个非常成功的游戏。
  有些人甚至出于许多不同的原因想做编程但不想编码。
  例如，阅读障碍等问题使代码成为一场噩梦，但通过事件表等更直观的方法仍然可以进行编程。
  大多数时候，这些人在制作游戏所需的东西时，除了编码之外还有其他事情要做。
  事件表将允许图形师、声音或游戏设计师超级轻松地测试或实施他的工作，而无需深入研究原始代码。
  它还允许一些超级快速的原型设计，以测试一个人的概念证明。 扔一堆库存图片，点击这里和那里，你可以检查你的想法现在是否有趣。 即使是优秀的程序员和大牌/工作室也使用最简单的东西在项目开始时进行迭代。
  关于这里的所有内容的更多反馈和讨论，我非常同意 OP。
  （Github 不是最好的反馈地方，来这里的人通常都深入编码并且看不到需要，尽管实际上是少数。）

• 结论：对于大量从事专业项目的严肃成年人来说，为人们提供简单而有效的工具来与 Godot 交互将是许多不同层面的天赐之物。
  （不仅仅是孩子和学校，即使它确实也会帮助他们。）

• 顺便说一句，如果您想查看更多示例，还有另一个名为

祝贺你已经完成了工作，尽管有某些反应，但你仍然保持积极和积极，并相信你的想法。 我也确认它确实非常有用，并且会为我解决重大问题。

@TheGoklayeh谢谢你的鼓励。 我确切地知道你的意思。 如前所述，成功的独立 Clickteam fusion 制作的游戏数量大大超过了成功的独立 Godot 制作的游戏。
正在发布的游戏、Steam 和移动设备上的销售数量以及 Kickstarter 游戏达到了他们的目标。
这应该足以证明专业艺术家和设计师使用它 - 而不仅仅是“孩子”

关于 Gdevelop 的新 IDE 的话题，我认为它很棒，但功能不完整。 主要开发人员做出的一项明智之举是将 ide 移植到 javascript - 使非 c++ 开发人员可以很容易地为它做出贡献。 到目前为止，我实际上一直在为它做出一些小修复——只是为了玩耍和学习。 这个周末我将尝试采取一些步骤将 piskel 集成到其中 😃 - 如果一切正常，它可能会获得一个内置的像素编辑器。
主要开发者最近合并了另一个开发者的贡献——增加了对龙骨的支持。 如果您愿意，请尝试来自 github 的最新版本——而不是在线演示。 它有货
https://github.com/4ian/GD/releases

我还在这个插件上取得了缓慢的进展。 在我可以进一步使用它之前，需要重构一些东西。

也许在这里获得所有也使用 godot 的 fusion 用户和construct2 用户是个好主意。 向他们展示这个线程并让他们获得有关设计的反馈。
Snailon 还没有联系我——但是是的——他是一位非常有经验的程序员，在事件表方面。 我不知道他也是一个godot用户。

这看起来太棒了！感谢您开发/推动这个，blurymind。
我已经做了 23 年左右的游戏开发，基本上什么都试过了——所有流行的游戏开发工具/引擎、程序语言等等。我更喜欢一天结束时的事件表，因为它可以让我完成游戏。 :)
以自上而下的方式将其划分为条件和动作，使其比任何其他系统都更加有序和简洁。由于我更注重视觉，拥有垂直/水平的刚性结构使我可以轻松地通过程序/事件。
其他需要意大利面条式连接的视觉脚本非常混乱和分散注意力——视觉细节分散在嘈杂的美学中，这打破了视觉思维的人们的注意力（假设视觉脚本的目标是相同的人）。
活动单对我来说是最好的。我已经用了 23 年，使用了所有东西——blitzbasic、gamesfactory、unity、c++、javascript 等等，我很确定——我喜欢事件表！

只是想插话，蓝图/节点样式编辑极难组织/避免“意大利面条代码”。 对于任何认为它与 Clickteam/Construct/GDevelop 风格事件相同的人，我很抱歉，但它们完全不同，事件表客观上更好（游戏本质上是基于规则的 IF/THEN，你可以更轻松地过渡从事件到代码，但总的来说，事件总比编写游戏逻辑要快）。

我确信在某些时候基于节点的编辑很方便，但如果将基于事件的编辑包含在基本的 Godot 可视化脚本中，它将很快成为首选选项。

@bigelod @prominentdetail感谢您提供更多反馈，说明是什么让事件表如此出色 - 不仅适用于那些正在学习编码的人 - 也适用于更有经验的程序员。

我认为你是完全正确的。 就像@prominentdetail一样，我从 fusion 中的事件表开始，然后经历了许多不同的引擎。 学习了python，然后是gdscript，然后是javascript。 尽管如此，事件表还是把我作为原型游戏的首选方式吸引了我——它们为游戏逻辑增加了额外的清晰度

我还注意到事件表游戏引擎社区 atm 的趋势，godot 可以真正利用它来扩大其用户群：

• 使用事件表的开发者社区渴望使用事件表的 3d 引擎。 clickteam fusion 社区都试图将其集成为插件（萤火虫）和 Construct（尝试了许多插件） - 但这些插件没有提供任何 3d 场景编辑功能 - 它们是让事件表与 3d 引擎一起使用的黑客 - 放在 2d 上引擎编辑器不是为 3d 游戏设计的。 您只能在其中构建带有事件逻辑的 3d 场景 - 放置对象、设置材质等会很痛苦。
• 学习和经验丰富的程序员仍然喜欢事件表，并且确实将它们用于原型设计 - 而不仅仅是教学。
• 许多独立团队已经成功地使用（并且仍在使用）事件表来制作成功的游戏——kicktarter、steam 和其他平台——但由于第一点，很少有人是 3d 项目

现在让它作为 godot 中的插件工作很棘手，因为引擎中有一些我不确定如何访问的东西。 我目前的实现既快速又混乱，除了演示如何完成 gui 的部分内容之外没有做任何事情。 我会尽量把它变成一个更漂亮的状态，并将它贴在这里

顺便说一句，我设法将 Piskel 捆绑并与 Gdevelop 集成。 在过去的几周里，这让我很忙。 如果你愿意，你可以试一试：）
我也一直在研究 gdevelop 中的事件表是如何完成的

@blurymind好吧，我只想说我在这里试图忽略这篇文章，因为我不喜欢两个可视化脚本的想法。

但这终于足够了，我认为终于到了开始一些讨论的时候了。 我相信您一定使用过文档来构建 GUI。 Mockup 是个不错的工作，我想问问有没有 repo 我可以稍微看一下代码。 可能可以做一些事情来使它更像 EventSystem，并且更可行。

我正计划在当前的可视化脚本系统上做一些工作。 当我遇到 GDevelop 并喜欢它时，我就来这里询问。 经过一个小时的阅读，结论很清楚，我们需要找到一个中间立场。

维护两个不同的可视化脚本系统是不可能的，其中一个必须死掉。 但包括我在内的任何人都不想与蓝图节点结构分道扬镳。
但是这个 EventSystem 太美味了（至少对于基本的原型设计来说）不能吃。

我希望 VisualScripting 更像是一种原型设计工具。 有限的功能是否真的可以增加用户群并不重要。
如果在此之前没有人注意到这一点，那么更多的用户也等于更多的捐赠，那么应该考虑这一点。

但是 Blueprints 是一个行业级别的工具，因此它有它的用途，并且可能为 Godot 带来更大的鱼，这对 Godot 也很重要。 我说可能也不太了解。

所以问题很简单，怎么办？ - 两者都选是不可能的。
但是混合体可能会让戈多更受欢迎。
正如您在两种可视化脚本风格方面的经验至少比我多。（我更像是一名编码人员而不是艺术家，所以喜欢编写自己的方式）为什么不尝试提出解决方案。

这可能会带来更多的人，而不仅仅是 EventSystem 所能带来的。 并且保持节点系统存活也将是一个很好的举措。

那么，如果不能实现中间立场怎么办。 有些东西会死掉。 不管它是什么。

就我个人而言，我可能会投票支持 Blueprints，因为我以前有过使用它的经验，并且我希望将 Unreal 与更大的鱼进行比较。
但只是为了比较，我在 15 分钟内拿起了 GDevelop。 GDScript 在不同的日子里不到几个小时，Blueprint 肯定是 GDScript 的两倍。
虽然它也显示了我作为程序员的经验水平。

我只是无法决定。 在这里看到。

1. 团结：4011
2. 虚幻：316
3. 游戏厂商：274
4. 构造：223
5. 戈多：75
   _从 Reduz 的推文中列出 Global Jam 中每个引擎的游戏数量。_

我想要戈多在上面。 所以希望一些 VS 的爱能帮助实现这一目标。
但是 Unreal + Godot + GameMaker + Construct 仍然没有成功。 但至少让它成为第二名。

我很困惑为 Godot 的可视化脚本的未来计划什么。 在当前系统上等待或盲目地尝试改进已损坏的东西是无济于事的。

“在某种程度上，EventSystem 类似于使用 Scratch 进行编程。蓝图是完全独特的，但它比 EventSystem 更强大，导致 EventSystems 在深度上更加混乱，可读性更差。”

什么？？ 如果您尝试使用 Construct 的事件系统，情况正好相反，特别是包括其他事件表和使用组。

与一般的 EventSystem 相比，最好的节点系统永远是代码意大利面条。

@bigelod是的，不应该那样说。 我以为是相似的。 我在学习 EventSystems 时花了 2 个小时写了这条评论。 对不起，这将解决它。

是的，我最清楚的是蓝图，拥有这样的东西真是太棒了，但是事件系统增加了更多对初学者友好的东西。 并且还有助于学习编程。

@swarnimarun多年前，我在同一个跟踪器上向 godot 开发人员提交了事件表。 但我当时做的不是很好，蓝图已经有了更多的支持，因为很多 godot 用户也是前 unity/Unreal 用户。 蓝图已经赢了，现在在 Godot 中。

现在很多真正来自clickteam fusion、游戏制作者和constructor等引擎的用户都支持事件表，非常不喜欢使用蓝图。 他们会说与您所说的相反的内容，并解释已经解释过的内容 - 为什么与事件表甚至脚本相比，蓝图会令人困惑。 我也已经这样做了。

即使在查看其他可视化编程引擎论坛时，您也可以看到对任何新蓝图系统引擎的负面反应：
https://rpgmaker.net/forums/topics/23922/?post=857285#post857285

现在归根结底，我看不出两个系统都不能存在的原因。 它们可以一起工作 - 蓝图可以与 gdscript 节点一起工作的方式。

事实上，在一个理想的世界中，您会希望使用细化逻辑和蓝图来构建事件表并快速原型化，以便在状态机中组织它。
为什么？ 因为这两种系统各有利弊。

当您开始使用节点制作简单的表达式时，Godot 的蓝图很快就会变得一团糟。 在事件表或脚本中，同样的表达方式会更加清晰。

开源项目是民主的——社区越支持一个想法，它就越有可能成为现实。 但这并不意味着必须扼杀另一个想法。 这两种想法都被广泛喜欢或不喜欢。

这里的每个人都必须意识到，使用事件表和蓝图——他们将从头开始编程。 最重要的是系统允许他们构建逻辑的清晰程度。 使用蓝图，执行顺序可能会变得一团糟，使调试变得困难。 与事件表相比，它还需要更多的点击和设置步骤。 这是我在这里主要向专业开发人员和视觉编程爱好者介绍的内容。 但也不要忘记这是个人品味的问题。 我不会试图让蓝图开发者成为这个的粉丝。 相反，我会指出许多可视化编程开发人员不喜欢蓝图，而更喜欢事件表。

事件表可以使用 gdscript 作为其表达式，这样实际上可以帮助那些来自事件表类型引擎的人快速学习它

可能事件系统可以用作自定义节点创建工具。

只是想就某事提出一个观点-老实说，我不认为事件表仅用于原型。 我认为偶数表仅用于原型设计的思维方式的部分问题是因为许多使用它们的工具都推动了这样一种概念，即它可以更容易地在不知道如何编程的情况下创建东西。 任何实际使用事件表相当长的时间的人都知道，这是一种真正的编程方式，需要了解基本的编程概念，并且您可以使用它创建完全完整且功能丰富的游戏。
部分问题是使用事件表的工具试图淡化它的技术性质，以试图吸引业余爱好者和没有太多开发游戏经验的人。 这实际上损害了事件表的形象，并使其他有更多使用其他工具经验的人看起来不那么有能力。 还有很多人使用事件表，他们不确定他们在做什么，因为他们被告知他们不需要对编程有任何理解——所以人们用它创建的例子并不能很好地代表它。 这并不意味着没有很好的例子。 只是它已经形成了一定的先入之见。

..混合可能是打破这种偏见的一种方式——允许人们以一种可能具有更严肃语气的新方式来解释它。 您也许有机会解决以前系统的问题，并使混合系统看起来比它所受启发的系统更好。

@prominentdetail提出了一个很好的观点。
为了补充它，我只想说：
Godot 有机会成为第一个支持事件表的适当 3D 游戏引擎。 根据定义，这将把它提升到目前所有其他事件表引擎之上。
正如我之前提到的，这在 Clickteam fusion 和 Construct 中都曾尝试过——作为插件，甚至在游戏制作者中也是如此。 而且那里很笨拙，因为这些引擎的编辑器的 3d 功能为零。

Clickteam fusion - 萤火虫引擎：
http://clickstore.clickteam.com/firefly
https://store.steampowered.com/app/267655/Firefly/
它在 Steam 上被淘汰了——因为它是一个糟糕的错误插件

构造2 - q3d
https://www.scirra.com/tutorials/9456/building-your-first-3d-game-with-the-q3d-plugin

看看在没有 3d 场景编辑器的情况下设置一个简单的 3d 场景有多麻烦
https://youtu.be/VUGsTdBpRCQ?t=6m17s

恕我直言，混合动力听起来是一种很好的方式来解决两者的缺点。

方法应该是创建一个事件表原型来展示其价值并获得反馈。

在对系统进行了大约一个多小时的测试后，它看起来确实很强大。 有趣的是，它可能与 GDscript 一样多的编程知识来创建大多数东西，而不是添加了辅助功能的运动或最基本的东西。

我相信那些害怕尝试编程的人可能是唯一在 GDScript 存在的情况下可能需要它的人。

Eventsheet 可以很容易地成为学习编程的工具，尤其是使用 Godot API。 由于 Godot 已经有许多相同的辅助函数。 所以实现 EventSheet 可能实际上可以使用 GDScript。
因为您基本上可以创建一个系统，将 EventSheet 转换为 GDScript 并存储在单独的隐藏文件夹中，该文件夹在编译时更新并可供引擎使用。 至少这就是我想出来的。 这可能是最简单的解决方案。

虽然我可以看到它不能代替可视化脚本/蓝图，这很好，但它并不是很直观，主要是列中的代码，使事情更容易理解。

我不明白为什么它会以这种方式进行宣传，除非有人具备使用 EventSheet 进行编程的基本知识可能会更麻烦。

目前在等待可视化脚本方面的修复时，如果我有时间，我可能会尝试用它来创建一些东西。 尝试实现 EventSheet 的基本版本可能很有趣（将帮助我学习 Godot API）。 如果我取得任何进展，请确保在此处更新。

事件表与 gdscript/脚本语言有何不同？

对于新手（比编码更有吸引力的东西）：

• 有一些逻辑的视觉表示 - 使用图标、颜色和尽可能少的文本
• 左列中描述了条件，右列中描述了动作——在编码中，条件和动作都在一个列中——使得一些人在阅读另一个人的逻辑时更难区分两者。
• 方法不是一长串的文本，而是显示为简单的单词-用英语并在可能的情况下去除语法符号-消除语法的噪音使其阅读起来更加清晰
• Intelisense/autocompletion 向用户展示了整个 API——因此他们可以看到所有可用的 setter 或 getter，并过滤掉他们想要的那些——与它在编码 IDE 中的工作方式相反——在你开始输入和整个 api 后自动完​​成显示仍然隐藏在引擎的文档中。 它还具有查找事物的视觉线索（图标）。 它直接显示返回或预期的变量类型
• 分组逻辑使您可以创建自己的文件夹，您可以折叠/取消折叠并四处移动。 当您组织代码并想要隐藏您未处理的部分时，折叠您决定应该是可折叠的逻辑块的能力非常好。

对于更有经验的用户：

• 您可以通过拖放填充的单元格来非常轻松地更改事件执行的顺序。 这是什么意思？ 当在 ide 中编码时，我们可以通过 ctrl+x 和 ctrl+v 来完成。 在事件表系统中，您只需将逻辑行或单元格从一行拖放到另一行即可重新排序。
• 已经建立的逻辑在视觉上比代码更容易找到和阅读——再次由于视觉线索和左右列的布局——在颜色编码的顶部。当您对某些东西进行原型设计时，这真的很棒
• 默认情况下，事件表可以自动为用户处理节点路径 - 因此，在将事件表放在一起时，您不必通过确定它们相对于某物的路径来访问其他节点（父节点或子节点）。 您仍然可以选择代码灵活性，但系统会为您处理节点不会动态更改其父子关系的情况。
  访问节点所需要做的就是从帮助菜单中选择它。 这加快了速度
• 它仍然非常像 gdscript - 因为所有表达式都在 gdscript 中，但它为您提供了一些额外的生产力优势。 我认为，如果做得好，这是 gdscript 用户会喜欢的东西——无论是否体验过。

我想如果我必须总结一下好处：
对于新手来说 - 代码乍一看更清晰，更有吸引力，因为引擎的 api 如何呈现给他们，并且他们放下的逻辑有视觉提示（节点图标）

对于更有经验的人 - 您仍然可以在所有表​​达式字段中编写 gdscript，但现在您还可以让流程的某些部分更快（例如无需通过键入代码导航到其他节点），能够拖动逻辑以更改其执行订单或要求（无需剪切和粘贴）

我有点偏离了一些 javascript 的东西，如果其他人试一试，我会喜欢它的 :) 但会回到它

我同意@mhilbrunner 的观点，它应该是它自己的系统，但如果可以将它与蓝图系统结合起来，那就太好了——就像你可以在项目中将 gdscript 与蓝图结合起来一样

@blurymind
所以，你说你正在开发这样的插件？
回购的名称是什么？ 它已经在你的github上了？

我可以确认 eventshee 更容易理解，我在大约 10 到 11 岁的时候学会了它，并且英语很差（我不是母语人士），而我花了更多的时间和英语知识来学习如何代码。

有时它可能比编写代码更快，当你习惯它时，你可以尽可能快地点击。

我看到的唯一缺点是当你必须学习传统代码时你会变得懒惰。

我开始研究这个，但你的代码似乎比我的更高级，恐怕我帮不上忙，但我还是想试试

@Elmapul我认为他的回购不会有太大帮助。
如果你有这样的想法，实际上编码要快得多，那么这意味着你并不是一个真正使用过 Python 等语言的优秀程序员。
尽管 EventSheet 对初学者更有帮助和宽容，但就是这样。

只是想我会提到一些东西-因为这些年来我涉足了各种工具..
我首先是一名艺术家，所以我大部分时间都在创作艺术。 这是我投入最多时间的事情，也是我的思想已得到加强以支持的事情。 有很多情况下，我会在编码之外进行长时间的休息，而我会做其他艺术性的事情，比如自由职业者等。
作为一名艺术家，这使得在任何需要特定语法模式的特定游戏开发工具上保持敏锐变得很困难——您必须始终如一地执行这些模式以保持掌握。
因此，作为艺术家 - 预计艺术家很可能不会与基于语法的编码风格具有相同的一致性和优先级。
每当您从编程中休假时，Eventsheets 是一种解决这个问题的方法（因为作为艺术家，您不会花连续的时间来编写代码）.. Eventsheets 更容易跳回，因为它对您在编码中熟悉的语法结构和模式需要更少的记忆。
正因为如此，我喜欢事件表，因为我可以更有效率，而不必不断地重新学习。我只是在用我的思想处理更多的艺术任务和项目后重新开始——这在精神上更容易流动。

..所以基本上，我想强调的是，是的——如果你把所有的时间都花在那个职业上，并建立起有利于这种思维方式的心智能力，编码会更快。 他们只是简单地输入它然后去-他们并没有真正避免这种生活方式/行为。 对于其他人来说，这永远不会是一个现实的选择，因为他们将自己的一生都奉献给了其他工作，这些工作加强了不同的行为和实践模式。
所以是的..你可以就像..哦，随便吧-做你真糟糕..太糟糕了，你没有把时间花在成为一名全职程序员等等。这会疏远很多永远不会充实的人-时间程序员或技术头脑。 当然，这是开发人员这样做的权利..
但是，如果您想邀请其他类型的人并让更多人实际使用该工具，无论他们的技术潜力如何，那么它有助于对事物更加开放并尝试帮助那些无法匹配您首选系统/工作流程的人， 等等..
我一直在回复，因为我觉得事件表对开发游戏的实际进展有很大帮助，不会出现一个人离开和回来时发生的退出效应等。像我这样的人放弃放弃的可能性较小，然后回到他/她的正常工作岗位。 所以最后，我实际上完成了更多，即使它需要更长的时间或者在技术层面上稍微不那么令人印象深刻。

@prominentdetail出于所有意图和目的，Visual Scripting 可以做到这一点，因此一旦实现更加完整，就无需担心，它将解决记住语法的大部分艺术问题。

我在离开编码后使用了蓝图，在几分钟内它仍然感觉自然而恰当。 所以我认为大多数人都会接受它。

不管您知道什么语言，具有正确分组的事件和操作选项的可视化脚本将比您输入非常短的变量名称和数据类型所花费的时间更快。

也就是说，如果事件被映射到键盘快捷键，那么再次“输入”确实会更快，但仍然是事件/动作比从头开始的标准代码更快（因为动作和条件通常代表一个完整的复杂功能，预制且灵活，适用于大多数用途）。

我的论点仍然是事件表比学习更容易
蓝图和更快的设置。

此外，它更擅长过渡
新人到实际的脚本语言。

如果设计得好，事件表系统可以和写作一样快
脚本。 如果你看一下我的模型 gif——它和打字很相似
使用帮助菜单过滤时具有自动完成功能的代码。

无论如何，我仍在想办法做到这一点，谢天谢地 godot
gdscript 将获得类型化的脚本，这更合适
为我的事件表生成 bbcode。
例如其中一个细节
事件表系统中的表达式字段的最大优点是它为您提供了一个
清楚地指示它期望的变量类型，甚至亮起
有效时为绿色（参见 clickteam fusion）。
我目前正在尝试弄清楚如何做一个可以
使用 gdscript 但也使用我制作的帮助菜单。 同样，这只是在试验它如何工作。 这远非任何可用的atm ..

2018 年 5 月 30 日星期三 22:59 Daven Bigelow， notifications@ github.com 写道：

不管你知道什么语言，正确的可视化脚本
分组事件和操作选项将比所花费的时间更快
除非您输入非常短的变量名称和数据类型。

也就是说，如果事件被映射到键盘快捷键，那么它会
确实可以更快地再次“输入”，但仍然是事件/动作
从头开始比标准代码更快（因为动作和条件通常
代表一个完整的复杂功能，预制且灵活，适用于大多数用途）。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/godotengine/godot/issues/17795#issuecomment-393333602 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AGMbVT30aPs63RYwxtFqDTHWVqclenRBks5t3xZTgaJpZM4S8wyr
.

@blurymind我确实建议使用 C++ 来做，使用该方法会更适合并且更完整。 即使是几周前开始使用 C++ 的我，现在也能够使用它，创建错误修复和新功能。 所以这并不难，可能有点难。 我仍然需要使用stackoverflow。

但是，如果您正在寻找保留和使用 GDScript 并且只是为其他人创建一个原型以将其转换为完整的工具，我认为您应该在此处共享存储库，无论多么不完整。
我很乐意提供帮助。 我真的很喜欢 EventSystem 的想法。 并且 VisualScripting 目前已被破坏，所以我无能为力。

问题是事件系统实现起来可能很麻烦，在 Godot 中，您可能会将其实现为脚本语言。 但这不是它的意图，它是事件管理器，因此它应该是全局的，或者应该能够单独处理整个场景，然后使用组将工作分成多个部分。
所有这些都是可能的，实施起来也不应该是一个问题。

@swarnimarun是否有一个 hello world 模块可以创建新的 ui 或更改现有的？
你能推荐任何对你有帮助的好的入门教程吗？

无论如何，我现在正在考虑将帮助菜单生成的 gdscript 语法更改为键入的 gdscript：
https://github.com/godotengine/godot/pull/19264
然后将其转换为呈现交互式事件表单元格界面的 bbcode

我制作了这个流程图来解释它目前是如何工作的
https://www.draw.io/#Hblurymind %2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml

@blurymind我建议不要拍摄教程，而是向实际实践或其他开发人员学习。
没有人真正帮助过我。 我也不需要太多帮助。 我很擅长捡东西，所以一切都很好。 与经验丰富的开发人员相比，我才刚刚开始。

而且我相信您正在使用 GDScript 进行所有编程，或者您正在使用 C++。
因为没有模块可以让你在默认情况下或刚开始时做任何事情。 你必须从已经存在的东西中学习。 并创建自己的。

如果您使用的是 GDScript，并且如果您使用的是 C++，则转换为 Typed GDScript 应该很简单，并且需要很少的移植。 据我所知，PR 应该随时合并。 它已经过审查，看起来还不错。 还没试过，但真的很兴奋。

现在让我猜猜，您可能正在使用带有 get_method_list() 和 get_property_list() 的 GDScript。 但我建议你也使用信号和组，信号是 Godot 事件触发机制。 我真的不知道 EventSystem 但如果你想在 Godot 中创建类似的东西。 确保充分利用 Godot。

最后，如果您需要帮助，请在 Twitter 或 Discord 上给我发消息。 我现在有几天空闲。

@swarnimarun我正在使用 gdscript 编写插件，其中已经有一些信号用于触发事件之类的事情。
是的，我也使用 get_method_list() 和 get_property_list() 来呈现帮助菜单

你在 twitter 和 discord 上的处理方式相同吗？

现在我的计划是在 gdscript 中制作 gui 原型，因为它是我比 c++ 更了解的。
我在 javascrit 方面也有一些经验，但这在这里没有多大帮助

键入的 gdscript 是帮助菜单将为表达式模式生成的内容 - 它更适合转换为 bbcode 以呈现带有富文本标签的 ui

@blurymind那很好。 我在上面的gif中没有看到。 所以我假设了一些事情。

至于我在 Discord 上的手柄是 Swarnim。 我想你已经知道我的推特了。

@blurymind - 出色的工作。 我刚刚开始学习 C++，因为与 GDScript 相比，Godot 的性能有所提高（快 3 到 4 倍，具体取决于您的指标 - 请参阅bunnymark ）。 如果可能的话，我建议直接购买黄金并为此使用 C++，即使这意味着在工作中学习——这将是值得的。 给我几个星期的时间来感受一下 C++，如果你愿意，我也愿意提供帮助。

@colludium 3 到 4 倍的速度不值得学习 C++ 的努力。 如果您想学习制作更优化的游戏，请改为学习 C#（随着它在 Godot 中的成熟会变得更快）。 而且现在类型化的 GDScript 正在出现，它将使 GDScript 比以前更快。 接近 C# 是相信。

C ++是一种痛苦。 相信我。 指针和引用以及编译代码只不过是痛苦。 除非你想成为一家大公司的游戏开发者，或者在大学里学习它，或者你非常聪明，完全了解 GDScript，或者作为一名程序员处于专业水平。

如果您仍然想继续尝试学习动态创建 GDScript 代码，因为我们知道为一种语言创建导出系统是一件痛苦的事情，因此直接生成 GDScript 代码将使整个事情变得容易得多。
作为额外的奖励，您将能够查看查看代码并帮助新手更快地学习编码。

@blurymind想问一下您使用哪个版本的 EventSystem 作为基础，因为我想将系统的原型创建为 C++ 模块，所以我希望至少在基础级别上使其与您的同步。

@swarnimarun - 感谢您的建议：C++。 我只是一个从 JavaScript 过来的业余程序员，所以我正在寻找一种最小痛苦/最大性能的转换。 我不知道计划中的改进以使 GDScript 更快 - 很高兴知道。 现在我有一个难题 - C# 或者更容易学习的 GDScript ......

@colludium假设无论您发现什么更容易，看到您的背景是 Javascript，我推荐 GDScript，因为它也具有动态类型，并且与传入的静态类型一起，它应该是完美的伴侣。
让我告诉你，如果你曾经认为 C++ 是一种你应该学习的语言，那就去看看某个论坛的 Rust vs C++ 页面吧。

@swarnimarun我正在使用
这是我将项目添加到的测试存储库
https://github.com/blurymind/Godot-eventSheetPrototype
每个人都可以自由地 fork 或做 pull requests 👍

请随时开始编写 C++ 模块。 到目前为止，我所拥有的只是接口的核心构建块——逻辑单元容器。

bbcode 解析器（它只使用正则表达式）和帮助菜单渲染可能对你最有用，尽管我个人正在考虑改变它们的工作方式——它们在我工作和其他项目之间的空闲时间被一起抨击. 事情是一个混乱的ATM代码明智的，所以有更多经验丰富的程序员对我有很大帮助。

其余的只是为了截图目的而放置的静态界面

要做的一件非常重要的事情是创建某种可编辑的字典来跟踪场景中的所有节点及其路径，因此，而不是静态节点路径 - 帮助菜单应该生成使用字典中的路径的 gdscript自动更新它们，如果一个节点被用户删除并且事件表的逻辑没有找到它 - 它可以重新链接

无论如何，如果你有什么东西，请分享——即使它是基本的。 我将尝试学习更多 C++ 并与您一起将其编写为一个模块 :)

@blurymind最后！ 非常清楚地理解 Godot Engine 3.x 可视化脚本是无用的（对初学者来说太复杂，对专家来说没用）。

GDevelop 事件系统太棒了！ 它非常有用，特别是对于创建完整的 2D 游戏模板，然后通过 GDScript 添加更多高级功能。 这将使 Godot 游戏引擎更具吸引力、更受欢迎和更广泛！

我真诚地喜欢 Godot 引擎，但为移动设备制作 2D 游戏并不是最简单和最直接的解决方案。 它可以通过简化的系统/事件系统提供更多功能）。 Godot 有一个出色的动画编辑器，它非常好用且功能强大，如果我想创建一个 2D 平台游戏而无需编写数千行代码（我觉得创建一个基本的超级NES 的样式模板马里奥兄弟）。

我发现@blurymind的想法是太棒了！ Godot 社区发展迅速，我对此感到高兴。 我毫不怀疑事件系统将在下一个版本中实现。 可视化脚本（我重复一遍）目前绝对没用（我什至找不到教程，而且从我在网上看到的内容中也没有人使用它）。

问候，并感谢您出色的工作！

@XenonCoder你最后提出了一个有趣的观点

可视化脚本（我重复一遍）目前绝对没用（我什至找不到教程，而且从我在网上看到的内容中也没有人使用它）。

这是一个很好的例子，说明某些东西天生难以使用，然后将用作自我实现的预言来解释为什么不应该这样做（例如：“看！没有人想要可视化脚本！”），而不是承认它根本不是以吸引人或初学者友好的方式完成的。

就像是半礼物一样，因为没有后续，确实是没用的。

对于没有很好地记录或提供示例的引擎的任何添加也是如此。

@bigelod完全同意你的看法。 我很高兴你没有误解我的意图，而且你完全理解我的意思。

Godot 游戏引擎简直太棒了！ 它具有令人难以置信的潜力。 做2D游戏，第一！ 多年来，我一直在尝试所有现有的游戏引擎和框架，我可以绝对肯定地说 Godot 是一个承诺伟大事物的项目。

例如，新的 Visual Shader 看起来非常好，并承诺为未来带来美好的事物。 我做了一些测试，我非常喜欢它作为一个想法。 但是要实现视频游戏的逻辑，Visual Scripting 是一个陷阱。

我们需要教程、文档，最重要的是构建 3、GDevelop、Game Maker Studio 2 风格的简化系统。最初是作为主要实现 2D 游戏的插件，将来会改进并正式实施。 我意识到这不是一件容易的事，只是一个想法，让 Godot 游戏引擎成为爱好者、学生和视频游戏专业人士的理想解决方案。

谢谢你们。

围绕游戏引擎形成了商店。 这变得很正常 - 在商业基础上编写附加组件。 对于构造包括。 所有最后重要的 C2 插件都是商业的。 这不仅是由于市场的形成，也是由于产品的复杂性，需要大量的时间来测试和修复兼容性错误。
我觉得…… Godot 是另外一个小众，如果胡安不写，不支持简化编程的应用，别人不太可能把这个工作搞到最后。

我是伴随着 Klik 'n Play、The Games Factory 和 Multimedia Fusion 一起长大的，现在我也在使用 Construct 2。 使用事件表编写可视化脚本与使用相互连接的蓝图式状态机节点完全不同，对于习惯于事件表的人来说，它是最简单、最有效的编程方式。 我很乐意欢迎在 GoDot 中使用事件表编写脚本的方式。

我在 gdscript、文档和插件 api 中遇到了一些限制，这些限制使我无法完全执行我将其作为插件的愿景。 即使我让它进入功能状态 - 它也可能有限制。

可以立即帮助我到达那里的一件事是可选的类型化 gdscript - 这就是为什么我停止工作直到它在 godot 中。 现在已经合并了——只要有时间，我就会重新开始研究这个作为概念证明插件。

这个想法是事件表的生成的 gdscript 将被键入。 然后，键入的数据将为事件表 gui 提供额外的上下文数据，以了解预期的参数类型。

如果有兴趣将此作为适当的 c++ 模块或 gdnative 插件 - 每个人都可以自由尝试实现它。

看看有多少人想要它，没有什么比让它成为 godot 的一部分更让我高兴的了——或者至少作为 godot 的一部分工作。

不幸的是，我目前有一份全职工作占用了我大部分时间:(
抱歉更新慢

为了加入这个讨论，我想在这里向大家展示一个使用基于节点连接的可视化编程方法的可视化脚本引擎的精彩示例，该方法目前未能针对目标人群
https://youtu.be/b8GZ21YCh50?t=4m12s
它有点类似于https://www.reddit.com/r/unrealengine/comments/4nt0up/need_help_debugging_this_blueprint/

注意 Gamesfromscratch 提供的替代方案

在这个设计方案中，我想避免的一件事是预定义超出 godot 中节点已经执行的行为 - 同时创建大量选项卡和 gui。
godot 事件表应该与 gdscript 代码完全一样 - 只是以更具触觉/视觉的方式
它不应该尝试在 godot 之上构建一个易于使用的游戏引擎，而是让 godot 更易于访问和更快地组合在一起

也许使用可视化脚本即使触摸屏也可以访问？

事实上，事件表样式的可视化脚本非常适合触摸
屏幕

2018 年 8 月 1 日星期三 06:46 Elmapul， notifications @github.com 写道：

也许使用可视化脚本即使触摸屏也可以访问？

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/godotengine/godot/issues/17795#issuecomment-409456475 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AGMbVdqoa3AdMNfiM986iwIpNeqzqjVLks5uMUCvgaJpZM4S8wyr
.

@blurymind如果插件系统需要为此改进，请打开一个问题，它已经被修改，因为其他插件需要特别的东西。

这是个好主意！ 我从来没有真正理解过这些蓝图，但基于事件的方法是众所周知的，尤其是在模组社区，比如魔兽争霸 III 世界编辑器。

示例屏幕：


类别和干净的触发器列表看起来很棒，至少对我来说是这样。 比第一篇文章的屏幕更容易感知它们。

它与您所说的基本相同，但可以将条件添加为动作并在其中嵌套进一步的动作。

@Wiadomy
这张图片太小了，看不到/读到任何东西

@Elmapul
抱歉，出了点问题。 更新。

@Elmapul虽然我的概念插件还不能进行嵌套，但我提议的事件表包括嵌套。 gdevelop 和construct 都支持行嵌套——如果你想的话，你现在就可以试试:)

@blurymind终于开始研究事件表的实现，你知道有什么资源可以详细讨论它的实现吗，比如研究论文或关于它的工作和实现的文章？
这将是一个很大的帮助。 让我开始为 Godot 设计事件表系统。
因为使用 Construct 或 GDevelop 方法是不准确的，因为 Godot 的工作方式完全不同，我们有一些称为信号的东西，它们也需要集成，然后还有更多。

如果您需要一般信息，这里有一些关于构造事件表的信息： https :
不同的公司实施他们的事件表彼此有点不同，所以他们每个人都有自己的怪癖。
也许我可以创建一个视频来总结构造方法的各个部分（因为这可能是目前最好的方法）。我不知道有任何研究论文——尽管这会很有趣。

@prominentdetail感谢您的链接，看来我将不得不看看如何使事件更易于使用，如构造系统。
我的第一个想法是拥有类似于@blurymind的插件的

那么你们认为事件系统应该有一个不同的 API 来增加易用性还是只是一个 GDScript 的包装器。

@swarnimarun真的最好的办法是使用引擎一段时间，然后考虑如何以一种更 godot 的方式来完成。 Construct classic 和 gdevelop 是 imo 的绝佳示例。

从我的角度来看，godot 中的信号就像内置函数事件一样。 在 godot 中连接信号已经是可见的 :)

从事件表设置信号只是帮助菜单中可用的一个操作 - 在引擎盖下它只是一个 setter 方法。 所以它与 gdscript 相同。

如果节点包含内置方法，则应该在单击“添加内置功能”时获得的菜单中可用

我强烈认为我们应该保持简单并成为类型化gdscript 的包装器，但如果那不可能或不实用 - 可能是不同的 API。 值得研究当前在 godot 中实现的可视化脚本是如何作为抽象工作的。

如果您想知道如何在构造中制作自定义函数，这里是他们文档的链接
https://www.scirra.com/tutorials/823/creating-function
:)

@blurymind将其作为 GDScript 的包装器实际上要容易得多，工作量也要少得多，但事实是 Event Sheet 中的许多功能将变得更加乏味，至少我是这么理解的。
所以我想我会在开始时保持不变，然后在需要时添加一些东西。

@swarnimarun感谢您抽出时间尝试一下

我认为最大的问题是，VisualScript 与您可以用来编写 Godot 脚本的所有其他语言一样，试图尽可能接近 GDscript 的功能，包括函数、变量、信号和其他所有内容。 您无法使用事件表系统来实现这一点，因为您会失去很多功能。 （我知道这是可能的，但它会很快变得臃肿）

@Jummit，除非你完全可以，尝试 Construct 2。它不会比标准代码更臃肿。

它可以具有GDscript的所有功能吗？ 那我们还在等什么？ 让我们在 Godot 中获取事件表！

@Jummit Godot以“节点”的形式拥有您想要的所有功能

godot 中的“节点”类似于construct2 中的“行为”
在construct2 中的平台行为就像一个不那么强大的kintematicbody2d 节点:)
您不必从头开始编写所有脚本。

更酷的是，您可以将这些节点嵌套在父子关系中，而行为被限制为像模块一样附加到单个游戏对象。

我坚信带有内置事件表功能和一些来自社区的附加插件的 godot 可以成为比construct2或3更快的原型引擎。
它有很多尚未开发的潜力。

C2 中原型制作的速度很大程度上取决于单元格的交互性——它们可以用热键拖动、复制和更改，包括条件对象，而下拉列表几乎完全消除了错误。

@swarnimarun ，我创建了各种构造物的通用概述： https : ioz3gHtA-Lg
它基本上适合那些不太熟悉构造的人来感受它。 由于我没有计划好所有事情，因此我可能忽略了很多事情，但它可能会提供一些基本的理解。 我可能应该制作一些我实际上在其中进行更多开发的视频，以展示它的工作流程方面，而不是漫无边际地谈论各种事情。 如果您想了解或探索任何内容，请告诉我。

这对我来说太丑了。 我的意思是，视频中的脚本。

@Wiadomy使用起来比该视频中的要好得多。 最后的事件表总是比任何基于节点的系统看起来更干净、更易读

@Wiadomy ，由于屏幕录制，我不得不使用一台显示器并保持文本大小相对较大。 Construct 格式化文本，这样如果您输入一个长的连续表达式，某些内容可能会由于屏幕空间而变得混乱。
为了解决其中的一些问题，您可以缩小文本并使用另一个监视器来腾出一些空间来更好地列出事件。
我也可以将表达式拆分一下以使其更整洁，但这是我的一个较旧的项目，也更具实验性。
此外，您熟悉事件表结构中的视觉提示和模式，因此更容易跟踪事件中的所有各个部分。 就能够适应任何项目并使工作流程变得非常快速而言，拥有这样的标准结构非常有用。

这个项目现在死了吗？

@Amr512我不认为它已经死了。 肯定有很多愿望将这个功能带到 godot 中。
@reduz最近甚至在 twitter 上对
https://twitter.com/reduzio/status/1085206844275081218

虽然我已经有一段时间没有在插件上工作了，但我决定真正开始为 gdevelop 本身做贡献——以便更多地了解它的事件表是如何编程的——并帮助它成为付费的更好替代品选项。
https://github.com/4ian/GDevelop/

一些大学已经开始拿起gdevelop教授编程课程
https://github.com/4ian/GDevelop/issues/882

我的 buggy godot 插件目前仅用于演示目的，需要大量工作才能发挥作用。 当然，任何人都可以自由地分叉它并尝试进一步推动它。
我的插件目前缺少的一件大事是事件行的可排序树 gui 元素。 还没有将事件表实际呈现到 gdscript 的功能，也没有具有语法自动完成和着色的适当表达式文本编辑器（想法是使用标准 gdscript 进行语法）。 它缺少许多可以制作事件表的关键元素，但主要目标是展示如何将事件表与 gdscript 结合使用以实现表达式语法。 我认为这两者对于原型游戏来说是一个非常强大的组合——即使对于有经验的开发者来说也是如此

@blurymind我在您的项目上留下了一张票（Godot 3.1beta3 上的错误）。
我非常喜欢这个主意。

偶然发现这个问题，我完全不知道这个东西已经在其他引擎/框架中常用，所以我不得不自己写，看起来很相似，你不觉得吗？ 👀

规则 = 事件
事件表 = 方案

之前的实现确实使用了相当“低级”的属性检查和相应的动作，但我认为这种系统实际上更适合通过扩展条件/动作基础脚本来定义游戏“构建块”，这些脚本更“高级”。抽象层次”。 所以这实际上就是我首先选择“规则”术语的原因。

您必须已经建立了游戏玩法和游戏框架才能充分利用它，因此它不能提供无需编码即可编写游戏的开箱即用体验，但实际上以一种允许的方式对其进行了补充您可以以多种方式组合现有功能并有效地组织它，只需使用您的普通 GDScript 编写具有不同条件和操作的新规则。

是的，允许玩家通过改装创建自己的游戏模式/任务/挑战是使用这种系统的另一个原因。

@Xrayez你能分享 git repo 吗？ 我认为你是对的，我的实现过于精细，但 gdscript 和 godot 的 api 的工作原理是正确的。
同样，仅通过查看屏幕截图，我认为您错过了重点-应该只有两列，而不是三列。 左=条件，右=动作。 此外，您应该能够在单元格之间拖放事件，还可以拖放行并嵌套它们。 要构建它，我们需要使用可排序的树。 玩一下 gdevelop 和construct，您会更好地了解是什么让这些事件表如此出色

也许我的实现可以被视为类似于DSL 的东西，所以这就是差异可能出现的地方。 许多规则只是针对特定游戏要求定制的功能的沙盒实现。 本质上，条件和动作只是继承了这些小脚本以及必须在子类中实现的方法：

class_name SchemeCondition extends Node

func is_met(object): # override
    return true

class_name SchemeAction extends Node

func perform(object): # override
    pass

规则只是这些条件和动作的集合，并根据是否满足所有或任何条件来执行，实际上并没有什么花哨的。

我知道贡献和实现事物的人喜欢编码，并不是所有人都看到了无编码编程的吸引力，但实际上还有许多人对此感兴趣。

Construct、Gdevelop、Stencyl、Game Maker、Playmaker、Bolt、Fungus for Unity、Unreal 中的 Blueprints、CryEngine 中的 Flow Graph 和 Schematyc 等...

正在为非编码人员制作和使用许多工具。 多亏了这些，才能制作出很多好游戏。
例如，空洞骑士与组织者一起完成。

你甚至有像Dreams这样的东西发出相当大的噪音。

这种工具会带来很多吸引力和可访问性，因此会给 Godot 带来新的人。

我最近在 gdevelop 中实现了一种通过这样的下拉菜单向其事件表添加新指令的方法

我认为这对 godot 很有效。

您使用richtextlabel 渲染每个单元格，这些单元格嵌套在左右列中，然后是一行的子级。 行由可排序的树管理。 每行包含实际的 gdscript，解释器将其呈现为简单的简短描述，带有缩略图和可点击区域以输入表达式。
这实际上是游戏制作者所做的。 他们的可视化编程数据被存储为实际的 gml。

当我开始将其作为 gdscript 扩展时，我发现的棘手部分是执行表达式字段。 我们如何将代码编辑器放在输入字段中并让它为我们自动完成？ 我们如何给它完成和验证上下文？ 如果没有经过验证的自动完成表达式字段，这将是死路一条。

我们拥有在 godot 中构建它的所有 UI 部分，但实际上我们没有一个经验丰富的开发人员在上面做任何事情。 到目前为止我还没有看到任何工作

无论如何，如果我的 c++ 知识更好，我会尝试一下 :) 但我知道 javascript，所以我的贡献转到 gdevelop

希望在 godot 中看到基于事件的解决方案。 我过去尝试过 godot，但我无法适应它的工作流程。 如果我要开发游戏，我的头脑更适合事件表。

我现在是一名程序员，甚至开始涉足引擎开发。 但我仍然可以非常自信地为活动表担保。

Construct 2 实际上是我第一次接触到许多基本的编程概念，通过我在高中时上过的一门课。 我觉得它极大地简化并加快了我的学习过程——无论是具体的引擎还是一般的编程——同时也足够接近实际的代码，以至于我在从事件表的过渡中并没有完全迷失方向到常规的旧文本脚本。 虽然我不能 100% 确定这一点，但我真的不认为我可以在相同程度上获得这些好处，如果它是意大利面条式的可视化脚本。

但我同意维护两个不同的可视化脚本系统可能是个坏主意。 也就是说，我认为我们不应该仅仅因为它是我们已经拥有的而坚持当前的系统。 我认为我们真的应该考虑切换到另一个系统，如果数据允许的话。 也就是说，我认为我们应该尝试更好地了解事件表系统与我们当前的系统相比更容易接近多少。 可视化脚本的目标应该是让引擎对不熟悉或不熟悉常规脚本的人更友好。 一个可靠的可视化脚本系统可能会对 Godot 的平易近人产生巨大影响，并且可能意味着获得更多人的支持和采用，否则他们不会考虑 Godot。

实际上，我最初离开 Construct 2 的主要原因仅仅是因为我想进入 3D。 我最终尝试了 Unity、Unreal、Godot 和 Amazon Lumberyard，最终选择了 Godot，几乎只是因为它打开和使用起来感觉更快捷，而且导入过程感觉更好。 但如果 Godot 有事件表式系统，我可能会立即默认使用 Godot。 诚然，现在对我个人而言，这真的没有什么不同，但同样，这是为了让 Godot 对非程序员（即大部分新的/有抱负的游戏开发者）尽可能友好。

我还没有阅读现在隐藏的 112 篇文章，所以如果我重复或遗漏了任何内容，我深表歉意，但我完全有兴趣对这个想法进行原型设计，或者帮助测试和考虑它。

我认为我们真的应该考虑切换到另一个系统，如果数据允许的话。 也就是说，我认为我们应该尝试更好地了解事件表系统与我们当前的系统相比更容易接近多少。

当前可视化脚本系统的维护人员已经很少。 我认为在我们的一生中永远不会完成一次完整的转换：slightly_smiling_face：

当前可视化脚本系统的维护人员已经很少。 我认为在我们的一生中永远不会完成一次完整的转换🙂

好吧，假设我们首先获得了事件表的工作原型，那么代码已经基本完成，这只是我们是否要切换到该系统的问题，对吧？

我也从 Construct 2 开始，发现事件表非常适合解决 2
问题：

• 像任何可视化脚本一样，您可以公开任何
  module/plugin/add-on/function，这对于学习新代码非常有用。
  视觉节点很快就变成了意大利面条代码（我是一个搅拌机的人，
  我知道合成器和着色器中的意大利面条）。
• 事件表就像是对 Rest API 的招摇，你从有据可查的开始
  填充事件表下拉菜单的代码，你会得到一个干净的 GUI
  使用您的代码的方式，您可以扩展变得混乱，并且，您可以
  从中生成代码（来自Construct2的JS），因此我的问题是：我们可以
  从中生成代码？

如果是，我认为应该优先考虑事件表，以便于使用
大家和优化的低级代码生成。
如果 Godot 可用于将 python/C#/... API 转换为一组干净的
事件，然后是用户构建事件，然后 Godot 从中生成代码，你是
解决一个非常困难的用户问题：学习如何从一个简单的 UI 编写代码。

我知道事件表不能解决所有问题，但至少你可以编码 500
像您在电子表格中进行的活动，而不会迷失在视觉中
链接无处不在。

2020 年 4 月 8 日星期三晚上 7:44，Jay [email protected]写道：

当前可视化脚本的维护人员已经很少
系统。 我认为在我们的系统中永远不会完成一个完整的转换
一生🙂

好吧，假设我们得到了事件表的工作原型，那么代码
大部分已经完成了，这只是一个问题，我们是否
想切换到那个，对吧？

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看
https://github.com/godotengine/godot/issues/17795#issuecomment-611096608 ，
或退订
https://github.com/notifications/unsubscribe-auth/AAAP6LM4PU6RYLO5NK5IL23RLSZWHANCNFSM4EXTBSVQ
.

我开始使用 Construct 2 并最终转向使用 JavaScript 开发插件，因此事件表在我心中占有一席之地。 对于初学者来说，它们既简单又直观，其中大部分的魔力来自每个类（插件）的可用方法（动作和条件）的简单可视化。 老实说，现在 VSCode 中的 GDScript 也一样好，完整的智能感知和自动完成功能让生活变得轻而易举。 虽然 2 年前我是这个想法的忠实拥护者，但我现在改变了主意。 我宁愿 Godot 开发英雄将他们的时间和精力集中在添加其他引擎改进上。

我们可以从中生成代码吗？

我必须更多地研究它，但老实说，我认为这样做很简单，事实上这可能是最好的方法。 也就是说，我认为处理事件表样式的最佳方法是基本上让它充当常规 gdscript 文件的图形前端。 在事件表编辑器中执行的操作只是编辑 gdscript 文件。 例如，在事件表编辑器中将一个块从一个地方移动到另一个地方基本上就像在 gdscript 文件中进行虚拟剪切+粘贴一样。 并且可以在脚本编辑器或事件表编辑器中查看和编辑任何 gdscript 文件。 从可用性的角度和实现的角度来看，这似乎是最好的方法。 那就是说我对引擎开发还不是很了解，所以我可能弄错了。

我宁愿 Godot 开发英雄将他们的时间和精力集中在添加其他引擎改进上。

我非常同意。 我认为解决这个问题的理想方法是任何有兴趣尝试一起制作工作原型的人，然后社区可以从那里尝试找出是否值得将其作为主要的可视化脚本系统。 在做出决定或至少接近做出决定之前，我不会要求任何关于这个想法的主要开发时间。

我也没有足够的 Gdscript 或 Godot。
但是我作为 VS Code 扩展开发的东西也在以这种广泛的方式进行
（https://github.com/j2l/blocklight）。
通过玩代码和视觉来直观地理解代码
链接变量和结果（大多数可视脚本中的节点或颜色
在我的扩展中）是许多人缺少的基石。
实际上，当我们学完代码时，我们就理解了代码，而我们应该
在获取所有块之前查看变量和块的链接
代码。
编码前设计:)

2020 年 4 月 8 日星期三晚上 8:08，Jay [email protected]写道：

我们可以从中生成代码吗？

我必须更多地研究它，但老实说，我认为它会很漂亮
这样做很简单，实际上这可能是最好的方法。 那是，
我认为处理事件表样式的最佳方法是基本上
让它充当常规 gdscript 文件的图形前端。 行动
在事件表编辑器中获取的内容只需编辑 gdscript 文件。 移动
在事件表编辑器中从一个地方到另一个地方的块基本上会
在引擎盖下就像对 gdscript 文件的虚拟剪切+粘贴一样。 和
任何 gdscript 文件都可以在脚本编辑器或
事件表编辑器。 这似乎是最好的方法，两者都来自
可用性的角度和实现的角度。 那说我是
对引擎开发还不是很了解，所以我可能弄错了。

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看
https://github.com/godotengine/godot/issues/17795#issuecomment-611108712 ,
或退订
https://github.com/notifications/unsubscribe-auth/AAAP6LN7GFGSBDZ537XXA6DRLS4Q5ANCNFSM4EXTBSVQ
.

我喜欢它会生成一个常规的 Gdscript 文件的想法。 真的很适合学习

当我开始制作游戏时，Klik & Play 的事件系统对我来说是一种了解编程逻辑的好方法，我仍然喜欢回到它。

我喜欢它会生成一个常规的 Gdscript 文件的想法。 真的很适合学习

当我开始制作游戏时，Klik & Play 的事件系统对我来说是一种了解编程逻辑的好方法，我仍然喜欢回到它。

我认为这可能是它相对于当前意大利面条系统的最大优势之一——由于它的设计，它将使人们更容易学习编程和 gdscript/godot 的 api。

这里的一些人评论说——但为什么要这么做——它与演示文稿中的脚本太相似了。
我对此的回答是——确切地说。 你学意大利面，你就剩下意大利面。 您学习了事件表，您将通过查看它生成的内容并使用这些表达式字段来了解 gdscript。

它将教您执行顺序以及如何阅读代码。

查看在游戏制作工具中转换为 GML 的作用
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changeing_dnd.html

真的很有趣的blurymind！ 我有同样的想法，我完全支持这一点。
我仍在为 Clickteam Fusion 2.5 进行扩展，但我想在 Fusion 中添加的所有内容都在 Godot 中。
我只需要在 Godot 中再添加一个抽象层（事件表），以使开发更容易。
我没有阅读整个线程，但从我的角度来看，Godot 中的可视化脚本和其他游戏引擎中的事件表之间的主要区别在于，可视化脚本“只是”代码的可视化视图，而事件表是具有简化视图的代码。 它更具人类可读性，在一行中分解需要几行代码的事情，并且信号/插槽链接是自动完成的。
实际上，将一些模板（预定义场景）添加到抽象 CF2.5 内置对象并仍然使用 GDScript 将为我完成大部分工作，但事件表肯定会让我在 Godot 中比在 CF2.5 中更高效现在。

真的很有趣的blurymind！ 我有同样的想法，我完全支持这一点。
我仍在为 Clickteam Fusion 2.5 进行扩展，但我想在 Fusion 中添加的所有内容都在 Godot 中。
我只需要在 Godot 中再添加一个抽象层（事件表），以使开发更容易。
我没有阅读整个线程，但从我的角度来看，Godot 中的可视化脚本和其他游戏引擎中的事件表之间的主要区别在于，可视化脚本“只是”代码的可视化视图，而事件表是具有简化视图的代码。 它更具人类可读性，在一行中分解需要几行代码的事情，并且信号/插槽链接是自动完成的。
实际上，将一些模板（预定义场景）添加到抽象 CF2.5 内置对象并仍然使用 GDScript 将为我完成大部分工作，但事件表肯定会让我在 Godot 中比在 CF2.5 中更高效现在。

我以前用过CF，它被称为多媒体融合，作为一个不会说英语的孩子，它很容易学习，并且在使用它之后，你可以非常快，这取决于你在做什么它可以比打字更快。
构造和 CF 是一个好的可视化脚本的参考（gdevelop 正在到达那里）

谢谢
我支持这个绝妙的主意
他们说构造 2 将退休！
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

我想知道是否可以与construct 2的开发人员协商，以便将事件系统开源，并在godot、unity等中使用它。
在未使用的货架上忽略构建2个事件系统是一种损失

谢谢
我支持这个绝妙的主意
他们说构造 2 将退休！
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

我想知道是否可以与construct 2的开发人员协商，以便将事件系统开源，并在godot、unity等中使用它。
在未使用的货架上忽略构建2个事件系统是一种损失

我怀疑我们是否可以在 godot 上使用来自construct2 的任何代码——它们是完全不同的代码库。

开源替代方案的最佳选择是转向 gdevelop
https://github.com/4ian/GDevelop

此问题单可能很快就会关闭，因此如果对 godot 中的此事件表有任何兴趣 - 我们可能很快不得不将其移至其他地方:)（或 gdevelop）

此问题单可能很快就会关闭，因此如果对 godot 中的此事件表有任何兴趣 - 我们可能很快不得不将其移至其他地方:)

什么？ 为什么？

@TheGoklayeh它可能已关闭，因为我们正在将功能提案迁移到godot-proposals 。

也就是说， @blurymind可以编辑第一个帖子以匹配提案模板。 然后，我们可以将此问题移至提案存储库。

我们真的需要一个使用事件表的 3d 引擎。

谢谢
我支持这个绝妙的主意
他们说构造 2 将退休！
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

我想知道是否可以与construct 2的开发人员协商，以便将事件系统开源，并在godot、unity等中使用它。
在未使用的货架上忽略构建2个事件系统是一种损失

那可能会毁了他们的生意。 另外还有clickteam。

谢谢
我支持这个绝妙的主意
他们说构造 2 将退休！
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
我想知道是否可以与construct 2的开发人员协商，以便将事件系统开源，并在godot、unity等中使用它。
在未使用的货架上忽略构建2个事件系统是一种损失

那可能会毁了他们的生意。 另外还有clickteam。

如果有什么让他们丧命——clickteam 将是由于他们的软件缺乏更新（最后一次是在 2019 年），Scirra 将迫使他们的用户切换到软件租用许可证，迫使他们每年支付或获得被锁在外面。 两家公司都有缺陷，他们的社区无法控制软件发生的事情。 这就是开源大放异彩的地方

@TheGoklayeh它可能已关闭，因为我们正在将功能提案迁移到godot-proposals 。

也就是说， @blurymind可以编辑第一个帖子以匹配提案模板。 然后，我们可以将此问题移至提案存储库。

有人可以代替我这样做吗？ :)
我有点失去希望这个功能能够原生地到达 godot（而不是扩展）。 意大利面条式的方法赢得了 godot 用户和开发人员的青睐

@blurymind如果您不再支持此提案，那么我认为最好关闭它。 然后，对使用事件表方法感兴趣的其他人可以在godot-proposals上打开一个新

尽管如此，这个帖子还是包含了很多有价值的讨论，所以无论如何都要感谢 :slightly_smiling_face:

我觉得这个提议很傻:)
但是我们可以用construct 3引擎创建事件系统吗？！
我认为游戏可以生成代码并通过node.js将它们以文本文件的形式发送到godot引擎

这太荒谬了..但我认为构造 3 足以制作事件系统
此刻这总比没有好

是的，希望至少我们设法在 godot 中就这样的系统达成了一个想法，它相对于当前的视觉编码系统的优势以及对使用它的其他引擎的看法

老实说，我很喜欢 GDevelop 是如何做到的，但是 Godot 做事件脚本并不是我现在（这些天）所支持的。
我尝试过一次实现它，我意识到 Godot 有一个非常精细/低级的 API，可以直接从可视化脚本系统中公开。
包括当前的可视化脚本系统以及为什么我希望它具有自定义抽象层但仍然很健壮。
为事件脚本编写这样的实现非常困难，除非您使用多种 DSL，例如子事件脚本语言，每种语言都用于引擎的特定部分。

一个简单易用的通用可视化脚本系统很难实现，这就是我认为的“独角兽项目”。
因为泛化的增加很可能导致所述系统的复杂性更大的增加。

我计划将 Visual Scripting 逐渐朝着可以为引擎的所有部分提供专用接口的方向发展。
想象一下，每种类型的原始复杂节点都有不同的编辑方式，就像在蓝图中一样，有一个表达式节点。
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/MathNode/index.html

但要明确一点，我并不反对事件脚本，我希望看到有人提出一个可以涵盖 Godot 的某些特定系统的提案，以及它为什么有用以及如何有用。 就我个人而言，我发现它非常适合对行为进行编程，GDevelop 是如何做到的。
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/events-based-behaviors

我不会用它来编写一个合适的游戏，但如果我们有简单的行为，我们可以下拉和玩，我认为这是一种非常有趣的方式来优化孩子们学习制作游戏的项目。
或者有人不习惯用它来玩游戏。

尽管 VisualScript 也是如此，但模块化可能会更容易实现。 问题在于统一性和一致性（Visual Shader 和 VisualScript 使用完全不同的代码库，只有相似之处在于使用的 UI 节点）。
尽管如此，我们当然可以尝试将事件脚本系统作为插件（C++ 插件，希望在 4.0 之后变得容易），可以由社区维护并在需要时添加到 Godot。 （我有点偏向于模块化游戏引擎）

无论如何，这只是我的 2cents。

为什么我的评论被标记为离题？ 有人审查社区，谁？ 这可不是好兆头。 除了我的之外，还有其他评论更离题。

@prominentdetail这是我的防撞通知消息，我忘记粘贴了：slightly_smiling_face：

请不要在未提供重要新信息的情况下遇到问题。 请改用第一个帖子上的 :+1: 反应按钮。

（我希望 GitHub 有办法发送私人消息，或者至少指定一个自定义的隐藏原因，这样我就不必在评论线程中乱扔垃圾了。）

PS：这是GitHub上的典型礼仪； 它不是特定于此存储库的。

我确实支持这个提议，只是认为没有人会花时间去实施它。
它没有真正能够实现它的开发人员的足够强大的支持。

值得一试，讨论肯定很有趣:)

@blurymind如果您仍然支持该提案并愿意花时间以 GIP 所需的格式编写它。 值得做 IMO。

在 Godot 中添加东西的方式是当有人对某个功能感兴趣时花时间去实现它。 这是非常随机和零星的。 但我们几乎完全依赖于随机决定添加功能的贡献者。

因此，仅仅因为当前活跃的开发人员对您的提案没有兴趣，并不意味着不会有人来实施它。