Godot: 易于使用的非程序员游戏设计器

计划在某个时候编写可视化脚本

2015 年 1 月 14 日星期三上午 6:20，RyanBram [email protected]写道：

嗨，Godot 开发人员。

首先我要感谢你们所有人创造了伟大的游戏引擎
具有非常宽松的许可证。 您的努力将帮助许多开发人员和
预算紧张的学生来实现他们的梦想。

以 Godot 的现状，开源游戏的未来将更加光明。
不幸的是，大多数开源游戏引擎都是用先进的设计
考虑到对编程知之甚少的用户。 还是达不到
初学者游戏制作者。

我的建议是提供一个易于使用的游戏设计师/编辑器
直观的 GUI 和预定义的类，以减轻新程序员的任务。 更多的
程序员意味着更多的用户（因为 Godot 用户是游戏程序员）。

我知道一个游戏引擎可以很好地完成这项工作。 它是用 Ruby 编写的，
最初来自日本，并在世界范围内翻译成英文。 它被称为RPG
创客 VX 王牌
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace。 尽管
名字前的RPG字，足以打造非RPG
带有内置 Ruby 游戏脚本系统 (RGSS) 的游戏。

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30312f7270676d616b6572322e6a7067

以下列表是使用 RPG Maker 引擎制作的游戏示例：

1. Aleph (RPG 冒险) http://www.pioneervalleygames.com/
2. 没有海牛承诺（街机） http://rpgmaker.net/games/5102/
3. Ragarokk - Bestiarium (纸牌游戏) http://rpgmaker.net/games/5808/
4. 地球受到攻击！ （射手） http://rpgmaker.net/games/6561/
5. Terra (VisualNovel) http://rpgmaker.net/games/3956/
6. 法力的回忆（动作角色扮演游戏）
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - 开始（恐怖） http://rpgmaker.net/games/6493/

我希望 Godot 引擎能像 RPG Maker 一样流行，因为它有很多
比 RPG Maker 更多的功能。 初级程序员只需要一个易于使用的
界面。 如果成功，Okam工作室可能会成为下一个GOG或Steam
它发布了由独立开发人员创建的数千款游戏。

问候，瑞安

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220。

@RyanBram - 在这里根本不试图反对这个想法 - 它可能在未来很有用，但我不确定可视化脚本是一种有效的脚本方式。 我不能肯定地说，但我想你发布的更复杂的游戏很可能是用文字编写的，而不是视觉上的。 似乎视觉脚本是新用户使用的东西，当然，但这会延迟他们学习正确完成项目所需的实际工具。 但它可以使引擎更平易近人，所以我不知道。

用户也应该可以使用 GDScript 在 Godot 中创建一个可视化编程系统，而不是需要内置到引擎中的东西，对吧？ 不过，我不确定。

RPG maker 似乎更多地采用了“Modding”的方法，如果 Godot 看起来更像 RPG maker - 打算制作不同类型游戏的人会转身离开。 所以你基本上建议是让godot看起来更像GameMaker（这是可以理解的，很多人想做游戏但不懂编程）但是有局限性:)
可能会发生的是，Godot 将获得节点行为图编辑器，类似于 Leadwerks 和 BGE 所拥有的。 这与 GUI 元素配合得很好，其余的则需要一些研究和大量的社区反馈，以使其尽可能简单和强大。

@SolarLune ，可以在 Godot 中构建游戏并在顶部添加一个编辑器，允许对游戏的每个小细节进行修改（通过使用 GraphNodes 和 UI 的其余部分，玩起来非常有趣），甚至允许编写一些额外的 GDscript 代码，我认为这是最好的方法，单独发布一个完整的游戏（RPG，FPS，RTS）并允许调整它的各个方面。 在 Godot 中制作的构造函数。

@SolarLune ：当您与
程序员，可以让你拼凑起来玩。 这
虚幻中的方法很有用。 我认为不可能更换
完全编程（除非你是一个受虐狂），但它可以工作
有些人也为非程序员制作模板块。

2015 年 1 月 14 日星期三下午 4:23，TheoXD [email protected]写道：

RPG制造商似乎采取了更多“Modding”的方式，如果godot会
看起来更像 RPG 制造商 - 有意做出不同的人
那种游戏会转身离开。 所以你基本上建议的是
让 godot 看起来更像 GameMaker（这是可以理解的，很多人
想做游戏但不懂编程）但有限制:)
可能会发生的是 Godot 将获得 Nodal Behavior Graph
编辑器，类似于 Leadwerks 和 BGE 的编辑器。 这非常适用于
GUI 元素，其余的需要一些研究和大量的社区
反馈，使其尽可能简单和强大。

@SolarLune https://github.com/SolarLune ，可以构建游戏
在 Godot 中并在顶部添加一个编辑器，允许将游戏修改为每个
小细节（通过使用 GraphNodes 和 UI 的其余部分），甚至允许
在上面写一些额外的GDscript代码，我认为这是最好的方法，
单独发布完整的游戏（RPG、FPS、RTS）并允许调整
它的各个方面。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733。

好吧，据我所知，Godot 已经有了基于节点的 UI 代码（用于动画树和现在的视觉着色器编辑器），将来可以用来创建“逻辑”树类型。

但是，必须注意，如果您想要最大的灵活性并且使逻辑节点有用，那么 GDscript 将仍然是要走的路，需要一个脚本节点来执行 GDscript（对于更复杂和更高级的东西）。

UE4 目前无法在蓝图中完成所有事情而没有疯狂的复杂性，GameMaker 希望您使用 GML 以获得最大的灵活性（通过使用代码块），而 BGE 需要在 Python 中编写脚本以获得最大的功能（通过使用代码块）。 人们不能忽视可视化编辑对快速原型设计和不太复杂的逻辑情况的有用性，但它通常不能完成代码中可以做的所有事情。

计划在某个时候编写可视化脚本

感谢您简单而积极的回应。

大家，感谢您评论此建议。 我相信一个简单且可视化的编辑器永远无法取代手工编码。 我建议将此功能作为常规编码的补充，而不是替换其位置。

在 RPG Maker VX Ace 中，大部分高级功能都是手动编码的。 高级程序员通常会提供高级修改脚本，其值可以由普通用户在 GUI 编辑器中编辑（角色名称、技能、肖像、精灵等）。 Ruby 游戏脚本系统使猴子补丁成为可能。 这就是为什么高级用户提供的大多数脚本不会替换 RPG Maker 开发人员原来的预定义类以避免兼容性问题。

为了比较：
KDE 和 GNOME 项目从不打算取代 Linux 中强大的 Shell 命令，而只是试图填补易用性和 Linux 强大功能之间的差距。

我对 Okam 工作室就像 Steam 的想法笑了... :))

2015 年 1 月 14 日下午 5:20，RyanBram 写道：

嗨，Godot 开发人员。

首先我要感谢你们所有人创造了伟大的游戏
具有非常宽松的许可证的引擎。 你的努力将帮助许多人
预算紧张的开发人员和学生来实现他们的梦想。

以Godot的现状，开源游戏将更加光明
未来。 不幸的是，大多数游戏引擎的开源都是设计的
考虑到高级用户，对编程知之甚少。 它
仍然无法接触到初学者游戏制作者。

我的建议是提供一个易于使用的游戏设计师/编辑器
直观的 GUI 和预定义的类，以减轻新程序员的任务。
更多的程序员意味着更多的用户（因为 Godot 用户是游戏程序员）。

我知道一个游戏引擎可以很好地完成这项工作。 它是用 Ruby 编写的，
最初来自日本，并在世界范围内翻译成英文。 它是
叫RPG Maker VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace。
尽管它的名字前面有RPG字样，但它足以胜任
使用其内置的 Ruby 游戏脚本系统 (RGSS) 创建非 RPG 游戏。

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30312f7270676d616b6572322e6a7067

以下列表是使用 RPG Maker 引擎制作的游戏示例：

1. Aleph (RPG 冒险) http://www.pioneervalleygames.com/
2. 没有海牛承诺（街机） http://rpgmaker.net/games/5102/
3. Ragarokk - Bestiarium (纸牌游戏) http://rpgmaker.net/games/5808/
4. 地球受到攻击！ （射手） http://rpgmaker.net/games/6561/
5. Terra (VisualNovel) http://rpgmaker.net/games/3956/
6. 法力的回忆（动作角色扮演游戏）
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - 开始（恐怖） http://rpgmaker.net/games/6493/

我希望 Godot 引擎能像 RPG Maker 一样流行，因为它有
比 RPG Maker 更多的功能。 初级程序员只需要一个
易于使用的界面。 如果成功，Okam 工作室可能会成为下一个
GOG 或 Steam 发布由独立开发者创建的数千款游戏。

问候，瑞安

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220。

无论您是否想做一个项目，虚幻引擎实际上都有项目模板
可视化脚本或完整脚本类型的工作流......甚至
用于可视化编辑的代码块可通过 Visual Studio 访问，并且可以
定制... ：）

2015 年 1 月 15 日凌晨 3:44，Juan Linietsky 写道：

@SolarLune ：当您与
程序员，可以让你拼凑起来玩。
这
虚幻中的方法很有用。 我认为不可能更换
完全编程（除非你是一个受虐狂），但它可以工作
有些人也为非程序员制作模板块。

2015 年 1 月 14 日星期三下午 4:23，TheoXD [email protected]写道：

RPG制造商似乎采取了更多“Modding”的方式，如果godot会
看起来更像 RPG 制造商 - 有意做出不同的人
那种游戏会转身离开。 所以你基本上建议的是
让 godot 看起来更像 GameMaker（这是可以理解的，很多
人们
想做游戏但不懂编程）但有限制:)
可能会发生的是 Godot 将获得 Nodal Behavior Graph
编辑器，类似于 Leadwerks 和 BGE 的编辑器。 这很好用
和
GUI 元素，其余的需要一些研究和大量的
社区
反馈，使其尽可能简单和强大。

@SolarLune https://github.com/SolarLune ，可以构建游戏
在 Godot 中并在顶部添加一个编辑器，允许将游戏修改为每个
小细节（通过使用 GraphNodes 和 UI 的其余部分），甚至会
允许
在上面写一些额外的GDscript代码，我认为这是最好的
方法，
单独发布一个完整的游戏游戏（RPG、FPS、RTS）并允许
调整
它的各个方面。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -69978224。

我对 Okam 工作室就像 Steam 的想法微笑... :))

我也笑得很积极。
因为如果有一家像 Steam 这样大的公司，拥有大量由数以千计的优秀游戏开发者创建的游戏目录、开放和 DRM Free，对我作为游戏玩家来说将是一件好事。

无论您是否想做一个项目，虚幻引擎实际上都有模板
可视化脚本或完整脚本类型的工作流......甚至
用于可视化编辑的代码块可通过 Visual Studio 访问，并且可以
定制... ：）

如果它可以在 Godot 中使用，那就太好了。

问候，
瑞安

嗨瑞恩

你检查过构造2吗？ 它是我最喜欢的视觉游戏设计师之一，使用起来非常简单。

在 Godot 中进行可视化编程，我认为会有些困难（因为 Godot 可以同时处理 2d 和 3d，因此范围要大得多。）
此外，当引擎的所有底层块都到位时，它可能会在很久以后构建。

我知道 reduz 对此有自己的路线图，但我希望他不会将其优先于其他编辑器/引擎更新。 我宁愿让初学者或半熟练的程序员而不是非程序员使用 Godot。 但这只是我。

嗨瑞恩

你检查过Construct 2吗？ 它是我最喜欢的视觉游戏设计师之一，使用起来非常简单。

我尝试了 Construct 2。它很棒而且很棒。 由此产生的游戏也跨平台，所以这是一个很大的优势。 不幸的是，我仍然找不到任何轻松创建 RPG 游戏的教程。 现在我可能会留在 RPG Maker VX Ace 并尝试在MKXP Project的帮助下将我的游戏移植到许多平台（包括 Android）。

感谢分享。 我期待在 Godot 中进行可视化编程。

最好的祝福，
瑞安

对于可视化脚本方法 - 您可以从 gdevelop、多媒体融合和构建 2 中记笔记。这些引擎 100% 依赖于可视化脚本。 您仍然需要学习一些需要表达式的语法，但是表达式编辑器可以非常容易地找到正确的命令。 这三个引擎让您可以自由地使用可视化脚本创建任何类型的游戏 - 与游戏制作者和 rpg 制作者不同。

Rpg maker 并不是一个很好的例子，因为它非常有限。
基于节点的脚本在空间使用方面非常低效——您将通过一个巨大的节点图平移和放大和缩小。 将其与构造 2 进行比较，其中所有内容都以清晰的方式布局，紧凑且易于阅读 - 你就赢了。

BGE 可能是这里最糟糕的例子，因为它试图将基于节点的方法与逻辑块结合起来。 我写了为什么这很糟糕：
http://blenderartists.org/forum/showthread.php?323905-comparing-BGE-logic-bricks-with-Scirra-Construct-event-sheet-for-prototyping

如果您执行可视化脚本，请不要使用基于通用节点的编辑器对其进行半途而废。 如果您希望更多非程序员人员使用您的引擎，请使用更好的设计来做一些事情 - 例如construct2或多媒体融合。

我希望看到像这样的东西_only_作为一种次要的编程方式。 与代码相反，可视化脚本将生产力降低了一个相当大的数量级。 它还往往使调试和重构变得更加困难。 我能想到的一个主要优点（除了它吸引非程序员之外）是，如果可视化脚本能够生成或至少显示实际的 GDScript 代码（IE.code.组织）。 我认为不需要反过来（IE. GDScript to Visual）。 我认为这将是学校将 Godot 纳入课堂的好方法。

以下是代码和可视化脚本之间的两个主要区别，我认为就可接近性而言，它们是最重要的。 这是来自一个不会用十英尺长的杆子接触视觉脚本的人，但我确实理解它对某些人很有吸引力:)

代码：代码往往具有需要遵循的特定语法规则。 我的猜测是，这往往是关闭非程序员的主要因素。 IE。 在 GDScript 中，你必须在函数声明、if、for、while 循环等的末尾有一个冒号。你必须正确缩进。 在声明像“var myInteger = 1”这样的变量时，您必须使用 var 关键字。 对于大多数语言，往往需要遵循大约 3 或 4 条主要语法规则，在我看来并不难学。 在编写了一些小脚本之后，即使是艺术家也可以学习它们。 我这么说是因为我与两位非常有才华的艺术家一起工作，他们与 Ensemble Studios 合作完成了所有三款帝国时代的游戏。 一个用 UnityScript 编写了大量代码，另一个用 C# 编写了大量代码。

视觉：您倾向于获得方法、变量、语句等的下拉菜单。但是，您仍然必须知道您正在寻找哪些函数、属性等以及它们的作用，甚至有时它们是如何工作的。 你仍然必须解决问题。 您仍然必须使用变量并跟踪它们在整个脚本中所做的事情。 您仍然可以像编写代码一样容易出现逻辑错误。

我确实认为，从生产力的角度来看，能够真正编写代码最终是一种优越得多的方式。 但是，两者都不会使您成为更好/更差的程序员。 我确实认为可视化脚本是一个非常好的教学工具，但是如果你不知道（或想学习）如何正确地构建事物，尤其是如何解决问题，那么可视化脚本对你一点帮助也没有。

我会采取稍微不同的方法。 由于 godot 编辑器是自行驱动的 - 很容易在纯 GDscript 中重新创建类似的编辑器界面。

所以我的建议是制作一个完全在 godot 中编写脚本的构造函数并单独发布。 这将允许程序员和非程序员在使用不同工具的同时处理同一个项目。 唯一的问题是非程序员有时不得不同时处理这两种工具，但是嘿，我见过更糟糕的 xD Gridmap 编辑器、着色器编辑器、动画编辑器、代码编辑器 - 可以重新创建，而 collada 导入器、凸发电机，出口商——没那么容易。 仍然感觉像是在重新发明轮子，但可以简化很多事情。

构造函数核心可以用于任何具有可下载内容和内容的游戏类型（FPS、RTS、GPS ......），如果它是由社区维护的 - 它会更容易贡献，因为一切都是 GDscript
godot 中不太可能很快出现可视化脚本，但这并不能阻止其他人在其之上创建构造函数。 我见过有人使用 Blender 2.5 并制作了一个用于设计室内的工具。

我认为拥有多个编辑器可能会破坏 Godot 的发展。 需要有一个设计良好的中心项目，用于构建在 gdscript 之上的可视化脚本工具。

不要偷懒，做你的研究。 查看其他纯可视化脚本引擎。 比较他们的用户群（他们有多受欢迎），比较他们的灵活性——用他们制作的游戏类型——无论是在kickstarter、steam还是其他平台上。
研究他们的设计方法。

然后在纸上设计。 不要只是复制节点方法。 为着色器使用节点是可以的，但是当它涉及到逻辑时，你最终会遇到一团糟的滚动并试图找出答案。

相信我，我什么都试过了。 Unity 的 playmaker、Unreal 的 Kismet、rpg maker、stenyl 等。
Construct2 与多媒体融合一起位居榜首。 这些是最受欢迎的，采用最灵活的方法。 他们都有资产市场商店。
它们非常灵活，如果您研究使用它们制作的游戏 - 类型繁多。

如果你对此更加了解，你可以与 Gdevelop 合作——另一个开源项目已经有一个可以制作 html5 游戏的可视化脚本编辑器。
查看它的设计和源代码..

如果我们要在这个线程上投票，我很确定这将是完全错误的地方，因为主要是程序员会出现在投票中。

应该为艺术家而不是程序员设计可视化脚本系统。 尽管我可以抱怨我完全不喜欢 Unity 上的 PlayMaker 之类的东西，但事实是艺术家们喜欢它。 这就是为什么它有近 2000 条评论并且是 5 星的原因。 如果投票是更像 Construct 2 的脚本，那么我的投票是根本没有可视化脚本，因为我不相信它会有任何真正的好处，因为 A) 程序员可以直接在 GDScript 中编程和 B) 许多艺术家会立即被它关闭，然后去其他地方。 我知道，因为我的两个艺术家朋友都可以编码，他们正在研究 Construct 2 并取笑它的编程接口，因为它几乎与编写代码相同。

一种可视化的脚本语言应该非常直观，字数不多。 乍一看，它不应该像代码。 它应该为“视觉人”量身定制，否则一开始就没有意义。 艺术家习惯并倾向于喜欢节点图，因为它们可以让您直观地了解程序正在做什么。 再说一次，我自己不喜欢节点图，因为我受不了它们，但我是一名程序员，我的投票在这方面真的不应该算在内。

我同意你的观点，它应该是为艺术家/设计师设计的。
但是不同意单词=复杂性的逻辑。

如果您让某人坐下来教他们使用两者中的一种-construct2 将成为两者中更容易的一种。 为什么？
因为它比节点更清晰。 清晰得多。 你有条件和行动。 你把第一个放在左边，另一个放在右边。
要添加两者中的任何一个，您不必知道命令。 它们都列在那里供您添加 - 清除为一天。 每个都带有一个图标 - 这是一个视觉提示。

Playmaker 和其他基于节点的系统需要更多的学习，因为将一个节点连接到另一个节点需要您首先了解是否可以将两者连接起来。 它不仅仅是条件-> 动作。 节点要复杂得多，而且缺乏视觉提示。 你在哪里看到了组织者的图标？
在其中犯错要容易得多。 阅读其中的逻辑要困难得多。
https://www.scirra.com/tutorials/top
我还认为，因为 C2 是一个设计更好的可视化编程工具，它拥有比 playmaker 更大的活跃用户社区——尽管它目前仅限于 2d 游戏。 网络上更多数量的视频教程（比 playmaker 更多的人了解如何使用它）、更多已完成的项目、健康活跃的市场和论坛，以及最重要的是开发人员和用户之间的积极交流。 所以开发人员知道艺术家用户想要什么。

Construct 用户可以简单地截取他们的事件表，并清楚地了解他们是如何做到的。 去论坛看看自己。 我认为它的用户比组织者多得多。

我认为在其中设置逻辑所需的工作比在任何基于节点的系统中要少。

我可以看出你喜欢它们，但请至少在声明它是程序员的引擎之前尝试一下construct2。
看看他们的论坛和用户群。 它比组织者拥有更多甚至更好的代表。 它通过精心设计——靠自己——而不是成为一个已经成功的引擎的插件，设法获得了良好的口碑。 它是任何艺术家都可以使用的纯可视化编程工具。 我是一名艺术家，我尝试过组织者——这比construct2更难。 去 C2 的论坛，试着让他们相信组织者更容易使用——只是为了一笑。 :D
你自己不是程序员吗？ 你对 github 项目的贡献比我多。 这是否意味着你不应该做出更容易学习的陈述？

我从程序员的角度理解你的观点。 如果我必须在两者之间进行选择，我也会选择 Construct 模型。 然而，就像我说的，这是做出这个决定的最糟糕的地方，因为可能大多数（如果不是所有）阅读 GitHub 邮件列表的人都是程序员。

在我的职业生涯中，我花在艺术家身上的时间比我花在程序员身上的时间要多。 虽然在过去的 18 年里我经常做这两件事（并且对这两件事都充满热情），但在我成为一名专业的程序员之前，我是一名专业的艺术家。 我不在乎我是否有学位，我的学位是数字动画和视觉效果。 据我所知，在堪萨斯城工作了几年后，我制作的广告仍然在播放。 我曾为 Hallmark、Sprint、Radio Shack、Honda 和其他一些我可能忘记的公司拍摄过镜头。 在与布鲁斯·布兰尼特（Bruce Branit）一起在“世界建造者”中拍摄不少镜头时，我也获得了很多乐趣。

https://www.youtube.com/watch?v=QP3YywgRx5A
学分中的内森·沃登是我

我说这不是为了炫耀，我说这句话是为了说明问题。 我可能是错的，但作为一个在艺术家身边花了很多时间的艺术家，我想我知道艺术家喜欢什么。 他们不太喜欢Constructor之类的东西。 他们往往会感到害怕并选择完全不同的应用程序。 一般来说，艺术家的思维方式与程序员截然不同。 就像当我和我的朋友 Erik 谈论我想教他的技术时，这些话经常从他嘴里说出来，“内特，我是一个非常有眼光的人，如果你不能给我看的话从视觉上看，你还不如对着墙说话”。

艺术家喜欢基于节点的着色器图而不是线性着色器系统是有原因的。 他们可以想象正在发生的事情。 我想我从来没有听过艺术家抱怨他们最喜欢的 3D 应用程序中没有线性着色器系统，但是当他们没有基于节点的着色器系统时，他们经常抱怨。

与 After Effects 相比，艺术家更喜欢 Fusion 等应用程序是有原因的。 在几乎所有情况下，他们都会选择基于节点而不是线性的东西，因为它更直观。

因此，基于节点的系统吸引艺术家的还有两个原因：

1）它们在视觉上看起来更具吸引力。
2) 它符合他们已经习惯的设计范式。 IE 着色和合成

归根结底就是这样。 如果艺术家因为另一个具有基于节点的编程而要看一眼并传递给下一个游戏引擎，那么 Godot 根本不应该有可视化脚本，因为可能不会超过极少数人谁将使用它，这意味着从那时起更多的代码维护。

你确定你知道Construct2是什么吗？ 你甚至没有拼写正确的名字。
它不称为“构造函数”。

我完全不同意我们应该使用节点，因为“乍一看它不应该像代码。”

它的清晰程度比它的外观更重要。 逻辑的清晰性比编辑器乍一看更重要。 Construct2 看起来不像代码——文本是用简单的英语编写的，很明显 Action 或 Condition 的作用。 使用 C2 的人也大多是视觉人。

事件表总是会战胜节点——无论你试图让它看起来。 它可以在屏幕上打包更多信息而减少平移 - 逻辑的作用更明显。 视觉提示（图标）更容易被艺术家的眼睛发现。
节点没有图标和文本的巨大限制。
所以在很多情况下，一个节点甚至没有清楚地描述它所做的事情，因为它的大小非常有限——迫使设计使用晦涩的术语而不是简单的英语。

还有一点：
从上到下读取并执行事件表。 这是显而易见且可以预见的。
有了节点网络，你的眼睛会四处走动，它们会分裂成分支。 它变得更加复杂。

关于第一眼而不是实际用户体验的第三人称观点故事在这里不应该有任何分量。 我也是一个非常视觉化的人，但已经使用了许多视觉脚本引擎。 看到人们在一段时间内不使用实际引擎的情况下进行争论，这绝对是一件令人头疼的事情——例如，在一个小项目中。

我敦促 godot 的设计师/开发人员/视觉人员在小规模项目中实际尝试这些引擎，然后得出结论。 这些第三方故事已经够多了。 我们需要动手研究和逻辑说明为什么一个比另一个更好的案例。 信不信由你，视觉上的人也有一些常识。

无关：
在 Fusion 与 Aftereffects 的示例中 - 人们更喜欢基于节点的合成方法，因为在复杂的场景中使用图层会变得非常麻烦，其中可以在多个图层上复制相同的效果。 使用节点，您可以在合成方面拥有更大的灵活性，并且只需将一种效果挂钩到多个图层。 但是节点比层更复杂。

我几乎同意你的所有观点，但这些观点仍然是从程序员的角度来看的。 如果我必须整天使用可视化脚本系统，我会选择看起来最像常规代码的那个。 这就是为什么我非常喜欢教想要学习如何使用 code.org 编程的孩子。 我真的是这种风格的忠实粉丝。 这对于教“想要”编程的人如何编程很有好处。

是的，我说构造错了，对不起。 不，我没有亲自使用过。 但是，这并不重要，因为它使用的脚本范式在任何想象中都不是一个新概念，所以我的论点甚至不是关于 Construct 本身。 这是关于那种风格的脚本，因为它与艺术家有关，而不是程序员。

在基于节点的系统中，您可以在每个节点中包含多个条件、事件和函数。 然后，您可以将节点命名为 Input，例如。 在其中，它将包含所有操纵杆输入，用户会告诉它要使用什么事件。 IE。 他们会指定一个像“Fire”这样的事件。 该事件将导致转换到他们将其连接到的任何节点。

这是一个简单的例子，你可以用一个简单的武器来处理射击。 请注意，虽然它很简单，但它也很强大，它看起来一点也不像代码：

最后一点，从界面的角度来看，您可以使基于块的脚本或基于节点的脚本看起来都不错，所以我不会浪费时间争论这一点。

但是，当我说“乍一看不应该像代码”时。 许多艺术家确实在无限期地关心他们每天整天都在看什么。 如果整个应用程序看起来不吸引人或看起来令人生畏，他们会拒绝整个应用程序。 我会说基于块的看起来对典型的艺术家来说是令人生畏和困惑的。 它看起来像程序员的东西，而且确实如此。

@blurymind ，

图节点实际上来自概念 UML。 您以非编程受众（项目经理、消费者、艺术家）可以理解的方式制作代码的图形表示。 这就是 UE4/Unity 使用的。 这是业内每个人都知道的事情。 构造函数通常采用不同的方法，这种方法有多好 - 不是由使用它的用户数量来定义的。

到处都有学习曲线，Construct2 也不例外。 但是，我们不要在不支持这些论点的情况下将 C2 的东西强加到 Godot 中。 事件表会随着更复杂的游戏而变得更长，并且最终会比图节点浪费更多的空间。 只有“添加操作”按钮有它自己的行。 这基本上是程序员解释代码块的方式。 所以这并没有那么糟糕。

我个人不明白为什么我们不能同时拥有两者，但开发人员已经有足够的能力去做，所以它不会很快发生。 这就是为什么我提出了一种不同的方法，这种方法会发展得更快，几乎是由非程序员与程序员合作推动的。

这里有一个更好的例子来说明每个节点可以有多个事件。 另请注意，每个节点（或状态）都是非阻塞的，因此它将允许其他节点图同时运行：

但是，看看你的截图，我不知道这个逻辑是做什么的。 “firePrimary”和“fireSecondary”到底是什么？
现在向上滚动到我发布的construct2的屏幕截图。
在construct2上，左侧的条件将显示为“按下“R”键”或简明扼要的英文——旁边有一个键盘图标！

将它们都展示给艺术家并询问他们哪个更清楚。

向我们展示更精细的节点设置：) C2 屏幕截图显示了整个游戏逻辑。 你的只是一个事件。 你能在一个带有节点的屏幕截图中拟合相同的逻辑吗？ 我不这么认为。

请参阅节点示例是模糊信息。
您必须选择一个节点才能查看其中设置的内容。
它使用晦涩难懂的程序员术语而不是人类语言（“发送事件”、“存储结果”到底是什么？）。
Construct2 将所有内容显示在一个地方，对于非程序员来说是可以理解的。 可视化编程的重点是摆脱学习术语的需要。

我不是程序员。 我没有任何编写实际代码的经验。 然而，我可以轻松地使用construct2 制作游戏，而对我来说，使用节点更难——当涉及到一个完整的游戏时。

我知道每个人都会为他们已经知道如何做好的事情投票。 但正如你承认的那样——你是一名程序员，并没有真正使用过 C2。 我坚持说我是一个没有编码经验的艺术家——他同时使用了节点和 C2 方法。

我正在给你很好的逻辑论据，说明为什么要使用一个而不是另一个。
您正在给我诸如“节点更直观”和“虚幻使用节点”之类的陈述。 这些都是自以为是的陈述。 你们都承认自己是程序员。

告诉我我不支持我的论点只是确认您不想研究construct2 或将其设计视为节点的替代方案。 可悲的是，我说服你不这样做是浪费我的时间。

@TheoXD
如果我没看错的话，我完全同意你的看法。 将两者都作为单独的插件/模块会很好。 因此，下面将是实际的 GDScript，但您可以使用任何您想要的方式对其进行可视化。 我认为这是可能的。 基于节点的方法可能需要一些标志，如特殊注释来分隔节点（IE.#node name="Input" 和#endnode），但没什么大不了的，因为如果您从节点图开始，它将是自动的。 我认为块方法将是直截了当的。

你的意思是这样的吗？

就像我上面所说的，我真的很喜欢 block/Construct/code.org 方法，因为它非常适合教授编程。 我只是认为它不适合那些将编程视为必要之恶的人。

@blurymind
它没有意义的原因是你不熟悉它。 当我查看上面的 Construct 图像时，我同样不知道发生了什么，不是因为它不好，而是因为我不熟悉它。

至于在单击节点之前无法看到节点下的内容，一旦设置了节点，筛选您已经知道的内容就没有真正意义了。 我已经知道我有左键和右键，它们会发射主要和次要弹药。 我已经知道主火节点和次火节点是做什么的。 自从我做了它就没有改变，为什么我每次看它都必须看到它的细节？ 所以，现在底层逻辑很混乱。 这是节点对艺术家和非程序员更友好的另一个原因。 他们可以将其特定逻辑分解为更通用的块。 这样一来，他们就可以获得全局视图，并且只有在绝对需要时才担心细节。

我现在正在查看实际发布的手机游戏的实际项目，几乎每个节点图最多有 2 到 4 个节点，因此当您通常不需要复杂的设置时，很难向您展示更复杂的设置。

如果您想详细说明，这来自同一个应用程序，该应用程序是由一个几乎不是程序员的人编写的。 这是游戏中最复杂的图表之一。 它控制主要玩家的移动：

（你不能用积木做的另一件事是让它们看起来像萨姆斯的船，哈哈）

没有任何提示，我只是把你的Construct2图像放在一个屏幕上，然后把上面的节点图放在另一个屏幕上，然后问我的妻子（她绝对不是程序员），“如果你必须使用它，你想用哪个？每天？”，她指着节点图说，“这个”。 我知道这不是确定的，但它不那么令人生畏的事实意味着我有更多的机会开始让她学习它。 如果它看起来很吓人，她可能会在我让她坐下来学习基础知识之前关闭她的大脑。

在没有将他推向其中一个的情况下，我昨天还问了我的艺术家朋友（同一位曾为所有三个帝国时代游戏工作的人），他在游戏行业已经工作了近 20 年，（并且谁使用过 Construct2）他认为其他艺术家会喜欢什么，他还说节点图。

无论如何，我真的很喜欢讨论，但是打死马没有任何意义，哈哈：）

是的，我也很享受。 没有不好的感觉:)

真棒萨姆斯船顺便说一句。 你发布的图片越多，你就越支持我的观点，即节点在视觉上更难追踪，因为它们可以分裂成分支并朝着疯狂的方向发展。
对我来说，必须遵循块之间的线条和箭头所增加的复杂性总是感觉像是额外的工作。 我想我应该在这些日子里再试一次节点。 如果那是戈多要去的地方。

你再次给我们提供了没有证据支持的第三人称故事。 把这个家伙带到这里，让他告诉我们为什么他更喜欢另一个:)
然后你会有一个更强大的案例。 到目前为止，我没有得到任何逻辑上理智的观点来支持节点更直接的论点。

是的，乍一看它看起来不那么令人生畏，因为它隐藏了很多信息。 您的示例比我发布的屏幕截图中显示的要简单得多。 这是误导。
这是一个视频，展示了如何在 C2 中为平台游戏设置逻辑。
https://www.youtube.com/watch?v=5RlSmkSbleI
跳过第一分钟：P

让我们不要将苹果与橙子进行比较。
Code.org 是一种与 Construct2 完全不同的方法——它看起来更像 Stencyl，并且具有节点的一个缺点：你的条件和操作没有明确分开——所以很难弄清楚你可以附加什么。 精心设计的可视化编程工具（多媒体融合、construct2、gamedevelop）为用户清楚地将所有条件与动作分开。 这使得构建逻辑变得更加容易，因为它们是由软件为您组织的，该软件会猜测您可能需要什么并在正确的时间向您展示。 它还可以防止你犯愚蠢的错误。

使用nodes/stencyl/code.org，你必须弄清楚哪个是条件，哪个是动作。 以正确的方式设置您的条件需要更多的思考。 什么类型的信息来自节点？ 有时需要更多的节点来设置条件 - 更多地学习如何连接它们。
来吧，做你的研究并实际使用其他工具。 将所有非节点节点视为更多相同并无济于事。

@blurymind ，到目前为止，您的案例得到了使用 Construct2 的用户数量的支持，这通常是软件的商业模式以及他们在营销方面的能力的结果。 个人偏好（您的逻辑论点）不足以将 C2 工作流强制转换为 Godot。 但它是一个很好的参考。

如果您要向某人展示您想如何在纸或黑板上构建游戏（对象-对象关系），您会如何展示？ 通过编写事件树？ 不。你会用节点和线绘制一个概念视图，然后将它们视为类，添加函数、成员..
我同意事件表看起来更像代码，只能由程序员解释，它可以让用户在进步时想要学习实际的编程。 我注意到它也有一些术语和学习曲线，你不能否认这一点。 但形状识别和对象分组实际上是一个真实的东西。 我学习了一门关于数据可视化的课程，除了它可能会变得多么无聊之外——它实际上是有好处的。

尽管我希望这个问题的评论超过 100 条，但开发人员不会全部阅读，我们每个人能做的最好的事情就是制作一个带有提案的 PDF，并在邮件列表中分享它们。 我不明白为什么我们不能有不同级别的抽象，图形节点作为顶层，可以用事件树的形式表示。 如果这行得通，那么就没有必要妥协。

“ @blurymind -- || -- 你们都承认自己是程序员。” - 我不认为自己只是一个程序员，你也知道做艺术。 我用我的经验从客观的角度看待事物。

我不确定是否错过了，但我也不仅仅是一个程序员，还是一个专业的艺术家。 我认为大多数程序员会真正受益于一段时间的艺术。 它使某些事情的编程更有意义，它还有助于弥合程序员/艺术家的竞争，哈哈 :) 我知道这更理想，对大多数人来说不太实用。

这是我的一些作品的一些链接（在学分中寻找 Nathan Warden）

World Builder（参与了大约一半的镜头）
https://www.youtube.com/watch?v=VzFpg271sm8

泰迪恐慌（参与了大多数镜头）
https://www.youtube.com/watch?v=qCXIzS_iY0k

标志皇冠中心（与圣诞老人的第三张照片）
https://www.youtube.com/watch?v=biqBq3_Whqk

这是我的路易大厦的渲染图。 如果您观看 World Builder，您会看到我从其中撕下并放入电影中的一些艺术品。

这是一个未完成的终结者 1 型 HK 坦克粉碎斯蒂芬金的克里斯汀的渲染。 这两个模型都是由我完成的，但我认为镜头中没有其他任何东西。

还有更多我可以说出的名字，但我认为这点是有道理的。 :)

好吧，这些都是惊人的剧照——但你再次这样做是为了给自己更多的权威。 这无助于从逻辑上支持节点比事件表更好的想法:)

如果您使用节点，您将像使用可视化编程的任何其他该死的 3d 游戏引擎一样。

我认为这不是一个好主意，原因有很多。

-最近 Unreal 让他们的引擎免费 - 它也是多平台的。 它是一个比 BGE/Godot 成熟得多的引擎。 因此，在复制他们的可视化编程方法时，您正在直接与他们竞争。

- 节点的屏幕效率低于逻辑表。 它们更难阅读/遵循。

-Scirra 宣布construct3 将是多平台的——编辑器将在windows、linux 和mac 上工作。
但是它们不是开源的。
https://www.construct3.com/

这在 scirra 社区引发了一波评论。 很多用户想要一些没有可视化编程的 godot 可以提供的东西：
- 本机 exe 文件而不是 html5 容器 - 以获得更好的性能
- 支持 3d 游戏开发，使用构造中的事件表样式对其进行编程：
https://www.scirra.com/forum/construct-3_t90881

如果他们制作一个简单易懂的 3D 编辑器，比如 C2 中的 2D 工具，我会完全使用它

我尝试过 unity、blender、torque 3D、UDK，因为它们的宣传力度更大，而且大多数所谓的著名开发人员都在使用它们……而且它们有同样的问题：它们对用户不友好（根本不友好），如果你以前从未使用过 3D 游戏创建 API……好吧，你是 3Doomed（坏笑话 ikno）

问题是，一旦你掌握了基本知识，构建就非常直观，让你可以自由地制作复杂的 2D 游戏，它为你提供了不同的路径来实现相同的结果（更不用说事件系统对我来说很有意义）； 这是大多数其他工具未能涵盖或使其不佳的细节

如果他们制作了与我使用 C2 相同的流程和感觉的 3D 引擎； 那为什么不试一试呢？

他们目前拥有庞大的用户群（喜欢可视化编程的事件表样式，但想要这些功能），其中一些已经准备好跳转到另一个引擎。 Godot 有很大的潜力吸引许多新的独立开发者加入——那些更喜欢节点而不是节点的人——那些不使用虚幻引擎的人——现在是免费的，而且比 godot 更成熟。

如果你选择它而不是节点，你将成为第一个支持具有可视化编程设计的完整 3D 游戏开发的引擎。 您将利用新的用户群，而不是与 Unreal（免费）、Unity（提供免费版本）竞争

好吧，这些都是惊人的剧照——但你再次这样做是为了给自己更多的权威。

剧照和链接不能证明我的权威，而是我合作过的人的证明，而且我不只是在编造 :) 这包括我的一些好朋友，他们参与过一些你可能听说过的电影，比如《阿凡达》、《金刚》、《宁静》，以及《迷失》、《革命》等节目……以及我在游戏行业工作超过 15 年的其他一些朋友。 所有这些都更喜欢基于节点的工作流程，而不是线性的、基于工作表的工作流程。 我可能会从其中 3-4 人那里得到一句话，告诉你如果你愿意的话，他们更喜欢节点图而不是逻辑表？

最近 Unreal 使他们的引擎免费 - 它也是多平台的。 它是一个比 BGE/Godot 成熟得多的引擎。 因此，在复制他们的可视化编程方法时，您正在直接与他们竞争。

可视化脚本工作流程是人们在将 Godot 与那些引擎进行比较时最不会看到的东西。 他们首先会注意到 Unreal 支持 DirectX 12 和 OpenGL 4，而且他们的演示和示例看起来很棒，然后他们会开始关注其他的东西。 Godot 对这些公司的主要优势是它是 FLOSS 软件，任何使用它的人同样是该软件的完全所有者。

节点的屏幕效率低于逻辑表。 它们更难阅读/遵循。

虽然您的陈述很明显您没有使用基于节点的良好设置，但如果您担心屏幕效率等问题，那么您无论如何都不应该使用可视化脚本，您应该使用已经可用的真实脚本:) 我向您保证，任何可视化脚本可以为您提供的屏幕空间常规脚本也可以做到这一点，例如折叠代码区域。

如果你选择它而不是节点，你将成为第一个支持具有可视化编程设计的完整 3D 游戏开发的引擎。

像虚幻引擎这样花费大量时间、金钱和研究客户需求的引擎没有采用这种形式的可视化脚本，而是选择节点，这是有原因的。

我对此的看法是，这完全取决于打算采用的方法
解决了。

像 Game Maker 这样的动作块很有趣，但我认为它更有趣
旨在替代编程。

虚幻的方法更像是对编程的补充，所以
设计师可以自己在游戏中工作，并将工作从
程序员。 这在团队中更有用（艺术家和游戏设计师
可以很好地使用它）并且绝对是我想添加的方法
戈多因为这个。

由于 Godot 架构，它也很容易添加，所以我会给出
这是 1.2 中的一个镜头

在 2015 年 3 月 3 日星期二下午 4:37，Nathan [email protected]写道：

好吧，这些都是惊人的剧照——但你再次这样做是为了
自己更有权威。

剧照和链接不是我权威的证明，而是我所认识的人的证明
和我一起工作过，我不仅仅是在编造:) 这包括我的一些
参与过一些你可能听说过的电影的好朋友
《阿凡达》、《金刚》、《宁静》以及《迷失》、《革命》等节目……还有
我的其他一些在游戏行业工作超过 15 年的朋友
年。 所有这些都更喜欢基于节点的工作流程，而不是基于线性、基于工作表的工作流程
工作流程。 我可能会从他们中的 3-4 人那里得到一句话，告诉你
如果您愿意，他们更喜欢节点图而不是逻辑表？

最近 Unreal 使他们的引擎免费 - 它也是多平台的。 它是一个
比 BGE/Godot 成熟得多的引擎。 所以你在和他们竞争
直接在复制他们的可视化编程方法时。

可视化脚本工作流程是人们最不想做的事情
在将 Godot 与那些引擎进行比较时查看。 他们会做的第一件事
请注意，Unreal 支持 DirectX 12 和 OpenGL 4，并且他们的演示
和例子看起来很棒，然后他们会开始关注其他的东西。
Godot 对这些公司的主要影响是它是 FLOSS
并且任何使用它的人同样是该软件的完全所有者
软件。

节点的屏幕效率低于逻辑表。 他们更难
阅读/关注。

虽然您的陈述很明显您没有使用好的节点
基于设置，如果您担心屏幕效率等问题，那么您
无论如何都不应该使用可视化脚本，你应该使用真实的
已经可用的脚本:)我向你保证任何事情
可视化脚本可以为您提供屏幕空间常规脚本
也可以这样做，例如折叠代码区域。

如果你选择它而不是节点，你将成为第一个
支持完整的 3D 游戏开发与该 vis 编程设计。

像虚幻引擎这样花费大量时间和金钱的引擎是有原因的
并且对客户需求的研究并没有采用这种形式
可视化脚本并选择节点。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -77017857。

我给了 Playmaker 一个很好的尝试，并且必须说我喜欢它 - 超过了 unreal 的 kismet/蓝图。

在组织者中，节点有点像您放置动作的容器。 其中一些操作是检查可能导致另一个节点的条件。

由于您自己制作节点容器并可以命名它们，因此它们中的操作以可预测的方式（从上到下）执行 - 这是我可以忍受的。 :)

此外，您放置在节点内的操作实际上是具有视觉输入的标准统一脚本。 因此，人们将能够编写自己的脚本并将它们添加为自定义操作。

请研究 playmaker 并实现一个更类似于它的基于节点的系统，而不是 Unreal。
它的优点当然是我们可以用更少的节点做更多的事情，它们更容易阅读和调试，并且更容易预测。

下面介绍一下它的工作原理：
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10

它非常灵活，允许用户轻松添加和共享游戏功能 - 易于重新使用。

引人入胜的讨论。 只想指出除了节点和 C2 的事件表之外的另一种类型/形式的可视化脚本，而是像拼图一样组合在一起的脚本块。 用于 2d 引擎 Stencyl http://www.stencyl.com/

基于 MIT Scratch http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(block)

在我个人使用的 Unity 中，Blox http://www.plyoung.com/blox/

我个人不相信类似划痕的“视觉”编程。 一世
认为这很像编程。
我认为 Unreal 这样做的方式对游戏/关卡设计师很友好

2015 年 3 月 21 日星期六晚上 11:57，todheil [email protected]写道：

引人入胜的讨论。 只是想指出另一种类型/形式的视觉
除了节点之外的脚本，而是组合在一起的脚本块，例如
拼图。 用于 2d 引擎 Stencyl http://www.stencyl.com/
[图片：stencyl_blocks]
https://cloud.githubusercontent.com/assets/8675463/6767767/d52e7b16-d013-11e4-878c-29002dc04f8e.PNG
基于 MIT Scratch
http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(块)
[图片：scratch_example]
https://cloud.githubusercontent.com/assets/8675463/6767792/57f50e5c-d014-11e4-8015-9228bb6001d8.PNG
在我个人使用的 Unity 中，Blox http://www.plyoung.com/blox/
[图片：hello_blox]
https://cloud.githubusercontent.com/assets/8675463/6767796/7849f46a-d014-11e4-9244-9e45c601f883.PNG

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -84508001。

_OkamStudio_

好点子。 对我来说，块是代码行和流程图之间的中间方式。

我不喜欢可视化编程的临时/模板方式。 它的布局是
视觉上比construct2块甚至节点更难理解。 它是
从字面上拼凑拼图，它受到以下问题的困扰
弄清楚哪一块适合哪里。 它们并不简单
一起

在 2015 年 3 月 22 日星期日上午 5:46，todheil [email protected]写道：

好点子。 对我来说，块是代码行和流程之间的中间方式
图表。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415。

好的，我现在不会阅读所有内容，而只是我在这个主题上的 2 美分。

创建基于事件的引擎来制作原型和小型游戏项目
像godot这样的引擎是为了制作各种项目而创建的

所以它们是两个不同的东西，有两个不同的方法，它们是两个
不同的通行费

老实说，我不能很好地使用它们。 （基于事件的收费）

对我来说，更好的方法是两个平行收费。

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected] :

我不喜欢可视化编程的从头/模板方式。 它的布局是
视觉上比construct2块甚至节点更难理解。 它是
从字面上拼凑拼图，它受到以下问题的困扰
弄清楚哪一块适合哪里。 它们并不简单
一起

在 2015 年 3 月 22 日星期日上午 5:46，todheil [email protected]写道：

好点子。 对我来说，块是代码行和流程之间的中间方式
图表。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752。

大卫·阿吉亚·德·阿基诺·派瓦

唯一有用的是统一的“行为”系统，
基本上它是一个制作东西的脚本，所以这在 godot 中
翻译为每个节点添加多个脚本的可能性。
当然，我可以创建一个节点并克隆它，但脚本将是
资源，然后将其加载到节点并添加行为（对于
例如，一个跳转脚本）
在编辑器中，我们可以看到在脚本名称下分类的导出。

2015-03-26 13:15 GMT-03:00 David Paiva [email protected] :

好的，我现在不会阅读所有内容，而只是我在这个主题上的 2 美分。

创建基于事件的引擎来制作原型和小型游戏项目
像godot这样的引擎是为了制作各种项目而创建的

所以它们是两个不同的东西，有两个不同的方法，它们是两个
不同的通行费

老实说，我不能很好地使用它们。

对我来说，更好的方法是两个平行收费。

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected] :

我不喜欢可视化编程的临时/模板方式。 它的布局是

视觉上比construct2块甚至节点更难理解。 它是
从字面上拼凑拼图，它受到以下问题的困扰
弄清楚哪一块适合哪里。 它们并不简单
一起

2015 年 3 月 22 日星期日上午 5:46，todheil [email protected]
写道：

好点子。 对我来说，块是代码行和流程之间的中间方式
图表。

—
直接回复此邮件或在 GitHub 上查看
< https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415
.

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752。

大卫·阿吉亚·德·阿基诺·派瓦

大卫·阿吉亚·德·阿基诺·派瓦

大家好！ 很好的讨论在这里 :) 我想补充一些东西。

第一件事：我是艺术学生，但编程是我的爱好。 我知道 Java、Python 和（我最喜欢的）Golang。 但是在我学习如何编码之前（大约 3 年前），我尝试了几乎所有声称它允许“无需编程即可创建游戏”的单个程序。 所有这些说法都是无稽之谈。

我尝试过（不分先后）：Click & Play、GameMaker、The Games Factory、Multimedia Fusion、Construct 1、RPG Maker、Stencyl、BGE 以及其他一些我什至不记得的东西。 而我的观点是：你可以制作一个没有_writing_代码但没有_programming_的游戏。 即使您使用事件表或节点，您仍然需要了解_编程逻辑_。 你必须知道什么是条件、事件、变量、字符串等。所以没有编程就不可能创建游戏。 所有这些可视化的编码方法只是用传统编程语言表达逻辑的不同方式。 这整个论点可能看起来很明显，但我向你保证，在我开始编程冒险时，我并不明显。

由此，它遵循我的下一个考虑：

在我学会如何编码之前，我发现的最好和最直观的可视化编程语言是 Scrach/Stencyl 拼图/积木方式。 原因如下：

• 该解决方案最接近传统编程。 事实上，它就像底层代码的语法糖（基本上它是 Stencyl 的工作原理）对我来说，与节点图或无法放置的杂乱事件表相比，它更清洁、更容易遵循或创建看起来像彩色花哨的代码成很好的结构，如函数。 对我来说_这_是一团糟
  请记住，这只是我的意见

*我认为 Scrach/Stencyl 块是最直观且易于遵循的方法。 他们广泛使用颜色（视觉头脑的人喜欢颜色）很容易记住黄色=条件和循环，绿色=数学，蓝色=变量等。而且它看起来像真实的代码（与节点相比）但更友好。

最后，我认为视觉编程不应该很快成为优先事项。 还有很多更重要的事情要做（整个路线图 + 文档），我想实施这些系统中的任何一个都不会快速和容易。 恕我直言，Godot 现在真的很容易工作。 它包含许多可供艺术家与游戏开发者合作使用的工具（视觉着色器编辑器、动画编辑器、瓷砖地图节点）。

顺便提一句。 我想借此机会感谢所有 Godot 的创造者和贡献者。 你做得很好:+1:

顺便说一句。 对不起我的英语。 我正在尽力而为，但我仍在犯愚蠢的错误:cry:

无论是construct2 还是blox - 对我来说都比那些节点图更好。

如果系统仅将节点用作操作的容器（作为状态）——就像在 Playmaker 中的方式，那么我会接受它。

blox 和construct2 的优点在于编辑器向您显示所有可用的条件和操作。 它为您将它们分开并将它们分类。 这是表示的一个巨大变化，它允许非编码人员立即使用引擎做很多事情 - 而无需知道执行操作的命令的名称。

如果您使用节点进行可视化编程 - 最大的挑战将是按照事件执行的顺序与用户沟通。 在 Unity 中 - playmaker 和 blox 都非常干净地做到了这一点。

在 playmaker 中通过在节点容器内堆叠动作（状态 - 包含动作）。 在 blox - 你有包含函数的状态。

它们可以完全访问大多数统一的功能。 这对非程序员来说真的很好。
blox 已进一步发展为“plygame” - 另一个具有 blox+ 的统一插件，blox 可以访问一些自定义脚本，以创建一个完整的 rpg hack 和 slash 风格的游戏。

统一的 Blox 与 Skrach/Stencyl 块相同。 这里似乎有很多人喜欢这种编程风格:)
https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k

希望 godot 开发人员试一试。
顺便说一句，Skratch (https://scratch.mit.edu/) 技术是开源的！ 并且其他人一直在采用它 - 不仅是 stencyl。 谷歌也对它很感兴趣：
https://developers.google.com/blockly/

建议 - 为什么不尝试两全其美！ 状态机的节点 - 用于表达式的 blox/skratch/stencyl。
在理想的世界中，您会将节点用作状态容器 - 就像在 Playmaker 中一样。 但是状态容器将具有类似于乐高系统的 blox/stencyl/skratch，允许用户轻松设置逻辑 - 无需学习以这种方式编写表达式 - 它们只需准备好拖放即可。

http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

iCanScript 的一位开发人员这样评价他们的 VS 资产：

iCS2 的技术进步使其不再是 Unity 唯一的产品，显着增加了市场机会。 最终愿景是 iCS2 将成为一种开发辅助工具，可用于为其他游戏引擎以及标准 Windows/OSX/iOS/Android 应用程序创建脚本。
http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

iCanScript 是一个多么混乱的节点！

无论如何，在我判断之前值得尝试。 也许有人可以进去
联系它的开发者？
如果 Godot 有一个有获利机会的市场——比如那个
unity 确实 - 也许这会吸引统一开发人员为
戈多也是。

2015 年 5 月 23 日星期六下午 4:24，todheil [email protected]写道：

iCanScript 的一位开发人员这样评价他们的 VS 资产：

iCS2 的技术进步使其不再仅仅是一个 Unity
产品显着>增加市场机会。 最终愿景
是iCS2将是一个开发辅助工具>可以用来创建脚本
适用于其他游戏引擎以及标准 >Windows/OSX/iOS/Android
应用程序。

http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -104895405。

我认为construct 2的事件表真的很容易理解和编程。

作为一名花费大部分时间为我的生活创作图形的艺术家，学习一门新语言非常困难且耗时。 人们说你可以在几个月内学会它，但是当你每天只有 2 小时的时间时，你可以选择从头开始学习或使用简单的语言进行创作。 此外，作为一个视觉人物，视觉脚本更有意义。

我在学校做过编程，我可以轻松阅读和理解代码，但编写它需要时间。 我也在尝试学习更容易的python，但是用它来创建一些东西仍然需要几个月的时间。

Construct 2 的方法看起来很简单。 对我来说，它看起来像：

1个事件：动作；

2 事件：动作；
： 行动;

它基本上是编程，但以一种非常容易理解的方式。 如果他们只使用语言而不是块我不会介意的。 使用这种模式很容易为我创建逻辑。

随着事情开始蔓延，使用节点可能会很快失控，并且您会花费更多时间来寻找节点然后实际编码（正如我从统一和组织者那里了解到的那样）。

因此，如果您正在尝试实现可视化脚本，请认真考虑构建事件系统。

您还可以将可视化脚本系统创建为像我们这样的人的可下载扩展，这样那些喜欢编程的人就不必下载额外的有效负载。

Godot 的出色工作期待在其上创造出色的游戏。

我对 Construct 方法的问题是它感觉像是编程，它
似乎没有太大的不同
从团队的角度来看，我更喜欢 Unreal 的蓝图方法，因为
对不懂编程的设计师更友好

在 2015 年 5 月 24 日星期日凌晨 3:58，whoisda [email protected]写道：

我认为construct 2的事件表真的很容易理解和
中的程序。

作为一个花费大部分时间为我的生活创作图形的艺术家，
学习一门新语言非常困难且耗时。 人们说你可以
在几个月内学会它，但当你每天只有 2 小时的时间
您自己可以选择从头开始学习或使用
简单的语言。 此外，作为一个视觉化的人，视觉脚本会让更多
感觉。

我在学校做过编程，我可以轻松阅读和理解代码
但写作需要时间。 我也在尝试学习更容易的python
但是用它来创造一些东西仍然需要几个月的时间。

Construct 2 的方法看起来很简单。 对我来说，它看起来像：

1个事件：动作；

2 事件：动作；
： 行动;

它基本上是编程，但以一种非常容易理解的方式。 如果他们
只使用了语言而不是我不会介意的块。 使用这个
模式很容易为我创建一个逻辑。

随着事情开始蔓延，使用节点可能会很快失控
你花更多的时间来寻找节点然后实际编码（正如我
从团结和组织者那里理解）。

因此，如果您正在尝试实现可视化脚本，请给出一个非常
认真思考构建事件系统。

您还可以将可视化脚本系统创建为可下载的
像我们这样的人的扩展，所以那些喜欢编程的人不必
下载额外的有效载荷。

Godot 的出色工作期待在其上创造出色的游戏。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159。

但是你是一个程序员的视角——一个已经知道怎么做的人
编码。
在这种情况下最好查看统计数据 - 的数量
与其他可视化编程相比，construct2 拥有的非程序员用户
编辑应该为自己说话。

它还值得研究以一种视觉编程风格而不是另一种风格创建的各种游戏。

Unreal 确实在 kismet 中完成了大量项目——但它是一个比construct2 更古老的引擎，而且其中很多只是第一人称射击游戏

2015 年 5 月 24 日星期日上午 10:15，Juan Linietsky [email protected]
写道：

我对 Construct 方法的问题是它感觉像是编程，它
似乎没有太大的不同
从团队的角度来看，我更喜欢 Unreal 的蓝图方法，因为
对不懂编程的设计师更友好

在 2015 年 5 月 24 日星期日凌晨 3:58，whoisda [email protected]写道：

我认为construct 2的事件表真的很容易理解和
中的程序。

作为一个花费大部分时间为我的生活创作图形的艺术家，
学习一门新语言非常困难且耗时。 人们说你
能够
在几个月内学会它，但当你每天只有 2 小时的时间
您自己可以选择从头开始学习或使用
简单的语言。 此外，作为一个视觉化的人，视觉脚本会让更多
感觉。

我在学校做过编程，我可以轻松阅读和理解代码
但写作需要时间。 我也在尝试学习 python 这是
更轻松
但是用它来创造一些东西仍然需要几个月的时间。

Construct 2 的方法看起来很简单。 对我来说，它看起来像：

1个事件：动作；

2 事件：动作；
： 行动;

它基本上是编程，但以一种非常容易理解的方式。 如果
他们
只使用了语言而不是我不会介意的块。 使用
这
模式很容易为我创建一个逻辑。

随着事情开始蔓延，使用节点可能会很快失控
你花更多的时间来寻找节点然后实际编码（正如我
从团结和组织者那里理解）。

因此，如果您正在尝试实现可视化脚本，请给出一个非常
认真思考构建事件系统。

您还可以将可视化脚本系统创建为可下载的
像我们这样的人的扩展，所以那些喜欢编程的人没有
到
下载额外的有效载荷。

Godot 的出色工作期待在其上创造出色的游戏。

—
直接回复此邮件或在 GitHub 上查看
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669。

Construct2 的编程方法与
Clickteam fusion，也有很多用户。 它的易用性来自于
事情的数量，即使它类似于编程：

• 列出所有可能的条件，供用户选择
  通过单击/拖动以简单的英语添加 - 这是非常宝贵的
  因为他们不必学习魔法词。 他们可以拖动
  放下它们。
• 列出所有可能的操作并可供用户选择
  通过单击/拖动以简单的英语添加 - 这是非常宝贵的
  因为他们不必学习魔法词。 他们可以拖动
  放下它们。
• 在设置和执行任何类型的表达式时也是如此
  动作或条件。 当您编写表达式时，编辑器正在帮助您
  有一个简单的下拉列表，可以从现有对象中获取
  场景。 您不必学习如何到达这些属性，因为它们
  只需单击几下即可使用。

也许它最好的方面是它教非程序员
没有学习新编程的学习曲线的编程理论
语。

2015 年 5 月 24 日星期日上午 10:17，Todor Imreorov [email protected]
写道：

但你是一个程序员的视角——一个已经知道的人
如何编码。
在这种情况下最好查看统计数据 - 的数量
与其他可视化编程相比，construct2 拥有的非程序员用户
编辑应该为自己说话。

2015 年 5 月 24 日星期日上午 10:15，Juan Linietsky < [email protected]

写道：

我对 Construct 方法的问题是它感觉像是编程，它
似乎没有太大的不同
从团队的角度来看，我更喜欢 Unreal 的蓝图方法，因为
对不懂编程的设计师更友好

2015 年 5 月 24 日星期日凌晨 3:58，whoisda [email protected]
写道：

我认为construct 2的事件表真的很容易理解和
中的程序。

作为一个花费大部分时间为我的生活创作图形的艺术家，
学习一门新语言非常困难且耗时。 人们说你
能够
在几个月内学会它，但当你每天只有 2 小时的时间
您自己可以选择从头开始学习或使用
简单的语言。 此外，作为一个视觉化的人，视觉脚本会让更多
感觉。

我在学校做过编程，我可以阅读和理解代码
容易地
但写作需要时间。 我也在尝试学习 python 这是
更轻松
但是用它来创造一些东西仍然需要几个月的时间。

Construct 2 的方法看起来很简单。 对我来说，它看起来像：

1个事件：动作；

2 事件：动作；
： 行动;

它基本上是编程，但以一种非常容易理解的方式。 如果
他们
只使用了语言而不是我不会介意的块。 使用
这
模式很容易为我创建一个逻辑。

随着事情开始蔓延，使用节点可能会很快失控
和
你花更多的时间来寻找节点然后实际编码（正如我
从团结和组织者那里理解）。

因此，如果您正在尝试实现可视化脚本，请给出一个非常
认真思考构建事件系统。

您还可以将可视化脚本系统创建为可下载的
像我们这样的人的扩展，所以那些喜欢编程的人没有
到
下载额外的有效载荷。

Godot 的出色工作期待在其上创造出色的游戏。

—
直接回复此邮件或在 GitHub 上查看
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669。

还要从想要学习编写复杂逻辑并最终有足够信心学习编码的设计师的角度来看待它。 当您看到该系统将由一组设计师和程序员使用时，我知道您来自哪里。 我个人希望将 Godot 用作单个用户，而不是像许多独立游戏开发人员那样与程序员一起使用。 当您有 1000 多个事件时，事件系统是宽容的，并且使用组感觉更有条理。

除此之外，我对节点系统没有任何问题，如果 godot 设法创建一个比当前更好的系统，我将使用它。

此外，如果可能，请创建搜索功能以轻松查找代码块/节点。

请注意，construct2/clickteam 中的事件表消除了学习的需要
语法——所以用户不必知道把东西放在哪里——也就是说
很明显。 左边是条件，右边是动作。 的顺序
事件执行也很明显。
Scratch/stencyl/unity blox 中的乐高积木不那么明显，但仍然
比“iCanScript”中呈现的节点噩梦要好得多。 你看了吗
在他们的视频教程中。 这是一个超级复杂的可视化编程设计
具有相当陡峭的学习曲线。 我认为即使你把它给
程序员，他们将很难弄清楚

在 2015 年 5 月 24 日星期日上午 10:33，whoisda [email protected]写道：

也从一个想学习的设计师的角度来看
编写复杂的逻辑并最终获得足够的信心来学习编码。
我知道您来自哪里，因为您看到系统将被
设计师和程序员团队。 我个人想用 Godot 作为
单个用户，而不是像很多独立游戏那样有程序员的团队
开发商。 事件系统是宽容的，使用起来感觉更有条理
当您有 1000 多个事件时进行分组。

除此之外，我对节点系统没有任何问题，如果 godot 设法做到
创建一个比现在更好的系统
它。

此外，如果可能，请创建搜索功能以查找代码块/节点
容易地。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595。

他们甚至不再在统一资产商店出售“icanscript”。
看看那里的销售数据 - 可用的可视化编程之一
系统使用最多 - 并且有完整的项目。

我会给你留下这个视频：
https://www.youtube.com/watch?v=3Zq1yo0lxOU
它有 167 款使用 clickteam fusion 制作的游戏 - 由没有经验的人制作
编程经验。

还可以看看 fusion 中成功的 kickstarter 游戏。
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia/​​description
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game/description
https://www.kickstarter.com/projects/2064021040/tiny-trek

需要我还提到弗雷迪的五夜（在clickteam融合中制作）：
http://en.wikipedia.org/wiki/Five_Nights_at_Freddy%27s_%28video_game%29
那场比赛是畅销书。 这里有一些数字给你：
https://thinkgaming.com/app-sales-data/8779/five-nights-at-freddys/

可视化编程框架的想法应该是让艺术家能够在不需要程序员的情况下创建游戏——在这个过程中学习一点编程知识。

如果你在仍然需要程序员的地方制作了一个——那么你还没有真正制作出可视化编程框架——你只是创建了一个状态机，程序员可以设置它供设计师使用——用于游戏中的简单事情——但不是用于游戏的核心逻辑。 因此，您不会真的要创建像这里提到的其他可视化编程工具一样好的和完整的东西。 您没有授权艺术家建立逻辑并邀请他们学习编程的基本概念。 你让他们依赖于程序员，并且对这些概念一无所知。

2015 年 5 月 24 日星期日上午 10:42，Todor Imreorov [email protected]
写道：

请注意，construct2/clickteam 中的事件表消除了学习的需要
语法——所以用户不必知道把东西放在哪里——也就是说
很明显。 左边是条件，右边是动作。 的顺序
事件执行也很明显。
Scratch/stencyl/unity blox 中的乐高积木并不那么明显，但
仍然比“iCanScript”中呈现的节点噩梦要好得多。 做过
你看看他们的视频教程。 这是一个超级复杂的视觉
具有相当陡峭的学习曲线的编程设计。 我认为即使
你把它交给程序员，他们会很难搞清楚

2015 年 5 月 24 日星期日上午 10:33，whoisda [email protected]
写道：

也从一个想要的设计师的角度来看待它
学习编写复杂的逻辑并最终获得足够的信心来学习
代码。 我看到你来自哪里，因为你看到系统将被使用
由设计师和程序员组成的团队。 我个人想使用 Godot
作为一个单一的用户，而不是像很多独立的程序员那样在一个团队中
游戏开发商。 事件系统是宽容的，感觉更有条理
当您有 1000 多个事件时使用组。

除此之外，我对节点系统没有任何问题，如果 godot 设法做到
创建一个比现在更好的系统
它。

此外，如果可能，请创建搜索功能以查找代码块/节点
容易地。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595。

如果这不是你想要的方向，我认为推动你使用一个对另一个游戏引擎非常有效的系统是不明智的。

同样，我希望看到一些更直观的方式来实现可视化脚本。 不使用凌乱的节点或耗时的块（Android 应用程序创建者）或过于编程的事件系统（我更喜欢其他一切）。 需要所有这些中最好的东西。

也许咨询可用性设计师以清除一些路径并查看一些数字。

最后，很高兴看到 Godot 独有的方法使 Godot 成为一个很棒的引擎，它既能让一个人初学者在一周内设计他的第一个游戏，又能让一个开发团队合作创建一个 AAA 游戏。

我很高兴看到一个系统可以帮助我创建精彩的游戏，而无需经常更改引擎和学习语言。

干杯。

我不介意节点是否像 playmaker 中的那样完成 - 因为
动作容器（状态）。
那里的节点实际上并未用于设置动作或条件。

但是，如果您使它们像“iCanScript”，那么您将一团糟。

1. 很难判断事件执行的顺序
2. 很难弄清楚哪个节点可以连接到哪个节点
3. 设置一个动作比设置一个动作需要更多的节点和步骤
   拖放它并在其中设置一个表达式（construct2/clickteam 样式
4. 您可以在语法方面得到帮助——这是一种很好的介绍方式
   无需阅读大量内容即可编程的人
   文档 - 一切都在他们的下拉菜单中
   目的）。

在 2015 年 5 月 24 日星期日上午 11:20，whoisda [email protected]写道：

我认为强迫您使用有效的系统是不明智的
如果这不是你想要的方向，那么非常适合另一个游戏引擎
想拿。

在同一张纸条上，我希望看到一些更直观的方式，而不是视觉
脚本实现。 不使用杂乱的节点或耗时
块（Android 应用程序创建者）或过于编程的事件系统（我
比其他一切都更喜欢）。 需要所有这些中最好的东西。

也许请教可用性设计师以清除一些路径并查看一些
数字。

最后，很高兴看到 Godot 独有的方法
Godot 一个伟大的引擎，它可以让一个人初学者设计他的
一周内的第一场比赛和一个开发团队一起合作
创建一个 AAA 游戏。

我很高兴看到一个可以帮助我创造精彩游戏的系统
无需经常更换引擎和学习语言。

干杯。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -104990083。

我投票支持@whoisda关于在 Godot 中创新的东西。 然而，似乎有三个可视化脚本学校：1）节点，2）事件表，3）块。 在这三个节点中，似乎在 3d 环境中处于领先地位。 说到这里，我在某处读到了一个想法，建议脚本/编程打破线性（文本、块、事件表）或水平（节点）格式并使用结构进行 3D 编程。 不知道这将如何工作，但听起来很迷人。

提到的视觉脚本学校已经在实践中进行了测试，并且
已经有用户了。 我建议结合 Playmaker 的设计和
blox 团结一致。

用于创建状态机的节点。
用于在每个节点（状态）内创建操作的块或事件表。

在 2015 年 5 月 24 日星期日下午 1:56，todheil [email protected]写道：

我投票给@whoisda https://github.com/whoisda 关于某事
为/在 Godot 中进行创新。 但是似乎有三个视觉
脚本学校：1）节点，2）事件表，3）块。 这三个中
节点似乎在 3D 环境中处于领先地位。 说到哪个
我在某处读过一个想法，建议脚本/编程突破
线性（文本、块、事件表）或水平（节点）格式和
使用结构进行 3D 编程。 不知道这会如何工作，但听起来
迷人。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -105001411。

如果我们可以同时使用节点和事件，那就太好了。 节点可以是如果遵循简单逻辑可以插入其他节点的状态，或者可以是脚本/块/事件表的容器，这样我们就不会拥有非常大的节点，也可以作为一个团队进行协作。 但这对开发人员来说可能太多了。 这个想法似乎仍然很简洁。

在 Playmaker 中就是这样——人们似乎很喜欢它。
这里的很多人似乎也喜欢 stencyl——这项技术是
开源，可在从头开始的 github 网站上获得。 我把它分享在一个
以前的帖子。

我个人很想看到可视化编程的任何第一步
方向。 即使开发人员制作了一个与 gd 一起工作的状态机
脚本——即使是高级程序员，这也是一个了不起的开始
会很感激。

然后也许在那之后我们可以有一些视觉上的东西，比如 stencyl 或
construct2 - 这就像代码 - 但比代码更容易 - 在
状态。

所以实际上这是两个功能请求！

• 一个用于状态机（节点）
• 另一个用于替代学习 gdscript 的可视化脚本框架
  使用拖放编码。 但也是朝着学习迈出的重要一步
  脚本。

最后，主要开发人员知道什么最适合 godot 的设计。

2015 年 5 月 26 日星期二上午 11:43，whoisda [email protected]写道：

如果我们可以同时使用节点和事件，那就太好了。 节点可以
如果遵循简单的逻辑可以插入其他节点或
可以是脚本/块/事件表的容器，这样我们就没有了
非常大的节点，也可以作为一个团队进行协作。 但这也可能
对开发商来说很重要。 这个想法似乎仍然很简洁。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984。

我会尽快检查 styencyl，因为我不熟悉它。
在这一点上，从我看到/读到的所有内容中，我可以收集到：

1) 蓝图：非常适合游戏/关卡设计师，但不太适合
可视化编程
2) Stencyl：对于可视化编程要好得多，但不能用于
游戏/关卡设计师

我制作游戏的经验总是在团队中，所以我可以看到 1)
非常有用，但这也让我有偏见。 有那么多人吗
对像 Stencyl 这样的可视化编程感兴趣？

2015 年 5 月 26 日星期二上午 6:10，Todor Imreorov [email protected]
写道：

在 Playmaker 中就是这样——人们似乎很喜欢它。
这里的很多人似乎也喜欢 stencyl - 技术是
开源，可在从头开始的 github 网站上获得。 我把它分享在一个
以前的帖子。

我个人很想看到可视化编程的任何第一步
方向。 即使开发人员制作了一个与 gd 一起工作的状态机
脚本——即使是高级程序员，这也是一个了不起的开始
会很感激。

然后也许在那之后我们可以有一些视觉上的东西，比如 stencyl 或
construct2 - 这就像代码 - 但比代码更容易 - 在
状态。

所以实际上这是两个功能请求！

• 一个用于状态机（节点）
• 另一个用于替代学习 gdscript 的可视化脚本框架
  使用拖放编码。 但也是朝着学习迈出的重要一步
  脚本。

最后，主要开发人员知道什么最适合 godot 的设计。

2015 年 5 月 26 日星期二上午 11:43，whoisda [email protected]
写道：

如果我们可以同时使用节点和事件，那就太好了。 节点可以
如果遵循简单的逻辑可以插入其他节点的状态
或者
可以是脚本/块/事件表的容器，这样我们不会
有
非常大的节点，也可以作为一个团队进行协作。 但这可能是
也
对开发商来说很重要。 这个想法似乎仍然很简洁。

—
直接回复此邮件或在 GitHub 上查看
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984
.

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -105458142。

http://www.emanueleferonato.com/wp-content/uploads/2011/12/stencyl05.png

这是模板“代码”的典型示例吗？ 如果是，那么这似乎是一个可怕的想法：它看起来像是幼儿园视觉包装中的标准编码。 来吧，python已经很容易让我妻子阅读了，所以为什么不努力学习基础知识呢？

如果您谈论可视化编程，那么 Godot 已经拥有的要好得多——着色器图或动画图：包含在可视节点中的代码。
https://frenchdog.files.wordpress.com/2009/09/specular_reflexion_vops.jpg - 另一个基于可视节点的编程示例（Sidefx Houdini，或 XSI）。 它很成熟，看起来不像儿童玩具，也让我想起了 Godot 节点。

我喜欢construct2方法，但在仔细研究之后——出于多种原因，它似乎是一个更好的选择：

• 编程设计似乎比construct2的更受欢迎
• 它已经被确立为帮助教人们编程语言的工具
• 它是开源的，其他人过去曾将其重新用于他们的引擎

Stenyl 开发人员采用了开源“scratch”技术。 这不是他们的设计。
https://scratch.mit.edu/about/
http://en.wikipedia.org/wiki/Scratch_ (programming_language)
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

其他针对非程序员的游戏引擎使用 Scratch 的示例：

• Stencyl（最受欢迎的一种） http://www.stencyl.com/
  
• 工艺工作室（http://craftstud.io/）
  
• 谷歌块（https://developers.google.com/blockly/）
• 最接近 Godot 的是 Unity 的“Blox”可视化编程资产：
  
  https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k
  它生成 C# 而不是 Lua。
  它的完整文档在这里：
  http://www.plyoung.com/blox/
  并在这里出售： https ://www.assetstore.unity3d.com/en/#!/content/12859

对于有经验的程序员来说，这似乎是一个可怕的想法，但它是教非程序员如何编写代码或简单地授权他们在不知道魔法词或语法的情况下进行编程的最佳方式。 Scratch 使它们都可以拖放 - 通过视觉线索强制构建正确的结构。 请观看我发布的“Unity Blox”视频播放列表以查看它的实际效果。 最重要的是，它已在实践中一次又一次地得到证明。 这看起来是最安全的选择。

我同意@reduz的观点，即一个擅长关卡设计，另一个擅长可视化脚本，并且不再争论使用一个优于另一个。

使用两者似乎是最好的方法。 如果不是 Unity blox，即使您查看 Playmaker，您也会看到节点实际上是容器 - 可以在其中堆叠操作 - 与 stencyl 非常相似。 您可以从列表中拖放它们！

“但这是教非程序员如何编写代码或简单地让他们在不知道魔术词的情况下进行编程的最佳方式”

然后我不明白这个目标是什么受众。 Godot 的目标是与市场上的大佬竞争（虚幻引擎、Unity 等）还是像 Scratch 一样教孩子编程/制作游戏（https://scratch.mit.edu/）？

我知道什么是节点（输入-> 带有参数的函数-> 输出），我不同意这个介绍。

Stencyl 和 Playmaker 可能很擅长教孩子们如何编码，但它们已被非程序员（工作室和独立开发者）成功地用于制作成功的游戏 - 在不同的平台上销售。
如果您将 Unity 归类为大男孩，那么您应该知道大男孩也从事可视化编程。
http://www.hutonggames.com/showcase.html

我认为 godot 有很多功能可供大男孩使用。 一些支持更小/独立的功能可以帮助更快地采用引擎。 开源性质和精简许可对于初学者来说是非常有利可图的。

@blurymind
我确实_不_反对可视化编程。 我想说 Godot 已经具备了它所需要的东西（ShaderGraphs）：同样的可视化方法可以扩展到状态机逻辑编程或通用编程。 我反对的是反对采用另一种不会吓跑孩子的视觉范式（~scratch）。

如前所述，它不仅适用于儿童。 但如果即使是孩子们也能理解并使用它——那我认为这是一件好事。 不是什么可耻的事。

我想在这里提出的最重要的一点是：

• 动作执行顺序要明确！ 使用节点执行所有逻辑会很快变得非常混乱。 所以节点应该用于状态imo。
• Playmaker 开发人员非常聪明地预见到了这个问题，这就是为什么他们将节点变成动作容器，在其中 - 与 Stencyl 非常相似 - 您可以从列表中拖放可用的动作：
  
  并以这种方式堆叠事件

你最终得到的是一个非常干净和高效的节点设置！

我建议 Godot 开发者也尝试一下组织者。
用 Stencyl 逻辑替换事件堆栈将使 godot 的方法更加灵活/强大！

它不必仅通过模板方法。 我认为您可以让有经验的程序员将 gd 脚本附加到节点。 可以选择使用模板方法来创建 gdscripts 将是非常宝贵的 imo。 它将邀请许多新用户加入 godot 社区。

@blurymind
好的，但那是不同的。 易于使用并不意味着它应该看起来像是为孩子们准备的。
给定节点的合适输入/输出的执行顺序和辅助过滤是基于节点的工作流的常见问题。 不同的软件有不同的解决方法。

你必须问自己——你希望更多的非程序员使用 Godot 吗？ 你想让那些没有使用 gdscript 经验的人可以做一些有趣的事情吗？

如果答案是肯定的——那么最好的方法就是给他们一个可视化的脚本方法。
我并不是建议让节点看起来像为孩子们制作的东西。
我的建议是将其分成两个项目！

• 在 Playmaker 中用作状态机的节点！ 程序员可以命名每个节点并将 gdscripts 附加到它 - 使用他们设置的输入和输出。 所以这根本不适合孩子。 事实上，对于程序员来说，这是一种更加灵活且不那么混乱的方法。
• 拖放事件表或块界面作为生成 GDscript 的替代方式。 因此，无需编写 GdScript 来附加到节点，非程序员只需从 godot 中所有可用事件的列表中堆叠操作 - 就像 Playmaker 一样。 更进一步并进行创新 - 与其简单地堆叠动作，不如使用类似 Stencyl 的积木。

这样你就有了对程序员和非程序员都有用的东西。 他们都可以使用状态机（节点），非程序员不必立即学习 gdscript，而是使用 gdBlocks 为节点生成 gdscript（再次 - 就像在 Playmaker 中一样）。

@blurymind
我更喜欢那个。 它也与 Godot 中的 Shader node-graph vs Shader-text 一致。

SideFX Houdini 有一个叫做 VEX (https://goo.gl/TMWNKk) 的东西（“向量表达式”一种类似 c 的语言，用于向量代数）。 它在某种程度上是 gdScript 的同义词。 它还有一个叫做“VOPs”（http://goo.gl/Qpn2OE）（Vex Operators）的东西——本质上是 VEX 子集的可视化包装器，它看起来与您在上面引用的 LeadWerks 节点图图像非常相似。 事实上，如有必要，VOP 可以转换为文本脚本（但不能反过来）。

两者的共存是很自然的，它确实允许，即使是非程序员，也可以创建非常混乱和低效的代码；）

我个人喜欢蓝图方法，因为它非常适合游戏设计师
喜欢，但我坚持认为我可能有偏见。

我在两个小时前下载了 Stencyl 并用它玩了起来。 我可能是
错了，但我认为 Stencyl 是一个很好的学习工具，因为不仅
编程部分被简化，但引擎部分也被简化。 组合是
很好，因为它是一个简单游戏引擎的简单编程方法。

但是 Godot 不是一个简单的游戏引擎（至少与 Stencyl 相比）所以我
不要认为简化的编程会那么有用。 Stenyl 依赖于
很多硬编码的游戏逻辑东西在
Godot，并试图使其可用将与 Godot 的目标相矛盾
作为一个非常通用的游戏引擎。

在我看来，节点和图形方法更有趣，因为它是
一种更低层次、更灵活的做事方式。

2015 年 5 月 26 日星期二上午 11:29，Vladimir Lopatin < [email protected]

写道：

@blurymind https://github.com/blurymind
我更喜欢那个。 它也与 Shader node-graph vs
已经在 Godot 中的着色器文本。

SideFX Houdini 有点冷 VEX (https://goo.gl/TMWNKk) ("vector
表达式”是一种用于向量代数的类 c 语言）。它是
有点像 gdScript 的同义词。 它还有一个叫做“VOPs”的东西（
http://goo.gl/Qpn2OE) (Vex Operators) - 本质上是一个可视化的包装器
VEX 的子集，它看起来非常类似于您的 LeadWerks 节点图
上面引用的。 事实上，如果需要的话，VOPs 可以变成脚本
（但不是相反）。

2 的共存是很自然的，它确实允许，甚至
非程序员，创建非常混乱和低效的代码；）

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -105543845。

Playmaker 中的动作堆叠和 Unity 中的 blox 怎么样？ Unity 不是一个非常简单的引擎。

我认为 stencyl 不是一个很好的例子。 最好在统一资产商店中查找示例。

我试图理解 playmaker 但失败了，它应该如何工作？

2015 年 5 月 26 日星期二下午 12:16，Todor Imreorov [email protected]
写道：

Playmaker 中的动作堆叠和 Unity 中的 blox 怎么样？ 团结不是一个
非常简单的引擎。

我认为 stencyl 不是一个很好的例子。 最好找
统一资产商店中的示例。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760。

查了playmaker的教程，但好像和stenyl类似
它带有无数预定义行为的感觉

2015 年 5 月 26 日星期二下午 12:19，Juan Linietsky [email protected]
写道：

我试图理解 playmaker 但失败了，它应该如何工作？

2015 年 5 月 26 日星期二下午 12:16，Todor Imreorov < [email protected]

写道：

Playmaker 中的动作堆叠和 Unity 中的 blox 怎么样？ 团结不是一个
非常简单的引擎。

我认为 stencyl 不是一个很好的例子。 最好找
统一资产商店中的示例。

—
直接回复此邮件或在 GitHub 上查看
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777。

_OkamStudio_

Unity 中最接近 U4 蓝图的是 uScript：
https://www.assetstore.unity3d.com/en/#!/content/1808

人们似乎更喜欢 Playmaker 而不是 uscript——因为它更容易理解已设置的逻辑。 正如您从屏幕截图中看到的那样 - 即使对于简单的逻辑，它也会变得非常混乱。

@reduz @okamstudio这里是 playmaker 的播放列表：
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10
我认为你应该实际使用它一点点。 您可以执行预定义的行为和脚本，但 playmaker 还允许您访问引擎的核心功能并自己从头开始制作此类行为。

是的，组织者是一个状态机，而统一性恰好伴随着许多预定义的行为。
Godot 也有它们——它们内置在引擎中。
我仍然相信，您实际上可以通过使用统一的模板克隆 blox 从头开始​​创建脚本/行为。

我认为最后你需要一个程序员来制作一个合适的游戏和这个想法
游戏设计师自己制作游戏很棒，但我认为很多
在许多情况下不能派上用场的工作。 但如果我们有更多
编辑器本身的功能就像其他人的平台游戏设计师一样
在另一个问题或其他有用的事情中提到，以使 ui 简单
更友好。
2015 年 5 月 26 日晚上 7:52，“Okam Studio” [email protected]写道：

查了playmaker的教程，但好像和stenyl类似
它带有无数预定义行为的感觉

2015 年 5 月 26 日星期二下午 12:19，Juan Linietsky < [email protected]

写道：

我试图理解 playmaker 但失败了，它应该如何工作？

2015 年 5 月 26 日星期二下午 12:16，Todor Imreorov <
通知@github.com

写道：

Playmaker 中的动作堆叠和 Unity 中的 blox 怎么样？ 团结是
不是
非常简单的引擎。

我认为 stencyl 不是一个很好的例子。 最好找
统一资产商店中的示例。

—
直接回复此邮件或在 GitHub 上查看
<
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
直接回复此邮件或在 GitHub 上查看
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777
.

_OkamStudio_

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -105565084。

这是统一资产商店对 uScript 的评论：

好工具，但如果非程序员很难学习......对论坛上的帮助请求的响应非常慢或根本不存在......

无论最终出现在 Godot 中，我认为 - 如果可能的话 - 允许单向转换为 GDScript 是一个好主意。 这将允许设计师和艺术家等在视觉上快速设置事物，然后允许团队中的编码人员进一步调整和返工，而无需使用尖点点击。

@adolson这将是一个非常需要的功能:)

这可以完成，也可以使用可视着色器编辑器完成
（实际上，确实会生成着色器代码）
但我认为生成的着色器代码不会像你想象的那样可读
期待：P

2015 年 5 月 26 日星期二下午 6:33，Nathan [email protected]写道：

@adolson https://github.com/adolson 那将是一个非常需要的
特征 ：）

—
直接回复此邮件或在 GitHub 上查看
https://github.com/okamstudio/godot/issues/1220#issuecomment -105670945。

@reduz一些元数据是预期的。
这是一个从 VOP 转换的示例 -> VEX 转换，如上所示：
：
这是代码的完整列表，否则，在纯 VEX 中看起来像这样：
@P += 向量({0,1,0}); // 取位置并添加向量 (0,1,0)

如您所见，元数据的数量很大，但将两者分开并不难，可能半自动或全自动解析它。

@reduz是的。 我并没有真正考虑过。 它可能不是大多数程序员想要花时间在的那种代码。我可以看到标签变成变量名等，但我看不出有太多其他东西可以缓解这个问题。

虽然我不能代表所有人，但如果我看到一堆乱七八糟的代码，我可能会从中提取一些零碎的东西，但我通常倾向于重写它。 所以，如果是这样的话，这对我个人来说是不值得的。

你们真的经历了各种各样的选择。 我使用过 Construct 2，虽然它很简洁，但你永远无法触及任何代码来改进它，而且选项相当有限。 瓷砖地图更新基本上摆脱了预制件，因此也实例化了。 我真正喜欢的是 PlayMaker for Unity。

关于它的一些事情很容易掌握你的范围和你需要做的事情。 这是一个非常吸引人的因素，我喜欢使用可视化脚本的全部原因正是因为这一点。 我看不到我在做什么或我需要在文本代码中做什么，但是看到一切如何“连接”对我来说绝对是最大的好处。 NateWardog 在更早的截图中发布了一个示例，并且在最近更模糊了。

我说reduz，你去吧。 现在，如果你不介意的话，我会为 1.3 或更高版本而努力，即便如此，主要还是专注于它的前端。 然后当它稍后准备好时，专注于让它输出像蓝图一样的可读代码，我想这将是非常具有挑战性的。 请不要小看这个！

订阅。 我对这个也很感兴趣！ 我知道一些脚本，并不介意使用它……但我更喜欢在可能的情况下连接节点！ 类似于 Blender 游戏引擎中的逻辑块，它充当 Godot 脚本功能的可视快捷方式，以替代手动编写它们……这将是一个可爱的功能，我正在积极等待。

可视化脚本确实吸引了很多有创造力的人或不想学习像 gd script 这样的新脚本语言的人。 我在看游戏制作者非常受欢迎，最重要的原因是视觉脚本机制。

可视化脚本乏味、愚蠢且难以使用。
我从来没有看到一个好的实现。 视觉的人应该画图形。 一世
知道很多人就是不会写，
但这对他们没有任何好处。 不会编程的人不代表
文盲的人。

我不知道任何可视化逻辑构建工具，它是主要系统
任何引擎中的游戏逻辑。
视觉方式在很多方面都很糟糕。 视觉的人通常认为
编程为“科技产品”
意味着真正的管道和辛勤工作，并且想要超越
它。 这种态度
通常是因为一些智力问题。 我不认为这些人
可以是目标受众
基本上他们限制了他们的创造力。

2016 年 4 月 14 日星期四上午 8:33，Rémi Verschelde [email protected]
写道：

编辑：我看到您将“RPG Maker”更改为“Game Maker”，现在它变得更多了
感觉：p 删除我的帖子。

—
您收到此消息是因为您订阅了此线程。
直接回复此邮件或在 GitHub 上查看
https://github.com/godotengine/godot/issues/1220#issuecomment -209770726

我不想，但我不得不说，但这是对可视化脚本工具的非常狭隘的看法，谢尔盖。 至于完全使用它们制作的游戏，一些引擎已经完全选择退出它们，例如 Construct，因此您不会看到任何使用常规脚本制作的引擎的游戏。 其他（更理智的，imo）引擎有 Unity 和 UE4 等插件。 我个人非常喜欢在 Unity 中同时使用 uscript 和 PlayMaker 以及我的常规代码，因为虽然有些东西更容易编码，但很多东西更容易在视觉上编写脚本，尤其是状态机，因为使用像 PM 这样的视觉脚本编写器可以为你提供很多反馈断点从更广阔的视野来看项目要容易得多。

一般而言，关于可视化脚本的真实情况是徒劳的尝试
让非程序员可以访问编程，这是完全错误的
方法。
可视化编程比常规文本编程更难。 让它
更容易你必须为传统生活中的每个案例编写许多块
方式和
让这些人使用它们。 事实证明，这些方法不如询问
写代码的好程序员。 诉说“编程不是职业，
每个人都可以做到”是错误的。所有没有编程的尝试
编程是一种浪费。

至于状态机 - 我有一段时间正在考虑实施这个
以前，但这无助于高视觉效果程序。
这可以使用工具脚本和节点编辑器为您的游戏轻松完成，
这是一个强大的工具，很多人将它用于游戏工具，比如
游戏对话编辑器。

2016 年 4 月 14 日星期四上午 9:09，Aaron M [email protected]写道：

我不想说，但这是一个非常狭隘的视觉观点
脚本工具，谢尔盖。 至于完全用他们制作的游戏，
一些引擎已经完全选择了它们，比如 Construct，所以你
不会看到任何使用常规脚本制作的引擎的游戏。 其他
（更理智，imo）引擎有Unity和UE4等插件。 我个人
真的很喜欢在 Unity 中同时使用 uscript 和 PlayMaker 以及我的常规
代码，因为虽然有些东西更容易编码，但很多东西更容易
可视化编写脚本，尤其是状态机，因为使用可视化
像 PM 这样的脚本编写器，它通过断点为您提供了很多反馈，这只是
从更广阔的视野来看项目要容易得多。

—
您收到此消息是因为您发表了评论。
直接回复此邮件或在 GitHub 上查看
https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

斯拉宾，你是对的。 但是您忘记了可视化编程或编程块的故障率非常低。 这是因为限制。
当您使用非常有限的脚本语言时，情况基本相同。 你不能犯很多错误。

我认为这应该是实现的目标，而不是视觉或文本脚本的问题！

如果你想让编程变得更好，那就让工具变得更好。 Codehighlighting、Codecompletion、Codevalidation、Codetemplates 等。 让调试器变得更好，让 Liveprogramming 变得更好。
我一直在寻找一个稳定的 Liveprogramming 环境，但是直到现在我都没有找到它！

如果你真的想制作可视化脚本，那就让它像 Stingray 引擎一样。 您可以在 Visual 中创建 CodeBlocks 并生成以后可以修改的 TextCode，或者编写以后可以用作 Visual Blocks 的 TextCode。

我不会说这是徒劳的，但我会说我们在谈论 2
完全不同的产品。

如果你经营一个工作室，并且你要和 20-80 人一起制作游戏，
您每个月要花费 6 位数的生产成本，而且您需要一个
引擎制作你的游戏，你想要一个特定的产品。 在这种情况下，你
根本不关心可视化脚本工具，你关心其他
事情，例如您的团队使用引擎工具的生产力
（因为如果他们超过计划一个月，你就会损失约 10 万美元）。 那些
团队有程序员，他们会更有效率地编写代码
而不是使用一些可视化工具（查找 Vicious Engine 的例子）

另一方面，如果你有一个很酷的想法并且不知道如何去做
写代码，你想要另一个产品，做一个快速原型的东西
你可以到处展示并最终给程序员做实际的
游戏。

这是两种不同的产品，如果我们争论哪个更有价值
有，我们必须承认这一点。 我会说可视化脚本
工具并不能真正扩展到超过 1 个人制作原型。 作为
只要你想打一场完整的比赛，或者你的球队成长到 2-3
人，你已经需要一门真正的编程语言了。 所以我喜欢第一个
更多作为总体目标的示例（除非您想要第三个产品，即
“您可以使用该引擎制作完整的独立游戏，从而获得数百万美元的收入
无需编写任何代码”。那不存在）。

但我们可以两者兼得，我不会阻止任何一个。 一个视觉
从长远来看，脚本工具将通过创建初学者用户来帮助我们
最终将在该行业中发挥作用，并可以决定
将godot用于真正的游戏，这很好。 此外，史克威尔艾尼克斯的 CTO
问我们引擎是否有视觉原型语言，所以这意味着
在大公司中也有这类事情的利基市场，可能是那些
重视研发并有很长的阶段
预生产/原型设计/尝试新想法等（他还告诉
我们认为我们的游戏看起来像主机游戏并询问（两次）哪个国家
我们去学习如何制作它们吗：p）。

2016 年 4 月 14 日 03:26，Sergey Lapin [email protected]写道：

一般而言，关于可视化脚本的真实情况是徒劳的尝试
让非程序员可以访问编程，这是完全错误的
方法。
可视化编程比常规文本编程更难。 让它
更容易你必须为传统生活中的每个案例编写许多块
方式和
让这些人使用它们。 事实证明，这些方法不如询问
写代码的好程序员。 诉说“编程不是职业，
每个人都可以做到”是错误的。所有没有编程的尝试
编程是一种浪费。

至于状态机 - 我有一段时间正在考虑实施这个
以前，但这无助于高视觉效果程序。
这可以使用工具脚本和节点编辑器为您的游戏轻松完成，
这是一个强大的工具，很多人将它用于游戏工具，比如
游戏对话编辑器。

2016 年 4 月 14 日星期四上午 9:09，Aaron M [email protected]写道：

我不想说，但这是一个非常狭隘的视觉观点
脚本工具，谢尔盖。 至于已经完全制作的游戏
他们，
一些引擎已经完全选择了它们，比如 Construct，所以你
不会看到任何使用常规脚本制作的引擎的游戏。 其他
（更理智，imo）引擎有Unity和UE4等插件。 我个人
真的很喜欢在 Unity 中同时使用 uscript 和 PlayMaker 以及我的常规
代码，因为虽然有些东西更容易编码，但很多东西更容易
可视化编写脚本，尤其是状态机，因为使用可视化
像 PM 这样的脚本编写器，它通过断点给你很多反馈
只是
从更广阔的视野来看项目要容易得多。

—
您收到此消息是因为您发表了评论。
直接回复此邮件或在 GitHub 上查看
< https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

—
您收到此消息是因为您订阅了此线程。
直接回复此邮件或在 GitHub 上查看
https://github.com/godotengine/godot/issues/1220#issuecomment -209779422

你只是在说我的punto slapin，我的意思是，我从来没有说过任何关于设计师或简化的事情，但即使对于程序员来说也很容易使用，我已经体验过它的用处。 当我的轶事经验正好相反时，你不能只告诉我这是浪费时间。 我更喜欢 _alongside_ 脚本可用的选项，你表现得好像我只能选择一个或另一个，我被迫把它交给我的艺术家。 根本不是这样。

很棒的帖子，很多意见😁

我的很简单。 你没事！

这些想法中的任何一个都将是 gdscript 的一个很好的补充😁

我期待着在它们出现时试用它们。

我认为 gdscript 也可以通过一些爱变得更加用户友好。

一些节点没有完整记录。 很多都没有描述。
Godot 可以利用一些辅助函数来简化开发。 Gamemaker gml 就是一个很好的例子：
https://twitter.com/uheartbeast/status/724326557108461568

我认为文档是这里的主要 PITA，仅此而已。
开发本身很简单。 文档和教程
真的很需要。 因此，只需让您的 youtube 帐户成为您自己的帐户（或博客，或
只是在论坛上发帖），
这会有很大帮助。

2016 年 4 月 25 日星期一上午 9:35，Todor Imreorov [email protected]
写道：

我认为 gdscript 也可以通过一些爱变得更加用户友好。

一些节点没有完整记录。 很多都没有描述。
Godot 可以利用一些辅助函数来简化开发。
Gamemaker gml 就是一个很好的例子：
https://twitter.com/uheartbeast/status/724326557108461568

—
您收到此消息是因为您发表了评论。
直接回复此邮件或在 GitHub 上查看
https://github.com/godotengine/godot/issues/1220#issuecomment -214163012

好吧，我对此有几个想法。
您可以通过包含诸如可视化脚本之类的东西来使引擎更易于使用，这对于所有想要制作游戏但没有编程经验的艺术家来说都是一件好事，但这会邀请另一群人 - 即，没有任何技能的人。 对于那些转向使用文本编辑器进行编程的人来说，他们永远不会出现在他们的议程上，即使这意味着最终游戏会受到影响。 那些认为制作游戏唯一困难的就是编程的人，而有了可视化脚本，突然间，这个限制就被解除了。 这也并不少见。 看看所有让非程序员更容易完成某些事情的流行引擎——大量的铲子。 我并不是说您不应该包含可视化脚本，因为这意味着我们冒着获得铲件的风险，而是应该以一种阻止这类人认为他们可以只使用 Godotengine 来制作所述铲件的方式来实施它。
我的另一个问题是 Godotengine 擅长的事情之一，很多人喜欢这个功能，它与 git 配合得很好。 可视化脚本的问题在于它通常以某种二进制格式保存，如果您使用任何类型的源代码修订版，管理起来都是一场噩梦。 如果你必须实现可视化脚本，那么它应该以文本友好的方式保存。 如果那是不可能的，那就太难了。 我宁愿在 Godotengine 中以对 git 友好的格式拥有项目文件，也不愿拥有不能与 git 很好地配合使用的可视化脚本。
从实现可视化脚本系统所需的所有工作来看，您可以在没有可视化脚本的情况下在 Godotengine 中制作某些类型的游戏而不会损失任何功能、效率或性能，那么将其实现为有什么问题插件？ 我真的不明白为什么它必须成为引擎的核心部分。

只是为了添加我关于可视化脚本的 2 美分以及为什么我不喜欢这个想法：

我认为在代码管理和熟练度方面，连接任何 gdscript 文件中的节点的能力要好得多。

例如，使用可视化脚本（或使用类似于 C2 的事件表），如果您有超过 1000 个函数会发生什么？ 我相信浏览所有内容会使情况变得更糟。 我现在正在将我的 HTML 5 动作 RPG 游戏移植到 Godot（超过 10k + 行代码和超过 500 个函数）。 _（它基本上具有流放之路的所有功能，除了动画并且是多人游戏）_

使用可视化脚本对我来说是不可能的。 我认为我们和这里的 godot 开发人员应该更多地关注特性/错误压缩，而不是可视化代码事件表。 但这只是我:)

编辑：正如其他人所说，我猜也许对于较小的项目......但任何大的我都看不到它有用

construct2 中的事件表支持函数，它们的工作方式与 godots 相同。 一个简单的过滤器/搜索框将解决您列出的所有问题。

但是，即使它很受欢迎，godot 开发人员也不想做事件表方法。 我的印象是它更有可能获得类似于蓝图虚幻方法的东西。 这样，程序员将受益于添加到他们的武器库中的状态机编辑器

要在 vonstruct2 中组织可视化脚本代码，请将其放入可以折叠的组中。 这是连 gdscript 都做不到的——你不能折叠代码块。 所以在某些方面，事件表确实比 godots gdscript 编辑器有优势。

@reduz我在看 Pure Data，他们的做法非常简单。 看看这个

如您所见，键入“Bang”会将通用对象转换为 Bang 对象。

如果可视化脚本可以简单地成为 GD 脚本的扩展会怎样。 只需放置一个通用节点并为 ex 键入 Vector2，它将成为一个 Vector2 对象。 所以基本上每个类/对象也是一个节点。

要运行函数，我认为您可以获得另一个不是对象而是进程节点的节点，您可以键入 Vector2.dot 之类的内容，该节点将变成具有 2 个输入和 1 个输出的点节点。

计划在某个时候编写可视化脚本

你没有让人失望:) <3

既然已经有了 VisualScripting，这个 issue 是否应该关闭？

是的。

“我也以积极的方式微笑。
因为如果有一家像 Steam 这样大的公司，拥有大量由数以千计的优秀游戏开发者创建的游戏目录、开放和 DRM Free，对我作为一名游戏玩家来说将是一件好事。”
看看gog，它是一家出售drm免费游戏的商店。

回答 2015 年的声明跑题了，来吧:)