可视化编程作业



现在搞语言的牛皮一个比一个能吹

如果你宣称 ↓

但又没法定义出下面这堆东西的话 ↓

data Eq : {a : Type} -> a -> a -> Type where Refl : Eq x x sym : {x : a} -> {y : a} -> Eq x y -> Eq y x sym Refl = Refl replace : {a : Type} -> {x : a} -> {y : a} -> {f : a -> Type} -> Eq x y -> f x -> f y replace Refl p = p

就是吹牛

ps. 这个例子

如果真的是延迟求值的话——你用到了 coinductive 你知道么？

惊了，第一次听说 Category Oriented Programming hhhhhhh

我还是老老实实造我家的

前言

“人人都应该学习编程，因为他教你如何思考。”——乔布斯

作为一名嵌入式小白呢，我一直认为，如果把底层的硬件驱动和编程环境的搭建当成学习生活中大量的工作的话，那一个人的创意将被抹杀，因为他在一大堆底层配置当中就已经丧失了斗志。

这也是为什么相较于51单片机和stm32标准库而言，stm32cubemx会受到大量开发者的追捧。相对于这两款大众嵌入式开发平台而言，如今更加大火大热的Arduino平台以及一些衍生平台是如何在嵌入式领域和创客领域逐渐拿下大量用户的原因。

所以呢，对比了一下从51单片机到arduino可视化编程的同学的感受，突然间嵌入式可视化编程进入到了我的小世界。

最近就开始在网上大量的搜刮嵌入式的可视化编程软件，同时对可视化编程的前世今生做了一些了解。

下面是正文

一、可视化编程的前世今生

这里就简单介绍一下可视化编程的前世今生吧，

当年Google和MIT合作建立了一个 App Inventor项目，后来MIT退出了自己的一个Scratch在线编程平台，可以编写各种动画，但Scratch本身并不支持硬件编程。

后来Google出了Blockly图形化编程库，提供开发者基于他的库去开发各种图形化编程软件。现在在Blockly官网上看到，Scratch和App Inventor也都使用了Blockly核心。

以上提到的软件皆为开源的，包括Blockly内核，所以近年来有很多根据Blockly内核开发的可视化编程软件，其中包括的不乏有：Ardublock、S4A、Webduino、mBlock、好好搭搭、Mixly、KenRobot、Mind+……

二、 可视化编程平台的选择

当然呢，以上所罗列的可能不能代表全部，如果还有同学们喜欢用的可视化编程软件可以在下方评论区提出来哦。

以上所罗列的平台也不是都还能用，有的官方已经停止更新了，有的呢就是要死不活的状态，经过大量的搜集资料，我只体验了三款软件，分别是Scratch、Mind+和Mixly。

（首先声明一下，我可没有拿任何的广告费，所有的说辞都是我主观的展现XD。）

1、Scratch

​其中Scratch呢，是之前在手机上安装的手机APP，用户体验上还是蛮不错的，但是它不支持硬件编程，作为主业是做嵌入式开发的来说，也只能留着以后给小朋友用吧。动画编辑不需要很多学习成本，可以学习一些编程思维快速培养起编程兴趣（没有底层和硬件层的麻烦）。

2、Mind+

​​该软件由DFRobot旗下子品牌蘑菇云创客教育发布，可以自动转换Python/C/C++等语言。一个软件可以进行动画编程和硬件编程，可以设计完动画之后，进行实物编程，如果要是做少儿编程教育的培训机构来说应该是非常方便的工具。

​​我个人觉得，他的界面配色和动画小人比Scratch做得好，可能会更受小朋友的喜欢。

​​但他的痛点也是我为什么没有在最后介绍他的原因，就是他所支持的开发版都是DFRobot自家平台上的开发板，所支持的传感器和执行器拓展板都属于DFRobot

3、Mixly

​Mixly（米思齐）是由北师大创客教育实验室团队开发的开源软件，他的界面配色以及官网前端并没有Mind+做得好，但是呢他所支持的硬件板子是非常丰富的

关于他们本家的系列产品我也没有使用过，但它还支持STM32F103是我没有想到的

还有一些拓展板卡，他们的更新速度是非常频繁的，以至于在下载的安装包里面放了一个“一键更新.bat”批处理文件用于快速获取官方发布的更新包，其他硬件平台的支持性也是非常全面的，我那手边的一块ESP32-WROOM试了一下WIFI连接，并没有查询任何的资料，上手即可使用。

三、关于最近配置ESP32编程环境和Mixly感慨

1、ESP32环境配置

虽然ESP32可以使用Arduino编程，相对于我之前用的STM32来说已经足够“人性化”了，但这可视化却是可以减少很多在代码上所花的时间。

如果使用arduino的官方平台，需要下载ESP32的支持库才可以使用，我记得当时为了配置ESP32的支持库也花了不少时间，因为官方软件上的下载速度很慢，所以我自己的Github上一个一个下载好库文件后放到指定目录里面才可以使用的。

而且arduino的编辑器正式版都不能跳转到定义等一些常用操作，即使是arduino2.0也是不太好用，曾经我还在VScode上安装过arduino支持包，但是每加载一个工程都需要在VScode的配置文件里面添加文件路径，当时在C盘的十层文件夹下面疯狂的找文件和文件头包含。后来摸索到了可以在esp32的头文件夹后面加上“”后可以通配之后的文件，但是呢，还是会因为头文件明相互冲突所以要细分包含。

后来也使用了VScode里的Platformio添加ESP32的库，还蛮好用的。

还有就是最近配置在Linux下面配置OpenCV的环境，以写成一篇分享，可以去参考一下Linux下OpenCV的安装与测试成功教程（解决E: 无法定位软件包 libjasper-dev、无法找到directory `opencv.pc‘、fatal error:“highgui.h“)_Boxjod的博客-CSDN博客

2、关于Mixly的一些感慨

但是这个Mixly呢，库文件几乎一键安装，甚至端口号也没有让我选，就直接可以编译下载了，简直就是傻瓜式插上线，拖动几块积木，点下载就可以用了。

甚至更好的是有Mixly的组件包，可以直接可视化查看所有的功能函数应该如何写，模块直接对应了常用的编程代码模式，比如连接出的阻断循环，如果没有连接上就一直在那个循环里，代码比我自己写的代码都规范。

个人觉得Mixly这款软件对于使用arduino系列产品而言高级应用也何尝不可。

​就连前几天学的MQTT和Blynk网络组件在Mixly里面看着都是那么的直观和简单

​四、结尾

以后可能会专门出一些关于Mixly的创意作品和文章，谢谢大家看完这篇文章并关注我，你的时间是对我最美的赞美！

nodered和蓝图这种节点编辑器确实现在是一个潮流趋势，代替脚本逻辑编程，可以做到无代码做规则业务流程编排。

不过UI前端图形界面复杂很多，因为UI界面比如一个按钮，属性就可以有非常多，有样式的、事件的还有，UI就是要随意配置这样交互功能、界面样式才能适应各种需求。

这样看来随便一个UI组件，如果用节点编辑连线来做业务逻辑，UI组件的属性就会很多，甚至说UI组件的属性就是API暴露出来的！这样才能通过连线节点编辑灵活编程。

目前来说nodered不适合做UI界面，做简单的业务规则流程是没问题的。

不过最近看到有国产的一款前端零代码工具UIOTOS可以看看，挺新颖，专门是做UI前端界面的节点编辑。不过还有点很有新意，而且也有点技术，就是专门提到的界面嵌套，这个确实挺有必要，我们用蓝图连线就算只是做逻辑，连线多了也复杂的不行。

嵌套这玩意，我之前也想过借鉴iframe的这种页面嵌套，但是实现起来太麻烦！UIOTOS这个玩意仔细了解，确实很多我想到的，上面都有实现了。nodered倒是可以参照uiotos的设计思路二次开发支持下，没有嵌套，就算有ui节点在nodered生态里，感觉都没卵用，越复杂的弊端越明显。

mikehadlow于2018.10.1在他的博客上写了篇文章:Visual Programming - Why it’s a Bad Idea。他在reddit上发了个同名帖子:，一石激起千层浪。截至今日(2018.11.21)，帖子获得414票的赞同，383个评论。考虑到它只是技术话题，算是非常热门了。

今早有人将这篇文章推到hacker news。我读完文章，顺带将同名帖子下的所有讨论一并读了。关于图形化编程，这是我近来读到最精彩的争论，做个梳理。

我最初给那篇帖子点了个踩，后来改为点赞。起初点踩的原因是，我不赞同文章的观点。但我认为那是一篇好文章，至少也算抛砖引玉，希望它被更多人读到，引起更广泛的讨论和思考。它值得一读，也值得一驳，这是我给它点赞的原因。一篇文章值得被反驳，是一种赞美。

这听起来有些古怪。如果有人跟我说，我写得东西，值得他花半个小时来反驳，我会觉得这是一种莫大的荣耀。要知道，太多的文章混乱不堪，根本不值驻足细读，更别说理解之后再反驳了，你恨不能捏起鼻子赶紧跑开。

在哲学圈，有这么一条不成文的规矩：对一位哲学家最大的尊重，就是去反驳他的论证。

罗素在《西方哲学史》卷三.近代哲学部分，写霍布斯时说:

把霍布斯和以前的政治理论家们作个对比，他的高明处显露得清楚极了。他完全摆脱了迷信；他不根据亚当和夏娃堕落人间时的遭遇发议论。他论事清晰而合逻辑；他的伦理学说对也好错也好，总是完全可以理解的东西，里面没使用任何暧昧含混的概念。除开远比他见识狭隘的马基雅弗利，他是讲政治理论的第一个真正近代的著述家。他若有错处，错也出于过分简单化，并不是因为他的思想基础不现实、偏空想。为这个缘故，他仍旧值得一驳。

你看，“他仍旧值得一驳。"的原因正是因为他有如此多的优点。

大卫·休谟（David Hume，1711—76）在1739年出版他的《人性论》（Treatise of HumanNa ture）后，期待着猛烈的攻击，打算用堂堂的反驳来迎击。殊不料谁也不注意这本书；如他自己说的，“它从印刷机死产下来。” 。你都准备好了在一次伟大的争论中，让观点屹立于世，却不料期待的对手始终没有出现。

我有个小人之心的想法，故事中持剑的少年，内心是期待着那条劫走公主的恶龙出现的。我甚至不知道持剑的少年究竟喜欢公主多些，还是喜欢恶龙多些。

近期正在尝试写文献综述风格的文章，本文是这个系列的第三篇。

可视化编程为何是个糟糕的主意

我先翻译mikehadlow对可视化编程的攻击，在文章后半部分，给出reddit社区用户对这篇文章的反驳以及我个人对此的反驳。

mikehadlow在Visual Programming - Why it’s a Bad Idea中写道:

可视化编程语言允许编程者通过操控图形元素不是通过输入文本命令来创建程序。众所周知的例子是Scratch,一个来自MIT(麻省理工学院)的可视化编程语言，用于教孩子编程。Scratch的优点是让新手和普通用户能够轻松地开始编程。

在20世纪90年代，有一种非常流行的运动，即通过所谓的CASE工具将这类工具带入企业，企业系统可由UML定义和生成，无需雇佣专业开发者。这涉及“round tripping”的概念，在其中，系统可以在视觉上建模，程序代码从模型中生成，并且代码的任何更改都可以反映到模型上。这些工具未能兑现承诺，大多数这此类尝试现已基本放弃。

除了一些非常有限的领域外，可视化编程未能成功。这基本上归因于以下对编程的误解：

1. 基于文本的编程语言使得本质上简单的过程变得混乱。
2. 抽象和解耦在编程中处于边缘位置，作用不大。
3. 为支持编程而开发的工具并不重要。

第一个误解认为软件开发存在很大的门槛，因为文本编程语言模糊了编程的本质。Scratch在教育学家中的流行属于这种误解。该观点认为编程实际上非常简单，如果我们以清晰的图形呈现它，将大大降低创建和阅读软件的难度，学习曲线将平缓。这种误解源自未能理解文本代码写就的典型程序，转而想将它转换为框和箭头等图形元素。如果你这样做，很快就会发现一行代码经常映射到几个图形块上，一个简单的程序包含数百行代码是很典型的。这将转化为成百上千个图形元素。在头脑中理解如此复杂的图形往往比阅读等效的文本要困难得多。

大多数可视化编程语言应对上述问题的策略是使用“块”来代表更复杂的操作，以便每个可视化元素等同于大块的文本代码。可视化工作流工具是罪魁祸首。问题是需要在某处定义此代码。它变成了“属性对话编程”。视觉元素仅代表最高级别的程序流程，大多数工作都是隐藏在框中的标准文本代码中完成的。这种做法，两边不讨好。一边是，文本编程没有现代工具的支持。另一边是视觉元素只能由有经验的程序员创建，只能通过阅读它们的文本代码来理解。因此视觉元素的大多数假定的优点都会丢失。在视觉“代码”和文本代码之间存在着阻抗不匹配，编程者必须在两者之间切换，时间都浪费在理解图形化工具上，而不是解决手头的问题。

这让我们产生了第二个误解，即抽象和解耦是外围问题。可视化编程假设大多数程序都是简单的程序序列，有点像流程图。实际上，这是大多数新手程序员想象软件的工作原理。然而，一旦程序变得比一个简单的例子更大，复杂性很快就会压倒新手程序员。他们发现很难推断大规模的程序代码，并且经常难以大规模生产稳定有效的软件。编程语言中的大多数创新都是尝试管理复杂性，最常见的是通过抽象，封装和解耦。面向对象和函数式编程实际上只是努力控制这种复杂性。大多数专业程序员将不断抽象和解耦代码。实际上，好的和坏的代码之间的区别本质上便是这样。可视化编程工具缺少有效的机制来实现这些，它们让开发者置身于1970年代的BASIC中。

最后的误解是可视化编程者可以在没有现代编程工具的支持下编程。考虑代码编辑器和IDE的长期演变。例如，Visual Studio支持高效的智能感知，可以单独查找基类库中可用的数千个API。缺乏良好的源代码控制是大多数可视化编程工具的另一个主要缺点。即使他们将布局保存为文本格式，比较代码差异(diff)几乎没有意义。对大量的XML或JSON进行“git blame”非常困难。有些事情对程序的功能执行没有任何影响，例如图形元素的位置和大小，仍然会导致元数据的变化，这使得观察差异(diff)变得更加困难。文本编程语言已经学会将代码单元分成单独的源文件，因此系统的一部分的更改很容易与另一部分的更改合并(merge)。可视化编程工具通常坚持每个图(diagram)单独存储，这意味着合并变得困难。当难以解析差异的语义时，这将更加困难。

总之，可视化编程工具提供的优势：使程序更容易创建和理解，几乎总是海市蜃楼。它们只能在最简单的情况下成功。

作者更新

我可能错误地使用了Scratch的截图，并将其用作我的第一段中的主要示例。我不是一名教育工作者，我对Scratch作为一种教学工具的有效性并没有真正的看法。许多人提到它在教学编程方面非常有用，特别是对儿童而言。任何将人们引向精彩纷呈的编程世界的东西都是值得欢迎的。我真的不打算将此帖作为对Scratch的批评，我主要批评人们听过的那些流行的可视化编程系统。

Reddit上的小伙伴们提到的另一个反例是静态结构工具，例如UI设计工具，数据库模式设计工具或类设计工具。我同意他们非常有用。任何有助于可视化数据结构或程序的大规模结构的东西都是好东西。但这些不足以支撑他们的论点的。PowerBuilder等90个试图构建在可视化之上，用以创建一个完全无代码的开发环境，都失败了，就证明了这点。

反驳

mikehadlow关于Scratch的观点，遭到reddit上很多用户的反驳，于是他在文章结尾处加了一段更新说:

我可能错误地使用了Scratch的截图，并将其用作我的第一段中的主要示例。我不是一名教育工作者，我对Scratch作为一种教学工具的有效性并没有真正的看法。许多人提到它在教学编程方面非常有用，特别是对儿童而言。任何将人们引向精彩纷呈的编程世界的东西都是值得欢迎的。我真的不打算将此帖作为对Scratch的批评，我主要批评人们听过的那些流行可视化编程系统。

mikehadlow在文章中盛气凌人，一副"我是资深程序员，你们这些渣渣新手"的姿态。关于Scratch的部分，在reddit上被一通反驳之后，态度突然变得这么低，让人反倒没什么反驳的热情了。

我们来看看reddit上的一些讨论。

@victotronics评论说:

我赞同这个家伙的几点论述。传统编程无法从图形环境中受益。
但是，对于初学者来说，积木块是不可能出现语法错误的语句。这很有价值！你希望初学者考虑算法的结构，而不是分号的位置。我现在正在教授一所大学开始编程课程一个月。我仍然看到学生们得到一个编译器消息说它预期出现一个分号，他们很难确定在哪里或为什么需要这个分号。为什么编译器指向“for“并且说它需要分号？嗯，这是因为前一行。非常违反直觉。”
请主意文章中关于Scratch的截图。编程者正在为精灵编写事件处理程序。事件循环是环境的一部分，而这不需要明确编程！你可以让一个10岁的孩子写一堆精灵，每个精灵都有一个行为，如果你点击某些东西，就会发生一些事情。你能想象用常规语言进行的工作吗？
但我完全承认他关于抽象的观点。图形环境可能对此的支持多是蹩脚的，而抽象是优秀软件的本质。

@AlSweigart评论说：

Scratch专为8至16岁儿童设计,这是完美的; 它是图形化的，具有简短的反馈循环，并使简单的事情变得简单。
我知道很多程序员都希望教他们的孩子编码，并忘记了它是多么令人生畏和沮丧。Scratch的辉煌之处在于它做到了平易近人的同时，仍然是实际的编程（而不只是配置一下游戏）。但是，期待“可视化编程”将使编码变得更容易却不现实。

@yummybear评论说：

今天向我11岁的女儿介绍了Scratch，她喜欢它。仅仅几分钟后，她就让人物移动和跳舞，并对进展感到开心。Scratch中的积木块也被翻译成我们的母语，她可以阅读它们的行为。
我不确定文本语言是否会给出同样直接的反馈激励。

当我们谈论图形化编程的时候，我们在谈论什么

当我们谈论图形化编程的时候，我们在谈论什么呢？

mikehadlow以为他在谈所有的"图形化编程"，他假设所有的这些编程工具都吹嘘一样的优点，有一样的缺陷，所以mikehadlow准备写一篇文章，一次驳倒它们，把“可视化编程”通通归为糟糕的主意,他不具体谈哪个软件，不举例说明，唯一在开头举了Scratch的例子，结果又成为众矢之的，只好改称:

我不是一名教育工作者，我对Scratch作为一种教学工具的有效性并没有真正的看法。

而reddit上的用户则代入各自的经历，以为mikehadlow在谈他们各自熟悉的图形化编程工具，有人在吐槽Labview，有人在拥护虚幻引擎中的图形工具，有人在赞扬Scratch...于是我们一时不知道大家在争执什么。这场面简直像哲学家们对意义、真理、道德的争论，大家自说自话，全然忘了问题是什么。

那么问题是什么？我们究竟能否用"图形化编程"来描述所有与图形有关的编程，它们是否可以混为一谈？是否都拥有一样的缺陷？是否需要再做细分，分门别类来谈论？是否更多的例证，而不是泛泛而论？

@teerre对此说得比较尖刻:

阅读他的文字我不禁认为他实际上从未使用过任何可视化编程，而只是在谈论他在自己的脑海中所构成的猜想。缺乏实际的例子。

Scratch的缺陷

总的来说我是喜欢mikehadlow这篇文章的，正是因为喜欢，我才决定好好反驳它。尽管他的讨论，显得有点粗糙，mikehadlow本人对Scratch也缺乏必要的了解，但他提到的“图形化编程共有的问题“，其中至少有一点，Scratch确实存在:

缺乏良好的源代码控制... 对大量的XML或JSON进行“git blame”非常困难。对程序的功能执行没有任何影响的事情，例如图形元素的位置和大小，仍然会导致元数据的变化，这使得观察差异(diff)变得更加困难。

@balefrost在帖子下的评论，比mikehadlow的原文更为精彩，也更为深刻。balefrost评论道:

我认为使用Scratch教学基本编程没有任何问题。在我看来，图形化编程大的缺点在以下方面:
使用空间经常不足。我见过的大多数图形化编程环境都有节点与线的连接。因此需要将节点间隔得足够远，以使连线有足够空间，并限制你将获得的线路交叉数量; 即便如此，无论给它们多少空间，总会有一些交叉线。你可能必须手动布线，以获得好看的图表。最终会投入大量时间和精力来制定“漂亮”（即“可读”）的图式。只要更改图式，所有仔细的布局工作都可能毫无价值.尽管Scratch不需要连线，但使用空间经常不足却也经常不足。而且积木组合如何分布好看也确实影响阅读。
文本编程语言还省略了图形化编程环境中存在的视觉装饰，因为我们不需要它们。VP(visual programming)中的框必须足够大，以便用户可以合理地使用鼠标来操纵它们，这是我们可以在文本语言中不必考虑的因素。
围绕纯文本文件构建了很多工具。我可以在任何我想要的编辑器中编辑纯文本文件。简化和合并纯文本编程文件通常是众所周知的活动，并且像Git这样的源代码控制工具针对纯文本文件进行了优化。即使VP环境将其代码保存在纯文本文件中，因为可视化编程文件需要编码算法信息以及空间信息，VP语言文件的差异通常比文本编程文件更嘈杂。
为文本编程编写代码生成器很容易，因为不需要太担心空间安排（只关心缩进）。用于可视化编程的代码生成器将需要担心放置节点的位置，这是一个非常重要的细节。
还有许多其他工具针对处理纯文本文件进行了优化。有一个丰富的文本编辑器生态系统，其中许多都对文本编程有很好的支持。可视化编程的编辑可能是一次性的。

@balefrost的这些论点都非常精彩，Scratch确实有这些问题。但我认为这些并不影响Scratch达成它的使命。而且像编辑器生态总是会随着时间和社区的壮大，持续改进。比如blockly就发展出了编译为6种文本语言的能力，并且可以还加入类型判断，用以决定可组合性，两块积木是否可吸合，这即便在文本编程工具里，也是很酷的功能，相当于静态分析了。而makecode则发展出了代码与图形积木的双向转换。这些都是非常先进的。而且在持续改进中。我们有理由保持乐观。

@balefrost继续说道:

我认为可视化编程将在非传统环境中取得最大成功。对于有大量条件逻辑的常规算法工作，我不知道可视化编程是否合适。我认为它在高级别工作中效果更好 - 将算法复杂性隐藏在预先封装的块中。我认为可视化编程适用于我们之前使用过脚本语言的一些任务。在我看来，Automator是一种向不熟悉Bash的用户提供UNIX管道功能的方法。
根据我的经验，一旦达到一定程度的复杂性，VP似乎真的会崩溃。我不能确定这是因为工具不足，个人经验不足，还是因为它是范式的根本限制。我的直觉告诉我，问题是根本的。

我的反驳

下边单说我的反驳。

由于我的兴趣主要关注图形化编程在教育这块的应用，所以我的焦点集中在以下系统:

• Scratch
• blockly
• Snap!
• GP
• Toy-Con Garage
• Etoys
• Squeak(smalltalk)

我将结合这几种图形化编程工具，来反驳mikehadlow的观点。

降低入门门槛

mikehadlow说

该观点认为编程实际上非常简单，如果我们以清晰的图形呈现它，将大大降低创建和阅读软件的难度，学习曲线将平缓。

我认为mikehadlow对Scratch存在很大误解，我甚至怀疑mikehadlow并没使用过Scratch。在Scratch社区，我们认为Scratch帮助降低编程入门门槛，我们并不认为编程实际上非常简单，我们认为入门编程应该尽可能简单，不应该让入门者太沮丧。使用Scratch构建大型程序确实会变得非常复杂，其中一些原因@balefrost在前头说得非常好，为了克服这种复杂度，Scratch的分支项目Snap!做了很多探索。

图形积木与文本代码的视野切换

mikehadlow在文章里说:

视觉元素仅代表最高级别的程序流程，大多数工作都是隐藏在框中的标准文本代码中完成的。
视觉元素只能由有经验的程序员创建,只能通过阅读它们的文本代码来理解。在视觉“代码”和文本代码之间存在着阻抗不匹配，编程者必须在两者之间切换，时间都浪费在理解图形化工具上，而不是解决手头的问题。

我不认为在Scratch3.0中, 这种切换是必要的，如果我们把编程积木视为一种好的抽象（我们应该这样做），那么我们是可以设计出原子积木的，它们彼此正交。编程者并不需要理解抽象背后的细节，这正是抽象的目标之一。正像他们在面向对象系统中，可以轻易使用别人定义的类。

我认为这是设计Scratch3.0这类积木化编程系统的核心工作。它并不容易，让一个积木可以运行是简单的，要设计出抽象得合理又正交的积木，极为困难，你可能需要一些研究PL的人以及交互设计的人，而且他们最好是一个人。

但你知道，大多数项目并没有精心设计，只是勉强能用，于是造成了使用者的灾难。

我们在codelab.club中做了很多有趣的探索，我们希望设计出尽可能正交的积木。此外我们允许大家在熟悉系统后，可以轻松去扩展这个系统，我们准备了通用的积木(EIM)。这里的核心概念是everything is a message，在这一点上，基于这个概念，能很轻松解耦。同时免费获得可组合性。我们是艾伦凯的忠实追随者。在这个领域，他一骑绝尘。

视觉元素仅代表最高级别的程序流程，大多数工作都是隐藏在框中的标准文本代码中完成的。

我不认为这是个缺陷，而认为这是个很好的特性，我在两种硬件编程风格的比较有做论述。

复杂度

然而，一旦程序变得比一个简单的例子更大，复杂性很快就会压倒新手程序员...编程语言中的大多数创新都是尝试管理复杂性，最常见的是通过抽象，封装和解耦。面向对象和函数式编程的所有类型系统实际上只是努力控制这种复杂性。大多数专业程序员将不断抽象和解耦代码。实际上，好的和坏的代码之间的区别本质上便是这样的。可视化编程工具缺少有效的机制来实现这些，它们让开发者置身于1970年代的BASIC中。

这是全文中我最为赞同的一段，如《SICP》在序言里说的，编程的本质是克服复杂度。但我认为Scratch/blockly这类积木化语言是有支持抽象的机制的。

先说Blockly。

@SanityInAnarchy在帖子下说:

我无法真正看到关于抽象的观点。函数只是一个容纳代码的块，包括一个“参数”块。一旦定义了，你就会得到一个调用你的函数的“调用”块，并且可以将值作为参数放到该函数中。这是抽象的大部分内容，而 http:// code.org 上的东西似乎很好地涵盖了它。

http://code.org使用blockly，blockly确实已经很好地实现了函数的机制。这个机制并不比大多数语言的函数功能更弱。而函数是实现抽象的绝佳工具。

至于Scratch则在解耦这块做得很好。消息机制是Scratch的核心机制。消息是绝佳的解耦工具，如果你逛一逛Scratch社区，就可以看到人们构建了许多令人惊叹的项目。它们中的许多并不简单，消息是帮助他们克服复杂度的核心工具之一。这个特性继承自smalltalk的设计原则:

计算应该被视为可通过发送消息来统一调用的对象的内在功能。

在codelab.club中，我们把这个概念进一步发挥，使用消息将积木块接入现实生活，我们做了许多有趣的探索

如果你对图形化编程充满热情，来codelab.club中与我们一起探索吧。

未来

我赞同@balefrost在前头提到的:

我认为可视化编程将在非传统环境中取得最大成功。对于有大量条件逻辑的常规算法工作，我不知道可视化编程是否合适。我认为它在高级别工作中效果更好 - 将算法复杂性隐藏在预先封装的块中。

我们相信可视化编程将在非传统环境中取得成功。我们在codelab.club做了许多探索，我们希望将可视化编程（我们更喜欢称它们为积木化编程）带入物联网与人工智能，我们已经做出了很多有趣的东西。

我们将继续探索这个领域，并且利用这种技术，让编程变得更加温和有趣，为每个人所用，去解决他们生活中的问题。

科技，以人为本。

除了codelab.club，这个领域还有很多有趣的探索者。艾伦·凯正在领导一个革命性的项目dynamicland，如果进展顺利，dynamicland将重塑人们对计算的理解。艾伦·凯在施乐实验室的工作，塑造了今天计算机的形态，我们认为他在dynamicland的工作将塑造未来。codelab.club计划明年三月份去dynamicland实验室参观。我们喜欢dynamicland的理想:将数字力量赋予给所有人，而不是收聚在技术精英手中。

dynamicland远不是一般的图形化编程，它把现实世界的真实物体视为编程元素，"现实便是计算引擎"，这是极为激进而令人热血沸腾的想法。如果你对此感兴趣，可以参考我此前的文章:"下一件大事"是一个房间。

收尾

最后我想用reddit两个用户的评论来结束本文.

@zushiba评论道:

虽然我同意文章的很多观点，但我想指出，当低级编程语言统治世界时，高级编程语言也遭遇类似的说法。
他们说:"这样做会混淆代码实际上在做什么，或者产生一代不知道编译器如何工作的程序员。"
我并不是说可视化编程会接管世界，但这些都是可以解决的问题。

@not_perfect_yet评论道:

我不喜欢看到人们诋毁一个没有真正探索过的想法。如果我们现在扔掉火并回到树上，我们将永远不会使用内燃机。

参考

• Visual Programming - Why it’s a Bad Idea
• reddit Visual Programming - Why it’s a Bad Idea
• Visual programming language
• 可视化编程Langauges的未来
• 第四代编程语言
• Squeak
• Etoys
• Snap!
• Toy-Con Garage

IVX是一个功能非常非常强大的平台。到底强大到什么地步呢？

我与IVX的初次邂逅源于三周前。第一次打开IVX时，感觉其界面有点像Photoshop，黑色的背景，左右两边整齐的工具栏以及中间的主操作区域。我的学习之路始于Github网页的UI模仿，可以说是真的很轻松。IVX的UI布局组件并不是很多，但每个组件都有着丰富的功能，因此使用这些组件是非常灵活的。比如行、列这两个组件，只用这两个组件就足以搭建出一个网页的基础轮廓。IVX作为0代码平台的先驱者，最大的特点自然是让使用者不再受到传统代码的束缚。前些年在日本留学时我曾学习过HTML语言，可以说，用HTML语言写出一个仿Github网页是一个浩大的工程，但用IVX平台只需要几个小时（使用者甚至还是新手的情况下）。因为所有的组件只需要拖拽和设置属性，并不需要实际代码的写入。

我的第二个项目是备忘录的制作。说实话，进展的速度有点超乎我的想象。那才是接触IVX的第三天。在做备忘录的过程中，我真正感受到IVX的灵魂所在------逻辑。应该说所有编程语言的核心都是逻辑，也就是所谓的算法，只是IVX脱去了编程中程序语言这层外衣，将核心逻辑直观地展现在人们面前。因此不再需要像以前写程序那样，把很多的时间用来debug，用在了编程语言语法的修正上。逻辑层级的搭建像极了下一盘大棋，我们在实现具体功能时，并不是走一步看一步，而是在着手操作之前，先做好构思，搭建好整体架构，进而逐步实现，这样才不容易出错。否则如果一开始构思都没有，很容易做到一半发现得从头再来。在这不得不提一句，一定要善于利用调试功能，在恰当的地方设置断点，方便我们找到逻辑问题所在。

紧跟备忘录之后是实现一个简单的投票功能。这个环节的核心是数据库的使用。没错，在IVX刚学会前端立马就能开始学习后端了。对于数据库的操作也是非常的简单，可以在后台增添服务对数据库进行操作，甚至可以直接通过前台对数据库进行调用（不推荐）。数据库让H5和小程序有了生命力，使得它们能够对用户数据进行存储和操作。此外，数据绑定也是非常重要和便利的。前台组件的绝大部分属性都是可以进行数据绑定的。

下一个做的是手机论坛，充满了挑战性。因为它集合了之前所有项目的重点。尤其是多个数据库的使用，数据库之间的联系，以及数据绑定的灵活运用，都是有一定难度的。此外，回调功能、条件判断、循环创建等等，都是重点和难点。

经过这么多天的学习和实操，真的让我感觉IVX是一个功能非常强大的平台。很多复杂功能的实现，在这个不需要编程的平台里显得是那么的简单。每当我实现一个功能时，会很有成就感，不再像传统编程那样枯燥乏味。我们知道，编程的核心其实就是输入数据，处理数据和输出数据。算法就是如何处理这些数据从而输出我们想要的结果。在IVX里，只要你的逻辑缜密，精妙，就能很快实现你想要的功能。而且在IVX的论坛里，云集了众多能人高手，分享经验和方案，也有各种demo可供参考，颇有github的感觉。在我看来，零代码是未来发展的必然趋势。就好比从机器语言到汇编语言再到高级语言，每一步的变革都是为了简化语言本身，突显逻辑的重要性，而零代码可以说是对高级语言的进一步跨越。相信未来会有越来越多的人加入零代码，加入IVX。

十几年前就深度应用过低代码的码农/顾问来讲讲低代码的应用经验和分析

起初

搞出低代码的目的是为了少写或者不写代码，让非码农可以简单滴配置业务流程

但是业务流程有标准的，也有特殊和个性化的

低代码只能搞在相对标准的业务流程中做部分定制

标准的业务流程总有一天会被固定下来，

非标准的业务流程一天一变而且参数会越来越多让低代码没法覆盖

所以

低代码的生态位永远会被固化流程 + 标准界面配置侵蚀，

同时又要去追那些新的业务特性，为低代码环境增加新的feature

最终

被标准界面侵蚀的部分成为了带配置项的固定流程，

个性化的部分复杂到变成了必须要用标准格式和语法来描述的东西，成了新的语言和开发环境

低代码的巨大劣势：

可视化编程经验分享怎么写
1. 版本控制差：
1. 图形化的一堆方框+连线怎么搞diff ？ 如何AB测试？搞错了怎么回滚？分布式事务（现实的分布式事务）如何解决？
2. 图文混杂导致注释混乱：
1. 程序员的注释习惯在很多情况下都无法保证，对非程序员怎么让他们老老实实写注释从而确保后来接手者能看懂？
3. 信息密度低：
1. 图形化更擅长表示逻辑 ，但是细节多了就会眼花缭乱，为了不眼花，只能放弃信息密度
4. 环境依赖度极强：
1. 部署了一个应用以后想要迁移到其他家需要付出巨大成本和承担巨大风险

十二年前我就用过低代码了

有个软件叫Captiva Dispatcher ，和 InputAccel一起使用，用来批量化地把扫描来的纸上的信息分类，归档，审批，数字化。通常用来处理发票，保险单，税单，物流出入库单据等等东西。

经典的发票流程就是读入发票，分类（发票/冲红/附件/其他等等类型），识别供应商，确认OCR模板，OCR读入数据，人工核验审批。 每个业务模块会对应一个软件模块。

刚开始，我们使用VBA语言和开发商的一种私有类库做开发，把一个个模块连接起来形成一个“生产线”，开发环境类似VB6或者vba。

这个软件开发商是EMC子公司，大概2010年左右推出可视化开发环境 Capture Flow Designer （低代码来了）靠拖拽就可以完成业务流程搭建，还做了web服务，可以用在网页上远程监控生产环境，并debug。

当然有好处

1. 可视化对于业务逻辑的展示更加清晰，CFD推出后客户的业务流程纷纷变得巨长巨复杂巨个性化
2. 可视化对于业务逻辑的展示更加清晰，商务和销售都可以自己拖出个简单流程展示给客户看POC
3. 可视化对于业务逻辑的展示更加清晰，因为流程上的每个模块的处理能力都可以单独收费，多用一个CPU核心，每分钟多处理10张纸都要额外加钱，所以商务和销售在算账上可以少一点遗漏。

但是

1. 客户的项目成本实际上提高了（因为可视化帮客户放飞了想象力，所以流程复杂度经常超过实际需求）
2. 实际技术门槛并没有降低，可视化界面玩得好的仍然是当年写代码好的那帮人，因为你的每一次拖拽都会被UI翻译成程序代码
3. 客户赋能并没有实现。 一个软件在接近行业标准之前，从业者的学习意愿其实是相当低的。
1. 首先，低代码相关的“拖动编程”技能和具体的业务技能的距离相当远。
2. 所以跳槽了就没用的东西，不是职场核心竞争力
3. 假设一个HR用某低代码平台管薪酬和绩效，跳槽以后还用回excel或者换了别的低代码平台，那低代码就白学了

总结：

1. 在成为行业标准之前，低代码相关能力的职场价值并不高，也不会有生态（钉钉有机会）
2. 低代码的未来仍然是类似SAP的用几千个参数 + 代码进行配置的行业软件（低代码产品经理通过客户生成的内容【暂且命名CGC】，掌握行业知识以后实现固定的产品）
3. 低代码唯一能赋能的，是基层和中层管理者，只有他们有利益点和以及必要的视野来用低代码提升效率
4. 试用玩票不代表商业部署，商业部署了不代表业务应用，业务应用了不代表从业者遵守规则，从业者遵守了规则不代表项目成功，这是低代码项目的成功漏斗。
5. 最终落地点还是SaaS的企业服务
6. 基于钉钉和阿里云相关业务线希望做“商业操作系统”的目标，钉钉风格的低代码，的确有可能是实现路径之一。

秉承着我专业优秀的：“我们可以不会、但绝不能不知道有这东西”的原则，我决定开个关于Unity PlayMaker的坑。这个坑里将会尽量收录PlayMaker全部节点的作用，不仅意在方便更多人无代码编程，更是一个备忘录一样的东西。

——忘了什么时候更的

忘记了这东西有个官方文档，先贴在这里一个网址：https://hutonggames.fogbugz.com

另外的话，我在unity也摸爬滚打几年了，这个帖子大概会转向一些实用playmaker玩法案例的介绍.......

红烧肉Kiri：【Playmaker】之核心概念与思想

前言

前言包含：什么是PlayMaker，什么是有限状态机FSM，怎么使用PlayMaker，怎么食用这篇查阅贴，以及类似的插件。

1. 什么是PlayMaker
1. PlayMaker是Unity可视化编程插件，不同于Bolt，它只能使用有限状态机FSM的方式进行编程（足够了），它将有限状态机的实现完整的从代码挪到了节点。
2. 什么是有限状态机
1. 有限状态机FSM是一种编程思想（建议知乎或百度搜索），它的核心是将物体所有可能状态进行穷举，并集合到一个整体（的状态机）中。物体生命周期内，物体有且仅有一种状态、物体的状态可以在不同条件下相互转换。由于同时只能有一种状态，有限状态机比较易于管理。
2. 有限状态机是编程方法的一种，还有一种思想叫做行为树，二者各有优劣，都有对应的unity插件。
3. PlayMaker的使用很简单，如果你了解了有限状态机的构成，那么将更有助于理解：
1. 状态机是母集合
2. 状态机下穷举了物体所有状态
3. 每个状态中，你可以调用Unity内置函数；访问、修改预设的变量；给自己或其他物体及状态机发送消息；etc.....
4. 你可以用代码访问PlayMaker或用PlayMaker调用代码，但其给的函数库，基本能满足大部分需求以做到无代码编程。
4. 这篇文章是查阅性质的，我会根据PlayMaker提供函数库的分类，每一个分类出一篇文章（如Transform、Time、UI等）。我会在这篇文章做个小栗子，给没接触过状态机的朋友简短的介绍。
5. Unity可视化编程的插件很多，我所知的比较强的有：
1. Bolt：我就是可视化编程
2. NodeEditorFramwork：好像也是可视化编程，和上面的类似
3. PlayMaker：有限状态机可视化编程
4. NPBehave：行为树可视化编程
5. InteractML：机器学习可视化编程
6. ShaderGraph：内置Shdaer可视化编辑
7. AmplifiedShaderEditor：更成熟的Shader可视化编程插件
8. VFXgraph：内置VFX可视化编辑
9. ODIN：非常强的Unity编辑器扩展

总之，有什么想学的想了解的，抱住Brackeys教父的大腿就完事儿了。（下面是Brackeys推荐的插件视频）

另外，PlayMaker是付费的，不过大家可以上网找一找或者上淘宝，也可以私信我，如果觉得好用建议花点钱支持一下原作者。

序：分享一个简单的有限状态机例子

Unity教程 火爆FSM插件PlayMaker视频教程_哔哩哔哩_bilibiliPlayMaker基础教程_哔哩哔哩_bilibili

正片：

Transform部分Action：

待整理......

前言

第一次在知乎写文章，文笔不好请多见谅，主要是为了写一篇关于我对TouchDesigner（TD）这个神仙软件的一些看法。先说明一点，我不是为了告诉自己有多牛逼，毕竟只是工作了才两年的小白，而是每逢一年我都会总结自己的学习经历，希望你也能看看我上一年简单的总结。

这一年我想用文章的形式去总结，并且，回首自己的同时我是怎么学习TD的，如果对未来的小朋友们入门时能有所帮助的话，那我的头发也就没有白白牺牲。

还想说一点就是TD不再是一个不可逾越的工具，以现在入门TD纯靠网络上自学一点压力都没有，但还是记住它仅仅是工具而已，真正会玩的还是靠自己的想法。

自我介绍

Wingto，学习TD已2年并运用到商业项目，现在杭州工作，个人正运营三个平台：

微信公众号：THE3

B站：WingtoKwong

微博超话：TouchDesigner社区超话

网友提问

1.TD能干什么

强烈推荐TEA社区生动形象地介绍TD的视频，但我也有可以简短的说就是（能做大多数的新媒体设计与艺术的作品）

2. 学了之后又忘记了

TD跟其他软件一样，都是是多练习多做才会熟而生巧，你该不会在学PS的时候会用一个小本本去记住每一个元件的用途吧，一般都是多用就记得了的，并且根据自己的需要达到的目的去学习。

3.没编程基础还有机会吗

我本科是计算机科学与技术，可能大家听到这儿心里会想（难怪..），但是！在大学里我大多的时间是学习设计，从平面设计到产品设计，完全不按路子走，不上课，回宿舍自己玩设计....

至于编程我也是很抗拒的，因为C++真的很恶心 - - ，基于这种一半计算机一半艺术设计的背景下，直至大学毕业才偶遇到这个软件简直相见恨晚，但没关系，有心不怕迟，所以没编程基础真的有机会，勇敢的学吧。

那应该怎么学编程？应该在哪里入门？这里我非常推荐MatthewRagan的python in Touchdesigner系列教程，全部免费！

（欢迎在评论区下提问更多，或者到我们的超话，会有更多大神回答你，平时我不懂的都会在那里提问~）

怎么学

1.软件的工作逻辑

.像我的话从来没有出国的经历（虽然英文也不是很差），但是建议国内的小朋友们可以先用中文的教程去了解TD这个软件的工作逻辑然后再看国外的教程（后面会总结）。

2.多看

ins

vimeo

youtube

3.多模仿

可以依葫芦画瓢的跟着教程走，然后再回过头去捉摸，会有新的发现。

4.举一反三

从而了解这个元件的用法，对某个元件不明白的话，可以点某个元件上的问号。

然后就会跳转到对应的元件介绍，如果想知道如何运用，可以点击help - snippet 得到对应的元件是如何运用的。

5.进入项目

这是根本的，仅仅拼命的学习但不创造财富也是空谈。

6.TD不是万能

实事求是，拒绝'有神论'。

总结

除了学习软件本身以外你会不知不觉发现，你还需要学更多其他的东西，所谓的跨界就从此开始，比如：

编程，硬件，用户体验，舞台设计，空间设计，等等....，所以这一行你还身兼多职，你可能会考虑很多东西都是蛮正常的，不要停止学习总没错。

最后干货

在这里总结了一些我知道的up主，可能我还有其他的没找到，也希望在评论下方告知其他小朋友。

国内：

TEA社区

FifthChat

交互坤

Blackbody_Emission

WingtoKwong

国外(太多筛选其中五个)：

MatthewRage

TouchDesigner官方YouTuBe

paketa12

exsstas

INTERACTIVE IMMERSIVE

待更新。

Transform属性是我们接触Unity时第一个属性之一，本文将简述Playmaker 的 Transform行为的使用。由于2d和3d场景有相似性，对于同时有2d和3d的行为，我都以3d做示例解释。

前有视频实例，所以，流量警告！

你也可以直接访问官方英文文档：

Transform Actions

目录：Transform Actions目录：

1. Clamp Orthographic View 钳制正交摄像机位置
2. Screen Wrap 物体屏幕位置限制（物体从摄像机左边缘滑出后会直接从右边缘滑入，常用于飞机大战游戏）
3. Align To Direction 对齐到方向
4. Clamp Position 钳制（物体）位置
5. Clamp Rotation 钳制（物体）旋转
6. Get Angle to Target 获得与目标物体之夹角
7. Get Position 获得位置
8. Get Rotation 获得旋转值
9. Get Scale 获得比例值
10. Inverse Transform Direction 方向变换（反向）
11. Inverse Transform Point 坐标变换（反向）
12. Look At 看向
13. Look At Direction 看向方向
14. Move Object 移动物体
15. Move Towards 向...移动
16. Rotate 旋转
17. Set Position 设置位置
18. Set Random Rotation 设置随机旋转
19. Set Rotation 设置旋转数值
20. Set Scale 设置比例大小
21. Smooth Follow Action 平滑跟随
22. Smooth Look At 平滑视角锁定
23. Smooth Look At Direction 平滑视角方向
24. Transform Direction 方向变换
25. Transform Point 坐标变换
26. Translate 坐标变换

Clamp Orthographic View 钳制正交摄像机位置

描述：钳制一个正交摄像机的位置，使摄像机视图被限制在某位置（用最大值最小值限制）内。可以通过不设置，让某个轴不做钳制。

正在研究....（可参考其他与钳制有关的行为）

Screen Wrap 物体屏幕位置限制

描述：将某个游戏物体的位置包裹在屏幕位置内，例如：当一个物体从屏幕左侧滑出时，物体会立刻从屏幕右边滑入。常用于飞机大战游戏中。

属性：

GameObject : 选择物体（本物体或指定物体）

Camera：选择要进行Wrap的摄像机（可以以拖拽或变量形式赋予）

Wrap (Left/Right/Top/Bottom)：是否围起来（视图四个方向都可以修改，可以通过自带的勾选或者通过布尔变量赋予）

EveryFrame：是否每帧执行

LateUpadate：是否延后执行（该操作影响是否在帧末尾执行，如果你在wrap前有其他操作会有用）

Align To Direction 对齐到方向

描述：将物体和某个方向对齐

正在研究......（效果和名称相似，但我暂时没找到他的具体实现过程）

Clamp Position 钳制（物体）位置

描述：钳制物体的位置（用最大值最小值限制），通过不设置来不钳制

属性：

GameObject : 选择物体（本物体或指定物体）

Min/Max（X/Y/Z）：X，Y，Z轴上的最大值和最小值限制（可以通过输入框输入或浮点变量赋予，或留着None来不钳制它）

Space：选择物体问题空间还是世界空间（Self/Global）

EveryFrame：是否每帧执行

LateUpadate：是否延后执行（该操作影响是否在帧末尾执行，如果你在Clamp Position前有其他操作会有用）

Clamp Rotation 钳制（物体）旋转

描述：钳制物体的旋转（用最大值最小值限制），通过不设置来不钳制。注意，这个旋转钳制针对的是某个轴对应的垂直平面的，并非物体自身Vector3旋转

属性：

GameObject : 选择物体（本物体或指定物体）

Default Rotation：默认旋转，钳制数值是根据这个默认旋转数值钳制的，可以设置为None让其以物体初始旋转钳制（可以通过V2变量赋予或手动输入）

Constraint Axis：限制轴（可选择X,Y,Z或手动输入）

Min/Max Angle：钳制最大值和最小值（可手动输入或浮点变量赋予）

EveryFrame：是否每帧执行

Get Angle to Target 获得与目标物体之夹角

描述：获得游戏物体正方向，和目标物体之间的夹角。目标物体可以是游戏物体或世界坐标。如果你同时设置了目标物体和世界坐标，世界坐标将自动转换为目标物体的本地坐标的偏移Offset

属性：

GameObject : 选择物体（本物体或指定物体）

Target Object：目标物体（None不输入，或指定物体或通过GameObject变量赋予）

Target Position：目标世界坐标（None不输入，或V3变量赋予或手动输入，和目标物体同时存在时会变为目标物体本地坐标的偏移Offset）

Ignore Height：是否忽略与目标物体/位置之高度差（可通过勾选或布尔赋予，如果忽略，二者夹角将等同于在同一高度平面内的夹角，不忽略则会考虑到高度差别，具体数值未研究出来）

Store Angle：将夹角结果赋予浮点变量，角度制

EveryFrame：是否每帧执行

Get Position 获得位置

描述：获得某个游戏物体的位置并存入一个Vector3变量，或（和）者将X,Y,Z数值分别存入三个浮点变量

属性：

GameObject : 选择物体（本物体或指定物体）

Vector：选择存入哪个V3变量

X/Y/Z：选择将某个轴上数值存入浮点变量

Space：世界空间或本地空间 （World/Self）

EveryFrame：是否每帧执行

Get Rotation 获得旋转值

简述：获得某个游戏物体的旋转并存入一个Vector3变量，或（和）者将X,Y,Z数值分别存入三个浮点变量，或以四元数方式保存

属性：

GameObject : 选择物体（本物体或指定物体）

Quaternion：将结果以四元数形式存入一个四元数变量

Euler Angles：将结果以欧拉角的方式存入V3变量

X/Y/Z Angle：选择将某个轴上数值存入浮点变量

Space：世界空间或本地空间 （World/Self）

EveryFrame：是否每帧执行

Get Scale 获得比例值

简述：获得某个游戏物体的缩放并存入一个Vector3变量，或（和）者将X,Y,Z数值分别存入三个浮点变量

属性：

几乎与Get Position相同，不再赘述，建议向上翻看

Inverse Transform Direction 方向变换（反向）

简述：和方向变换（正向）相对，方向变换（反向）会将世界空间中的方向转换为游戏物体的本地空间内的方向。

属性：

GameObject : 选择物体（本物体或指定物体）

World Direction： 世界空间的方向，可以手动输入或者用V3变量引入

Store Result：保存结果到V3变量中

EveryFrame：是否每帧执行

Inverse Transform Point 坐标变换（反向）

描述：和坐标变换（正向）相对，坐标变换（反向）会将世界空间中的坐标转换为游戏物体的本地空间内的坐标

属性：

GameObject : 选择物体（本物体或指定物体）

World Direction： 世界空间的方向，可以手动输入或者用V3变量引入

Store Result：保存结果到V3变量中

EveryFrame：是否每帧执行

Look At 看向

简述：旋转一个游戏物体，让它的正方向指向目标。这个目标可以是特定的游戏物体或者世界坐标，如果你同时设置了目标物体和世界坐标，世界坐标将变成目标物体本地坐标上的偏移Offset

属性：

GameObject : 选择物体（本物体或指定物体）

Target Object：目标物体（None不输入，或指定物体或通过GameObject变量赋予）

Target Position：目标世界坐标（None不输入，或V3变量赋予或手动输入，和目标物体同时存在时会变为目标物体本地坐标的偏移Offset）

Up Vector：将物体Y轴变换到目标方向，再进行LookAt操作（可以手动输入或用变量赋予）

Keep Vertical：物体是否在会在LookAt时因为高度差而改变俯仰角（手动勾选或布尔变量赋予）

Draw Debug Line：是否绘制Debug线条（手动勾选或布尔变量赋予）

Debug Line Color：设置Debug线条颜色（手动设置颜色或用RGB变量赋予）

EveryFrame：是否每帧执行

Look At Direction 看向方向

简述：旋转一个游戏物体，让它的正方向指向某个方向

属性：

GameObject : 选择物体（本物体或指定物体）

Target Direction：目标方向（手动输入或用V3变量赋予）

Up Vector：将物体Y轴变换到目标方向，再进行LookAt操作（可以手动输入或用变量赋予）

EveryFrame：是否每帧执行

LateUpadate：是否延后执行（该操作影响是否在帧末尾执行，如果你在wrap前有其他操作会有用）

MoveObject 移动物体

简述：用平滑函数将一个游戏物体移动到另一个游戏物体

属性：

Object to Move：选择要移动的物体（本物体或指定物体）

Destination：目标物体（可以手动拖拽物体或用游戏物体变量赋予）

Time：在Time时间内到达目标物体位置（手动输入或浮点变量赋予）

Speed：让物体以某个速度移动，代替Time（手动输入或浮点变量赋予）

Delay：移动之前的延迟（手动输入或浮点变量赋予）

Ease Type：平滑类型（有很多很多中平滑类型，例如线性、弹簧、弹跳、缓入、缓出等等等等）

Reverse：反向，是否反向运动（手动勾选或布尔变量赋予）

Finish Event：让移动完成后触发一个事件（自定义事件或系统事件）

RealTime：是否忽略设置的时间比例，比如如果游戏有暂停时间的按钮，会不会受其影响（手动勾选）

Move Towards 向...移动

简述：将游戏物体移动到一个目标，成功后可以发送一个事件。目标可以是游戏物体或世界坐标如果你同时设置了目标物体和世界坐标，世界坐标将变成目标物体本地坐标上的偏移Offset

属性：

GameObject : 选择物体（本物体或指定物体）

Target Object：目标物体（None不输入，或指定物体或通过GameObject变量赋予）

Target Position：目标世界坐标（None不输入，或V3变量赋予或手动输入，和目标物体同时存在时会变为目标物体本地坐标的偏移Offset）

Ignore Vertical：忽略高度，物体在移动时是否会因为高低差而发生高度变化（手动勾选或布尔变量赋予）

MaxSpeed：最大速度，移动时不能超过这个速度（可以手动输入或用浮点变量赋予）

Finish Distance：终点距离，当被移动物体和终点间距离小于这个FinishDistance时会被判定完成移动并发送完成时的事件（可以手动输入或用浮点变量赋予）

Finish Event：让移动完成后触发一个事件（自定义事件或系统事件）

Rotate 旋转

简述：按照每个轴旋转游戏物体，可以通过V3变量输入或用X,Y,Z分别输入，不设置可以让其在某轴上不旋转

属性：

GameObject : 选择物体（本物体或指定物体）

Vector：旋转值得Vector3变量（不设定，或以变量形式传入）

X,Y,Z Angle：每个轴上的旋转值（不设定，，手动输入，或以变量形式传入）

Space：世界空间或本地空间 （World/Self）

PerSecond：是否以秒为单位，等效于乘Time.deltaTime

EveryFrame：是否每帧执行

Fixed Update：是否在Fixed Update函数中执行

Set Position 设置位置

简述：设置物体的位置

GameObject : 选择物体（本物体或指定物体）

Vector：设置位置的Vector3坐标（不设定，或以变量形式传入）

X,Y,Z：每个轴上的坐标值（不设定，手动输入，或以变量形式传入）

Space：世界空间或本地空间 （World/Self）

EveryFrame：是否每帧执行

LateUpadate：是否延后执行（该操作影响是否在帧末尾执行，如果你在wrap前有其他操作会有用）

Set Random Rotation 设置随机旋转

简述：设置物体的随机旋转数值

GameObject : 选择物体（本物体或指定物体）

X,Y,Z Axis：每个轴是否会应用这个随机数（不设定，手动输入，或以变量形式传入）

Set Rotation 设置旋转数值

简述：设置物体的旋转数值

GameObject : 选择物体（本物体或指定物体）

Quaternion：设置旋转时使用四元数变量设置（不使用或通过四元数设置）

Euler Angles：设置旋转时使用Vector3变量数值，Vector3里的数值将以欧拉角的规则被处理（不使用或以Vector3形式传入）

X,Y,Z Angle：设置每个轴上的旋转值，以欧拉角规则被处理（不设定，手动输入，或以变量形式传入）

Space：世界空间或本地空间 （World/Self）

EveryFrame：是否每帧执行

LateUpadate：是否延后执行（该操作影响是否在帧末尾执行，如果你在wrap前有其他操作会有用）

Set Scale 设置比例大小

简述：设置物体的大小比例

GameObject : 选择物体（本物体或指定物体）

Vector：以Vector3形式传入各个轴上缩放大小（不设定，或以变量形式传入）

X,Y,Z：每个轴上的缩放值（不设定，手动输入，或以变量形式传入）

EveryFrame：是否每帧执行

LateUpadate：是否延后执行（该操作影响是否在帧末尾执行，如果你在wrap前有其他操作会有用）

Smooth Follow Action 平滑跟随

简述：令一个物体跟随另一个物体，这是一个大部分时候用于摄像机跟随角色的行为，包括摄像机距离主体的前后距离，摄像机物体在主体上方的数值，摄像机物体方向和主体正方向相同且在物体正方向直线上，和一些平滑选项。

GameObject : 选择物体（本物体或指定物体）

Target Object：跟随的目标物体（选择物体或物体变量传入）

Distance：主物体和目标物体之间的距离（可理解为摄像机在主体后面的距离数值，手动输入或变量传入）

Height：主物体和目标物体的高度差别（可理解为摄像机在主体头顶的距离数值，手动输入或变量传入）

Height Damping：跟随物体时产生高度数值变化的阻尼数值

Rotation Damping：跟随物体时产生旋转数值变化的阻尼数值

Smooth Look At 平滑视角锁定

简述：让主体的正方向轴平滑的对准一个目标物体或世界坐标，如果你同时设置了目标物体和世界坐标，世界坐标将变成目标物体本地坐标上的偏移Offset

GameObject : 选择物体（本物体或指定物体）

Target Object：锁定的目标物体（选择物体或物体变量传入）

Target Position：目标世界坐标（None不输入，或V3变量赋予或手动输入，和目标物体同时存在时会变为目标物体本地坐标的偏移Offset）

Up Vector：将物体Y轴变换到目标方向，再进行LookAt操作（可以手动输入或用变量赋予，不设置就是默认的LookAt）

Keep Vertical：物体是否在会在LookAt时因为高度差而改变俯仰角（手动勾选或布尔变量赋予）

Speed：当目标物体或坐标位置变化时，主物体进行LookAt行为的最大速度

Debug：画出用于Debug的当前之LookAt效果的示意直线（Debug.DrawLine）

Finish Tolerance：如果主体的正方向与主体和目标物体之方向夹角小于这个角度，那么发送一个结束事件，该数值为角度制

Finish Event：发送事件的具体事件内容

Smooth Look At Direction 平滑视角方向

简述：平滑的把目标物体之正方向调整为目标方向之方向

GameObject : 选择物体（本物体或指定物体）

Target Direction：锁定的目标方向（输入方向或Vector3变量传入）

Min Magnitude：当目标方向矢量的模大于这个设定数值时才执行LookAt行为

Up Vector：将物体Y轴变换到目标方向，再进行LookAt操作（可以手动输入或用变量赋予，不设置就是默认的LookAt）

Keep Vertical：物体是否在会在LookAt时因为高度差而改变俯仰角（手动勾选或布尔变量赋予）

Speed：当目标物体或坐标位置变化时，主物体进行LookAt行为的最大速度

Debug：画出用于Debug的当前之LookAt效果的示意直线（Debug.DrawLine）

Finish Event：当物体的正方向与目标方向之夹角小于MinMagnitude时，发送事件的具体事件内容

Finish：是否会在当物体的正方向与目标方向之夹角小于MinMagnitude时，结束这个行为

Transform Direction 方向变换

简述：将某个物体的本地坐标内之方向变换为世界坐标内的方向

GameObject : 选择本地坐标之物体（本物体或指定物体）

Local Direction：这个本地坐标系中的方向参数

Store Result：将结果存放到的变量

Every Frame：是否每一帧进行执行

Transform Point 坐标变换

简述：将某个物体的本地坐标内的坐标变换为世界坐标内的坐标

GameObject : 选择本地坐标之物体（本物体或指定物体）

Local Point：这个本地坐标系中的坐标参数

Store Result：将结果存放到的变量

Every Frame：是否每一帧进行执行

Translate 坐标变换

简述：最常用的坐标变换

GameObject : 选择物体（本物体或指定物体）

Vector：变换值的Vector3变量（不设定，或以变量形式传入）

X,Y,Z Angle：每个轴上的变换值，可以覆写Vector中的变换值（不设定，手动输入，或以变量形式传入）

Space：世界空间或本地空间 （World/Self）

PerSecond：是否以秒为单位，等效于乘Time.deltaTime

EveryFrame：是否每帧执行

Late Update：是否在末尾执行

Fixed Update：是否在Fixed Update函数中执行

ZENO的初衷是一个面向高性能物理计算而研发的可视化编程系统和平台。

它包括了以下几个重要概念：

内置的几何数据结构

可视化编程系统

高性能计算框架

软件以及官方用代码或者zeno的可视化编程本身开发的工具

对这几个概念的熟练掌握将能帮助用户更快更好的把zeno使用到出神入化，创建出丰富的计算任务场景：

本文的目的是从案例入手，帮助个人用户掌握zeno的使用，并能够逐步进入zeno的深水区。

• Example 1 一个ZENO中的Hello World

在这个例子中， 我们演示了一个zelloWorld的简单案例， 这个案例有三个部分构成：

用户提供一个字符串-->通过zelloWorld节点根据字符串产生3D字图形（只有大写）-->使用闪烁渲染进行可视化。

同时，这也是一个典型的zeno界面， 它总共有这几个部分组成：

一个三维观察窗口， 用于观察ZENO系统中的三维物体， 底下是一些frame调整功能， 再之下是节点编辑窗口， 这三者构成了ZENO的主要概念：对于时间轴的可视化编程。

• Example 2 在zeno读取并显示一个三维文件

在zeno中可以读取并显示三维物体(这个功能还在进步中, 会做成自动对输入多态和输出多态的支持)比如读取一个mesh,并显示(上图)

或者:读取一个VDB 数据将SDF转换为polygon并显示(下图):

• Example 3 zeno中的tag和连线,关键词

Zeno中的节点有以下几个重要的编辑概念

Control Tag

这些tag浮动于节点上方，被开启后会显示为绿色， 他们分别是：

• Out：

当该Tag被点亮时，由ZENO节点图所定义的程序逻辑， 无论多么复杂， 到达该节点的通路上的前置计算节点（以及通路上所需要的数据和数据所需的前置计算结点）会被必然依序执行（每个frame）， 直到最后一个out节点为止。节点的执行顺序由zeno系统保证：任何一个被需要的节点必然在任何需要其的节点之前被执行。

• Mute：

当该Tag被点亮时，相应的节点会被取消执行， 注意，这也许会在整个图中引入错误， 比如被跳过的节点正好将一个数据类型A转换为后续计算所需要的数据类型B时。谨慎使用。

• ONCE：

当该Tag被点亮时， 所标记的节点只会在全局被执行一次。ZENO系统的最基本计算单位为substep（subframe）， 所有位于节点编辑器中的计算， 都会默认地被每个frame的每个subframe执行，然而很显然我们不是总需要这么做：比如读取一些与时间无关的静态的场景文件时，读取操作只需要执行一次。 对于这样的目的， 我们可以指定ONCE。

• VIEW：

被打了VIEW的节点， 其计算结果， 当是renderable的物体时，会进入到zeno的3D可视化窗口被可视化， 可视化的方法由zeno的可视化节点决定。被标记VIEW的节点， 其所有前置计算也会被正确执行。当一个frame存在多个subframe， 以及当一个被标记数据可能在计算顺序中被先后修改时，只有最后一个subframe的最后一次修改结果才会进入可视化界面进行可视化。

数据端口连线：

除了特殊端口，SRC，COND，DST以外的端口即数据端口，当一个右侧的数据端口被连向一个左侧的数据端口时，两个节点即构成了计算依赖关系， 前序节点会优先于后续节点被执行， 后续节点的数据输入为所对应连接的数据出口。

• 特殊端口：

DST， SRC

除了数据依赖关系外， 可以通过DST和SRC连接来强制指定计算执行顺序， 考虑如下计算图：

在该流程所代表的计算图中， 我们企图对于读取的图形做CSG相减操作，

图形---->上路:对它的所有坐标乘以0.5(inplace修改)-->转换为SDF, 给予VDB combine A.

----> 下路: 转换为SDF, 给予VDB Combine B

然而结果, 我们没有得到任何输出图形, 原因是上路的图形的操作是inplace的, 而这两个岔路的执行顺序是按照创建顺序, 当上路的primitive 被inplace修改结束后, 下路的primitive数据(同一个指针位置)也被修改了, 于是乎我们实际上是在对数值相同的Primitive进行SDF转换和CSG操作, 当然没有结果.

当出现对于数据的In-Place操作可能会修改其它分支链路的计算结果时, 我们可以通过DST->SRC强制修改节点执行的顺序, 如此, 原先的Primitive会被先转化为一个SDF, 再被进行缩放修改, 转化为另一个SDF, 如此,我们就会对两个数值不同的SDF进行CSG操作, 从而得到正确的结果.

zeno中提供了一些重要的节点对于系统级的变量(比如frame, time等的)进行设置和获取, 以支持用户在计算中出于不同的目的对于系统变量和状态进行控制和利用. 比如:

这将会在一个frame的subframe中对物体的形态按照系统变量framePortion(当前frame时间积分完成的百分比)进行插值, 提供更精细化的边界或者运动控制.

而{frame}字符将把目标数据在当前frame结束时自动命名为正确的序号名称并保存到硬盘上.

以上构成了zeno最基本的一些计算和操作概念, 我们将在之后的章节中通过更多的案例和练习深化这些概念, 带领大家往zeno的深水区进发.

• Example 4 在Zeno中执行一个For循环

4.1 for循环

Zeno中的for循环有几个重要组成部分: count(执行次数)FOR接口的连接(BeginFor->EndFor对), 以及由DST出发经过系列计算操作到达EndFor的 SRC的通路. 这条通路上的计算结点将会被执行count次.

• 4.2 forEach循环

当我们有一个物体列表时(列表由zeno的AppendList节点创建), 我们也可以使用ForEach循环, 它会自动给出当前循环的Object以及index值, 并可以运用这两个数据对物体进行操作. 上图中, 我们获取ObjectList中的物件, 随后, 根据index%7获取彩虹颜色列表中的颜色给物体指定颜色.

• 4.3 BreakFor

当index大于5的时候终止执行

• Example 5 在ZENO中进行条件控制

如果frame是奇数, 读取sphere.obj并显示, 如果frame是偶数, 读取monkey.obj并显示. IFElse节点会根据输入条件在两条分支道路中选择一条执行并把对应路径的执行结果传递给result出口. 共后续节点使用.

• Example 6 封装一个zeno子图并让他被其它场景调用

Zeno中最强大的功能之一就是用zeno封装子图并被zeno的其它场景作为一个节点调用. 由此可以两仪生四象 , 四象生八卦, 变化无穷.

下图:一个mesh和它被ReCenter(减去质心)后的位置

开发一个subnet(子图)节点就如同开发一个函数, 可以自定义它的输入和输出, 以及它可能被可视化捕捉的对象, 在以下这个最简单的实现中, 我们展示了这样一个逻辑: 首先对于输入的图元, 我们对它进行ParallelReduce操作求其坐标"pos"的均值, 这就是它的几何质心(这基于它的每个三角形都差不多大, 如若不然我们可以使用remesh对它先做remesh). 然后, 我们将图元的每一个pos都减去这个均值, 就得到它被recenter后的坐标了. 我们再输出com以及prim, 以供后续节点使用

这样一个节点被封装完毕后, 它就和任何一个由cpp开发出来的节点一样可以被调用, 并且还可用于其它的子图中, 甚至自己调用自己(递归). 事实上, zeno的很多官方算法甚至都是由subnet开发的, 而非cpp开发.

未完待续......

Example 7 在ZENO中编辑一个公式(zfx)

Example 8 在zeno中进行刚体仿真

Example 9 VDB以及体积操作的妙用

Example 10 在zeno中进行刚体仿真

Example 11 在zeno中进行流体仿真

Example 12 在zeno中进行MPM仿真

Example 13 在zeno中进行气体仿真

Example 14 在zeno中进行肌肉仿真

Example 15 在zeno中进行分子动力学仿真

Example 16 zeno的Wrangler

Example 17 用C++扩展zeno:如何用编程开发一个节点?

Example 18 用zeno扩展zeno, 以实现一个SPH解算系统为例

Example 19 ZENO与纯CPP开发出的并行程序的性能对比

Example 20 ZENO与直接开发cuda代码程序的性能对比

Example 21 场景实战: 狂风, 海中方舟, 镇龙塔倒, 龙腾出海.

Example 22 场景实战: 程序化生成场景

在前面的基础上：

迦非喵：CMake+IMGUI实现Examples中测试代码迦非喵：CMake+IMGUI实现最简单的窗口界面

这里继续进行简单测试。

这也是国产CFD开源软件OneFLOW的界面部分的一些技术储备。当然，用不用得到就是一回事了。毕竟计算科学是比较严肃的事情，花里胡哨的界面并不见得带来多少收益。然而了解，在清醒之中的洞见还是有必要的。

这里仅编译运行好开源的imgui-node-editor就够了，后面OneFLOW还要进行数以千记，万记，甚至数十亿次的迭代，只不过后面是机器自动去做了。

目前阶段，还得靠人工去迭代。

imgui-node-editor网址：

thedmd/imgui-node-editor: Node Editor using ImGui (github.com)

编译：

cmake https://www.zhihu.com/topic/

有：

 cmake https://www.zhihu.com/topic/ -- Building for: Visual Studio 16 2019 -- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19043. -- The C compiler identification is MSVC 19.29.30133.0 -- The CXX compiler identification is MSVC 19.29.30133.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found imgui: D:/work/imgui_work/imgui-node-editor-master/external/imgui -- Found stb_image: D:/work/imgui_work/imgui-node-editor-master/external/stb_image -- Found ScopeGuard: D:/work/imgui_work/imgui-node-editor-master/external/ScopeGuard -- Found imgui_node_editor: D:/work/imgui_work/imgui-node-editor-master -- Configuring done -- Generating done -- Build files have been written to: D:/work/imgui_work/imgui-node-editor-master/examples/build

cmake --build .

 cmake --build . 用于 .NET Framework 的 Microsoft (R) 生成引擎版本 16.11.0+0538acc04 版权所有(C) Microsoft Corporation。保留所有权利。 Checking File Globs Checking Build System Building Custom Rule D:/work/imgui_work/imgui-node-editor-master/examples/application/CMakeLists.txt dxerr.cpp dxerr.vcxproj -> D:\work\imgui_work\imgui-node-editor-master\examples\build\application\Debug\dxerr.lib Building Custom Rule D:/work/imgui_work/imgui-node-editor-master/external/imgui/CMakeLists.txt imgui.cpp imgui_demo.cpp imgui_draw.cpp imgui_widgets.cpp 正在生成代码... imgui.vcxproj -> D:\work\imgui_work\imgui-node-editor-master\examples\build\external\imgui\Debug\imgui.lib Building Custom Rule D:/work/imgui_work/imgui-node-editor-master/examples/application/CMakeLists.txt entry.cpp imgui_impl_dx11.cpp imgui_impl_win32.cpp 正在生成代码... application.vcxproj -> D:\work\imgui_work\imgui-node-editor-master\examples\build\application\Debug\application.lib Building Custom Rule D:/work/imgui_work/imgui-node-editor-master/examples/canvas-example/CMakeLists.txt crude_json.cpp imgui_canvas.cpp imgui_node_editor_api.cpp imgui_node_editor.cpp 正在生成代码... imgui_node_editor.vcxproj -> D:\work\imgui_work\imgui-node-editor-master\examples\build\canvas-example\Debug\imgui_no de_editor.lib Building Custom Rule D:/work/imgui_work/imgui-node-editor-master/examples/basic-interaction-example/CMakeLists.txt basic-interaction-example.cpp basic-interaction-example.vcxproj -> D:\work\imgui_work\imgui-node-editor-master\examples\build\bin\basic-interaction -example_d.exe Building Custom Rule D:/work/imgui_work/imgui-node-editor-master/examples/blueprints-example/CMakeLists.txt blueprints-example.cpp builders.cpp drawing.cpp widgets.cpp 正在生成代码... blueprints-example.vcxproj -> D:\work\imgui_work\imgui-node-editor-master\examples\build\bin\blueprints-example_d.exe Building Custom Rule D:/work/imgui_work/imgui-node-editor-master/examples/canvas-example/CMakeLists.txt canvas-example.cpp canvas-example.vcxproj -> D:\work\imgui_work\imgui-node-editor-master\examples\build\bin\canvas-example_d.exe Building Custom Rule D:/work/imgui_work/imgui-node-editor-master/examples/simple-example/CMakeLists.txt simple-example.cpp simple-example.vcxproj -> D:\work\imgui_work\imgui-node-editor-master\examples\build\bin\simple-example_d.exe Building Custom Rule D:/work/imgui_work/imgui-node-editor-master/examples/CMakeLists.txt

此时已经编译好了一些示例代码：

运行（需在VS2019集成开发环境下）：

即将blueprints-example设为启动项目：

运行有：

连线：

当然，上面只是示意，具体使用需要经过改进。感兴趣者可以举一反三。

这其实骗了很多人，包括我；

在开始学习可视化编程之前，我一直认为可视化编程是不需要任何编程基础就可以做出游戏；

事实上我大错特错了，我看了很多教程以后，终于明白，可视化编程他还是编程，只是他以另外一种方式在编程，比如原来是敲代码，他把代码的一些功能变成一个小图形化的方块或别的什么，该有的程序步骤一个也少不了，只是变得另外一种形式罢了，给那些不喜欢敲很多代码的人多一个选择而已；

悲剧的是，我刚开始始终认为我是可以做出游戏来的，以至于就全职开始独立游戏的制作，以至于到后来我发现不行了，很多东西其实是完全不知道的，只能挨个去度娘，油管，谷歌学习，就这样，我学会了可视化编程；这时候我再去看别人写的代码，还是有大部分看不懂，但我也发现耐着性子其实很多代码也能看懂，而且基本上和我的思路也差不多；

这个时候我可以说我学会了一种既不是敲代码的编程，但又是一种编程方式的编程；稍微有点尴尬，但幸运的是，我可以用这些学到的可视化编程知识做出几乎我想要的任何东西，这就够了，原本我的目的就是做游戏，至于怎么实现，是敲代码还是可视化编程，那都不是我的基本目的了；

基本上，可视化编程和传统的编程思路差不多，你用的越多就越熟练，该有的变量，逻辑，方法，组件访问都是差不多的，如果你没有编程知识来学可视化编程同样是比较吃力的，千万不要相信那些宣传说不需要任何编程基础就可以做游戏的荒唐言论；

如果你因此做出了重大的选择，我觉得你基本上是上了条不归路了；

市面上目前有的可视化编程（主要指Unity），大概思路都是这样：

1，图形化api和游戏内置api一一对应，完全映射，你会编程也会这个，比如bolt，universal，

2，开发者经过加工，把一些功能合并起来，更接近于投放给没有编程基础的人群使用，但即使是这样，你也需要相当的程序思想，比如Playmaker

事实上，我建议各位如果只是学着玩玩，那么哪种方式都可以去尝试；
如果是专业的程序员，也犯不着来学这些可视化编程；
但是如果因为听了别人一些言论，认为不需要任何程序思想就可以做游戏的人，而且还打算全职来做的话，你最好多做点思想准备和以及准备好退路；

事实上证明国内可视化能做出成品的游戏确实不多，而且那基本是有专业程序员参与团队才敢使用这些插件的，万万不可能商业团队来完全使用这些可视化插件，基本是独立游戏才会使用，因为独立游戏体量和投入不是很大，即使发现不对劲及时止损都还行。

之前买HB慈善包送的插件。网上的中文资料相当少。总之写一遍文档记录一下。

插件文档地址

Documentation | NodeCanvas

基本概念：

Graphs

NodeCanvas创建可视化资源执行资源，共分为3种。BehaviourTree，FSM和DialogueTree。

Owner

挂载到Gameobject上面执行Graphs的核心组件，依据Graphs类型同样分为3个。

Blackboard

为Graphs提供的变量的组件。还可以绑定同一gameobject下的其他组件的成员。

Node

节点是组成Graphs的关键，下面Assign可以添加相应的任务。

大部分节点介绍

工欲善其事，必先利其器

• Action

执行一个action并返回成功或失败

• Condition

检查某一状态并返回成功或失败

Composites

组合使用多个子节点，并基于组合功能以某种顺序执行它们。

• sequencer

按次序或者随机的执行子节点。当子节点返回成功时，该节点也返回成功继续执行。反之则重新开始。

• selector

按次序或者随机的执行子节点。若执行节点返回true则会停止执行下一个节点。

• parallel

同时执行所有子级。它可以设置为具有序列器或选择器的策略，如下所示：

如果设置为First Failure，则一旦任何子级返回Failure，它将重置所有当前运行的子级并返回Failure。否则，当所有的孩子都返回成功时，它将返回成功。

如果设置为First Success，则一旦任何子级返回成功，并行程序将重置所有当前正在运行的子级并返回成功。否则，当所有子级都返回失败时，它将返回失败。

• binary selector

根据自身bool执行左边或右边。

• Flip Selector

Flip Selector 的工作方式与普通 Selector 类似，但是一旦子节点返回成功，它就会移动到末尾（右侧）。 因此，总是首先检查以前失败的子节点，最后检查最近成功的子节点。

• Priority Selector

Priority Selector 类似于普通 Selector，但会根据每个子级的优先级选择子级执行的顺序。一旦您连接子节点，优先级权重就会显示出来，您可以直接或通过黑板变量改变优先级权重。

• Probability Selector

概率选择器将根据被选中的概率选择并执行一个子节点。如果选中的子选项返回 Succes，概率选择器也将返回 Success，同时开始新的一轮。如果它返回失败，讲继续选择别的节点。如果没有子级返回成功，概率选择器将返回 Failure。Failure Chance是独立于节点的失败概率。

• switch

根据switch上的数值或者enum选择执行子节点。

Decorators

Decorators总是有一个子节点。他们通常会给那个节点额外的功能，过滤或者以某种方式修改它。

• Conditional

就是Condition，不过可以加子节点

• Filters

根据冷却或者次数限制执行子节点。在冷却或超过最大次数可以

• Guard

Guard有个token值，相同token的Guard不会同时执行。

• Interruptor

Interruptor内值一旦返回失败立即终止子节点。

• Inverter

反转子节点返回值

• Iterator

根据迭代器迭代多次，可以将迭代内容输出到黑板上。

可以选择将迭代器设置为在修饰的节点返回成功或失败时立即终止迭代。如果未设置任何终止条件（无），或者如果迭代列表且未满足终止条件，则迭代器将返回上次迭代子执行返回的内容。

如果选中“重置索引”，则迭代器将在每次重置时将当前迭代索引重置为零，否则该索引将保留，除非它是列表的最后一个索引。把它看作是一个“foreach”。

• monitor

监视子节点返回值决定是否执行该节点任务，监视返回值可以设为成功，失败或任意。

返回值也是设置为子节点和自己任务。

• Optional

不会返回任何值。

• Override Agent

Override Agent为行为树的其余部分设置另一个代理，从其点开始，然后从直接选择或从黑板变量中获取的游戏对象开始。这意味着这个装饰器下面的每个节点现在都将被勾选为新代理。此装饰器是NodeCanvas允许您从单个“主”行为树控制多个代理或动态更改代理的方式之一。

• remap

将成功和失败重新映射

• Repeat

重复执行。

• Timeout

没在规定时间内执行完则返回失败

• wait until

在该节点停留直到条件为真

• merge

可以被多个父节点继承。

自定义Task

• Task Type

分为两种Action和Condition。

Action用于执行功能

Condition用于判断状态

• Task Name

Task的名字

• Namespace

该task所在的名称空间

• Category

该task创建时所在的分类

• description

描述

• Agent Type

挂载的类型。默认为Gameobject

基本看英文都能看得明白，同时游戏自带的task也能开打。基本上把常用的打开看看就懂怎么写了。

BBParameter 黑板的参数，这个能绑定到黑板上

[BlackboardOnly] 加到BBParameter 上就能限定必须用黑板上的值

EndAction()该方法调用后就表示该task结束。可传递bool表示成功或失败。

agent 表示挂载的类。

最近从航模老师那儿借了几架可编程的无人机Tello EDU，本想着应该很比较好上手，结果资料、软件都没有，一下子有点无措。不过，还好有度娘，以下是我在搜集资料过程后的初次通过PC用scratch编程控制Tello完成飞行控制的配置过程。虽然网络上已有网友给出了非常详细的教程步骤，但还是自己做一个小记录方便自己查阅。

一、资料收集与下载

1、Scratch2.0 offline Editor下载：链接:http://yun.zjer.cn/res//share/s.html?shortCode=bieiAr 提取码:a955，此包为离线绿色版，解压开即可使用。若提示需先安装Adobe AIR，则请点击以下地址下载安装，Adobe AIR下载：链接:http://yun.zjer.cn/res//share/s.html?shortCode=6ZFjUn 提取码:de67

2、node-v8.17.0下载与配置：https://nodejs.org/dist/latest-v8.x/，建议直接下载安装.msi格式的文件，可以直接安装无需环境变量另外配置。安装完后，在命令窗口输入：node -v，若出现版本编号则表示安装成功，如下图所示。

3、Scratch图形化编程插件下载：https://dl-cdn.ryzerobotics.com/downloads/tello/Release.zip，Release.zip文件中包含有Tello.js（作为pc端连接Tello无人机的进行编程控制的固件）、Tello.s2e（英文插件）、TelloChs.s2e（中文插件）

1、node命令启动Tello.js固件：

在命令窗口中，找到release.zip解压得到的scratch文件夹中的Tello.js文件，使用node命令运行Tello.js： node Tello.js，如下图所示。

2、Scratch中添加Tello编程插件：

打开scratch软件后，按住shift键，鼠标点击文件菜单下的“导入试验性HTTP 拓展功能”（英文：Import Experimental Extension），导入TelloChs.s2e（中文插件），则在更多模块中出现了Tello编程代码，如下图所示。

三、无线连接与编程控制

1、PC端连接Tello无线热点：

2、编程控制：

添加简单的控制代码，即可控制Tello无人机的启动，前进后退，翻转，降落等操作了。

四、无人机编程初体验

编程插件较为简单，只要能连接上Tello的无线热点，就能轻松控制Tello的起飞等动作。

但是编程插件似乎没有维护更新，一些视觉方面的功能，或者复杂的操作功能没那么容易实现，例如机械爪的控制、视觉识别等等；研究了半天，发现可扩展性很弱，还是有点失望。

声明：未经本人允许，禁止转载，原创链接：https://zhuanlan.zhihu.com/p/52

介绍一下如何搭建在线的编程教学网站，目前支持Scratch、Python，是一位大佬开源在GitHub上的，搭建比较繁琐，动手能力不够的可以找我搭建。

开源页面地址：https://github.com/open-scratch/teaching-open

Teaching针对机构、学校提供STEAM在线教育解决方案， 提供一个低成本试错的机会。

平台集成CRM系统、教务系统、作业系统、题库系统、赛事系统、社区系统。并封装了常用的工具，如各种工具类、微信生态对接、支付对接等等。

对于小白而言，我们直接用编译好的前端和后端文件即可。

我的操作系统：云服务器Ubuntu 20.04

1、下载好几个文件

2、服务器环境配置

安装宝塔服务器面板，安全组开放8888端口，阿里云还需开80端口

宝塔面板一键安装 redis 6.0、Nginx 、mysql5.6

设置数据库表名忽略大小写 lower_case_table_names=1 后重启mysql

导入api/db文件夹的sql文件（宝塔可一键导入）。如果是升级，需要以此按版本号执行升级sql

安装open-jdk-1.8

sudo apt-get install openjdk-8-jdk java -version #出现1.8说明安装成功

3、注册七牛云，用于文件存储

注册 七牛云 后实名认证

新建对象存储Kodo，访问控制设为：开放，记录bucket名字和存储区域

绑定域名（免费分配的测试域名一个月后过期） 获取accessKey，secretKey以备后续配置

此时可买好域名并备案好，一个用于首页，一个用于七牛云。

4、修改jar包和配置文件

打开jar包，剪切或复制所有.yml到.jar同级目录下（优先使用，原理见jar 包启动时,读取配置文件优先顺序）

根据官网修改配置文件（放外面就是方便修改和升级）

domain: 您的站点域名  # 数据库连接配置 datasource:  master:  url: jdbc:mysql://127.0.0.1:3306/teachingopen?characterEncoding=UTF-8&useUnicode=true&useSSL=false&tinyInt1isBit=false  username: teachingopen  password: teachingopen  #Redis连接配置 redis:  database: 1  host: 127.0.0.1  password: ''  port: 6379 #七牛配置 qiniu:  accessKey: 您的七牛accessKey  secretKey: 您的七牛secretKey  bucketName: 您的七牛bucketName  staticDomain: 您的七牛域名

将jar和所有.yml配置文件上传服务器（整个一起，保留同级关系）

4、修改前端

将web-2.6.zip上传，解压，修改index.html

 window._CONFIG['qn_base'] = "//qn.open.teaching.vip/" //七牛域名 window._CONFIG['qn_area'] = 'z0' //七牛存储区域 z0华东 z1华北 z2华南 na0北美 as0东南亚

5、配置nginx反向代理

server
{
    listen 80;
    server_name open.teaching.vip;
    location / {
      index index.html index.htm;
      root /www/wwwroot/teaching-open; # 改为你网站目录的路径
      if (!-e $request_filename) {
          rewrite ^(.*)$ /index.html?s=$1 last;
          break;
      }
      gzip on;
      gzip_min_length 1k;
      gzip_comp_level 9;
      gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;
      gzip_vary on;
      gzip_disable "MSIE [1-6]\.";
    }
    
    location ^~ /api
    {
        expires 0;
        proxy_pass              http://127.0.0.1:8080/api/;
        proxy_set_header        Host 127.0.0.1;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        add_header X-Cache $upstream_cache_status;
        add_header Cache-Control no-cache;
    }
}

切换到.jar目下测试一下能否正常启动

cd /home/ubuntu/techingopen java -jar teaching-open-2.6.0.jar

看到启动成功，接着可以配置开机自启，我用的是启动脚本，将其加入开机自启即可。

特别注意的是，启动命令一定要在脚本里写上，切到jar目录下，再执行启动jar，否则会搜索不到jar包的配置文件，默认会从脚本的当前目录下搜索，也就脚本所在的目录，所以一定先切换目录再启动。

jar 包启动时,读取配置文件优先顺序

最好一切配置完成，安全起见 把宝塔的8888端口 关闭掉。（云服务-安全组）

步骤整体比较繁琐，难度较大，不想动手的，来找我吧，感谢大家关注！

嗨！大家好，我是小蚂蚁。

“我不会写代码，还能做游戏吗？”不少想做游戏的朋友可能都会有这个疑问，答案当然是“能”。

在这个时代，你不懂摄影，但是却可以用手机轻松地拍出好看的照片；你不懂图像处理，但是却可以一键让你的照片显示出各种各样的效果；你不懂画画，但是却可以通过语言描述，让 AI 帮助你画出你可能凭借自己永远都无法画出的作品......工具在不断的降低创作的门槛，让越来越多的人能够做一些原本只有少数人才能做到的事。

即使不会代码，也并不影响你做游戏。会不会写代码，并不是做游戏的必要条件。

感谢工具的力量，是先进的工具让做游戏这件事对很多人来说成为了可能，下面我就为大家介绍几个不需要写代码，也能够做游戏的工具。

1.GameMaker

官方网站 : https:// gamemaker.io/zh-CN/game maker

在独立游戏开发者的圈子里非常的有名气，已经诞生过很多使用这个工具制作的有名游戏了，例如那个你可能听说过的《去月球》，《废都物语》。

这个游戏制作工具是可以免费使用的，但是如果你想要将做出的游戏导出到某些平台的话，是需要收费的。

如图，对于个人游戏开发者来讲，大概需要一个“INDIE”版本，一年的价格是 100 美元。

2.BuildBox

官方网站： https:// signup.buildbox.com/

也是一个有名的通过拖拽搭建各种组建，就能够快速制作出游戏的可视化工具，可以制作 2D 和 3D 游戏。无需编写代码，也能快速的制作出游戏。

这个工具也是可以免费使用的，但是想要用到某些功能就需要收费了。

3.GDevelop

官方网站： https:// gdevelop.io/

这是一个免费开源的无代码可视化游戏制作工具。可以将游戏到出到 PC，移动平台或者是网页端。

工具中包含一个易于使用的强大的事件系统，无需编写任何代码，通过各种事件描述来实现游戏逻辑。

以上 3 个都是国外的可视化游戏制作工具，下面来介绍 2 个国内的可视化游戏制作工具。

4.唤境

官方网址： https://www. evkworld.cn/

国内发展的比较好的可视化游戏制作工具，无需编程，也可以靠着比较强大的编辑器做出各种类型的2D游戏。

可以将制作的游戏导出到 PC，移动，H5 等各种平台，另外还有很重要的一点，使用是免费的。

5.微信小游戏制作工具

官方网址： https:// gamemaker.weixin..com

微信团队的一个还不是很成熟的可视化的游戏开发工具，无需编程，使用积木块像拼积木一样的来搭建出游戏的逻辑。仅支持制作微信小游戏，使用也是免费的。

以上是 5 个不用编程也能做游戏的工具，希望可以给你一些参考和帮助。

不少人对于可视化工具是有偏见的，尤其是技术圈的人，认为这些工具只能玩玩，做不出来像样的游戏。但是任何一个可视化工具基本上都能拿得出不错的作品，而且这些作品基本上都是一些不懂代码和技术的人做出来的。

这是一个很有意思的现象，会写代码，开发技术高超，就一定能做出好游戏吗？好像不一定。每一种工具的产生自会有其产生的理由，有的工具是给会写代码的人用的，有的工具是给不会写代码的人用的，但是工具不是目的，最终的游戏才是目的。因为玩家更关心的是游戏到底好不好玩，而不会去关心你到底是用什么做出来的。

熟悉我的朋友可能都知道，在以上的 5 个可视化工具中，我选择了最后一个微信小游戏制作工具。是的，就是看上去最不成熟的那个。至于为什么要选择这个呢？因为它有一个其它 4 个工具都不具备的优势。这个优势就是它是微信的，它能够制作微信小游戏，凭借这一个优势就超越了其它所有的缺点和不足。你可能体会不到这个优势到底在哪里，可以看一下我之前写的这篇文章。

同样的一个工具，在好的工匠手里是打造出精美物件的利器，在不会使用的人手里无非是多了一个无用的东西而已。工具会不断发展和变化，但是好工匠的手艺是不会变的。

但愿我们能做一个好工匠。

我是会做游戏也会教你做游戏的小蚂蚁，想学习做游戏的话，欢迎关注我的微信公众号【小蚂蚁教你做游戏】，学习更多做游戏的原创教程。

以下的小游戏都是我使用微信小游戏制作工具做的，闲暇之余希望能给你带来片刻的放松和愉悦。无需下载安装，点击下方的游戏卡片就可以直接玩啦！

版权声明：

本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。

本文网址：https://www.mushiming.com/mjyfx/189.html