可视化脚本与编码[关闭]

Question

感恩节快乐， 首先，我一直在寻找可视化脚本是否是为游戏引擎而生的新事物。 让我给你看一些可视化脚本的例子

另一件事只是常规编码，例如在 IDE 中编写 c++ 代码 现在我两个都试过了，但我一直想弄清楚的问题是， 因为我尝试了这两种方法，所以视觉脚本似乎更容易，至少对我来说更容易理解我觉得当我连接节点时将它与我编写类似“播放器控制器”之类的代码进行比较是有道理的 我会告诉你我写一个敌人控制器花了多长时间！ 用 C++ 为播放器控制器编写代码花了我大约 2 个小时 虽然我只用了一个小时连接节点就使用可视化脚本制作了一个播放器控制器，但即使它是一个简单的过程，而且速度很快，但我对此并不满意，我开始更多地思考它的优势是什么编写 C++ 代码而不仅仅是连接节点？ 所以这是一个问题： 写代码有什么好处？ 使用可视化脚本有什么好处？ 两者的缺点是什么？ 我知道这个 Visual Scripting的优点它不像写c++代码那么复杂

编写代码也会比“已经创建的脚本”（Visual Scripts）更快

最后一个问题，如果你必须在两者之间做出选择，你会选择视觉还是编写代码？

注意：我决定在这里而不是游戏引擎网站问问题，因为在这里我可以找到“程序员”，在大多数游戏引擎网站中，他们都喜欢他们所说的“快乐方式”，即（视觉脚本）而不是（编写代码）的“悲伤方式”

我希望这次我没有问一些会导致太多负面投票的“坏”问题 :) 对我来说是感恩节;)

更新： 以下是有关我在虚幻引擎中使用的可视化脚本的更多信息，我从虚幻引擎网站获得 "虚幻引擎中的蓝图可视化脚本系统是一个完整的游戏脚本系统，它基于使用基于节点的界面从虚幻编辑器中创建游戏元素的概念。该系统非常灵活和强大，因为它提供了能力让设计人员几乎可以使用通常只有程序员才能使用的所有概念和工具。 通过使用蓝图，设计师可以制作原型、实现或修改几乎任何游戏元素，例如： 游戏 - 设置游戏规则、调整游戏条件等。 玩家 - 创建具有不同网格和材质或角色自定义的变体。 相机 - 制作新相机视角的原型或在游戏过程中动态更改相机。 输入 - 更改播放器控件或允许播放器将输入传递给项目。 物品 - 武器、法术、皮卡、触发器等。 环境 - 创建随机道具或程序生成的项目。" 我不认为有这样的事情，如果你必须让事情变得复杂，你需要为它编写代码（我的观点）

Answer 1

Visual Scripting 经常用于 Unity、Construct 2、Unreal Engine 等许多游戏引擎中。

这是为什么呢？因为它更容易。
用VS写的代码更容易理解，通常单节点就可以代替100行普通代码。
除此之外，它更易于理解，更容易理解正在发生的事情。
更重要的是，它易于学习，因此知识很少的人可以实际使用它。
有很多东西在这样的脚本后面进行，你实际上不需要知道发生了什么就可以使用它。

当您键入普通代码时，您需要知道自己在做什么，它允许熟练的用户获得更大的灵活性和性能（可视化脚本通常缺乏这一点）。尽管组织这样的项目要困难得多，而且代码很容易失控。但是，是的，性能和灵活性，这真的很重要。

例如，在某些引擎中，您可以只编写 Player Jump 或类似的东西，而您并不关心它是如何发生的，您甚至不必了解游戏机制、物理机制等。

如果我必须选择一个，我会根据项目进行选择。这与以下问题相同：
如果您可以在 Game Engine 中创建游戏或使用代码从头开始创建游戏，您会选择哪一个？

我们每个人都有自己的喜好。大公司倾向于创建自己的技术和引擎，以便他们可以更快地工作，并使工作更轻松。

所以 Adv/Disadv：

对比：
+ 快速发展
+ 易于维护
+ 易学
+ 易于团队合作
+ 经常便携
+隐藏了很多你不必关心的东西
+ 更清晰
+ 通常不包含“代码错误”
+ 笨拙友好（你不会忘记那个分号）
- 缺乏灵活性
- 你真的不知道发生了什么
- 您将学习如何解决问题，但您无法在特定引擎之外解决问题
- 通常比代码慢得多
- 你不能做性能更新
- 依赖引擎（每个都使用其他编码方式）
- 您需要了解每个引擎的工作原理
- 如果有引擎bug，你无法修复，你必须等待补丁
- 他们通常是有报酬的，或者他们缺乏可能性
- 哦，对了，可能性有限

代码：
+ 让您学习如何实际做某事
+ 给你更多的可能性
+ 如果您学习如何编码，则可以编写任何代码
（如果您学习引擎脚本，则仅限于它，您不会编写除游戏之外的任何其他应用程序）
+ 基本上没有限制（技术内容除外）
+ 如果您学习 1 种语言，则更容易理解任何其他现代语言
+ 您实际上可以控制正在发生的事情
+ 让您真正了解如何编写算法和程序
+ 代码独立于公司
+ 大多数东西都是免费的
+ 它可以比编写脚本快得多
- 更难学习高级的东西
- 更难维护大型项目
- 你可以笨拙地破坏东西
- 经常让别人难以理解
- 不如可视化脚本清晰
- 在某些时候它很难维护
- 很多平台相关的东西
- 要真正做某事，您需要学习相当多的东西

选择实际上取决于情况、公司、团队偏好、截止日期、平台、目标等。

我希望我为你整理了一下:)。

Answer 2

如果您查看 UML，它是一种建模语言，几乎涵盖了您可以使用代码执行的所有操作，并且非常适合对系统进行建模，但是在用于程序生成时它就不足了。基本上，与编写等效代码相比，描述真正复杂的交互需要更多的图表和更多的图表。

采用简单的 5 路 switch 语句。写起来容易，画起来很复杂。对通过系统的不同路径进行建模可能会变得非常麻烦，而且速度非常快。

当存在简单的数据路径时，代码生成的拖放连接模型非常有效，但是一旦您谈论状态机之间的复杂交互，它就会变得相当复杂。在过去，我注意到这类可视化建模系统最终会在连接上编写脚本以适应复杂性，这通常最终使它们比直接代码更难理解，并且更难找到事情发生的地方。

最后，语言级别越高，您在性能和控制方面必须做出的权衡就越多。所以这些越重要，语言选择的层次就越低。如果您正在编写一个对时间要求很高的设备驱动程序函数，您最终可能会编写汇编程序，而用于自动化的高级菜单系统可以很高兴地用脚本语言编写。视觉语言是一种非常高级的语言，因此权衡可能非常高。然而，上市时间往往会随着语言水平的提高而下降。所以你想在某件事上投入多少时间和精力也成为一个因素。

Answer 3

“可视化编程”既不是“新”概念，也不是游戏编程的新概念。

这也是一个非常广泛的概念：“可视化编程”的概念在许多不同的领域都有很多应用。

您提到了“游戏编程”。另一个是“教育”。例如：

Hour of Code: Coding with Anna and Elsa