怎样快速制作一个图形化的逻辑编辑器？

如果只是您题图里面那个，可以直接集成Blockly，完全基于HTML5+JS

如果要做成连线图这类的，我之前WPF做过一套，有商业控件可用，HTML5+JS这类控件就更多了。

不过想提醒一下题主，我之前WPF那个，断断续续做了 大概半年多的时间才初步成型、一年多的时间才基本可用，两年多的时间直到我后来离开项目也磕磕绊绊，还有许多一开始的设想和功能没有实现 。

所以快速制作这个实在很难讲，因为我做这套系统花的时间确实是比较长，虽然中间牵扯了其他的开发业务，但是仍然感觉到这不是一个很容易的工作，粗略列举了一些我自己遇到的问题，希望对题主能有所帮助。

当然，首先，个人水平有限是一个方面，重大系统设计决策时犯过一些错误，比如自己做了套解释器，而没有一开始强推引入其他脚本，技术选型上选择了WPF而不是HTML5+JS，不过做的那会儿大概是12年，前面那个是整个项目的客观情况限制不得已为之，后面那个则是当时确实技术嗅觉不够，找到一个GoWPF试了试可以用所以就用了，结果几乎没人能接，WPF在国内游戏圈还是小众了点。还有一个方面是当时用的引擎是CE，不支持反射，为此几乎重头做了一套反射系统，这些都浪费了不少时间。

另外一个方面就是对业务逻辑的抽象和归纳过程中有许多细节问题，这些细节问题可能远比单纯做一套图形界面、连带支持Ctrl-Z、Ctrl-C、Ctrl-V要复杂很多。就先说CtrlC、V、Z，这几个问题可能做的时候，如果一开始没做过类似系统的就能卡不少时间。然后如何持久化，是分散持久化还是整合持久化，如何保证多人开发时各自的版本最后能够统一，而且还得跟当时他的数据环境能够统一起来？（策划操作，最忌讳的就是数据和功能版本不一致，他连他个人数据库，用的是你新的功能脚本，这往往得出事儿，怎么能把这个问题解决掉？或者一开始就先警告？）

好几年了，当时一路的过程中解决的问题都是一开始没想到的，现在印象里也不是记得特别清楚了，准备休息，所以写得先简单点，抱歉了，我后面想到的话会再补充：

基本实现：

前面CVZ可能首当其冲就是得考虑的问题，然后就是New/Load/Save/SaveAs/Compile这类持久化、工作流的问题，看起来小，做起来的时候都是工作量。比如SaveLoad，要不要考虑文件版本问题？后续如果修改文件格式，没有版本记录该怎么办？节点函数调用型变化之后，重新加载过程中会不会出现异常？加载后，旧版本节点本身的连线是直接丢失掉还是先缓冲下来？语言本身的特性上的Co-routine和代理也是个大问题，Blockly也好，什么的也罢，这个东西都不会是原生提供的，都需要自己想办法体现出这些的概念来。

关于功能接入：

逻辑可以连线了，怎么把程序各个模块的功能用更简单的方式接入到这套图形系统中？最好是程序那边做个函数加几个Attribute描述，这边就可以自己多出几个节点出来，那么这个东西要不要开发？影响旧模块的部分要不要修掉？许多功能过于程序化，程序自己调用的时候都N个地方N种调法，public函数满天飞，抽象度封装度严重不够，这些函数和类的流程是不是要重新修理来提供一套鲁棒性强的调用型？

关于数据整合：

数据系统往往是读数据库的，怎么在脚本里获取数据的时候能跟数据系统打通？最简单的方式是具名访问，但这样手误填错了怎么办？这种情况现实中很常见，脚本A维护，没改名，数据B维护，改了下表结构，于是就出问题了。怎么在这类情况发生时快速定位到问题源？要不要考虑？

调试系统：

调试系统要不要做？策划拿这套图做出来问题之后，他们自己怎么能知道问题发生在哪里了？如果遇到问题就来找程序，那么做这套图的意义很大程度上就没有了——这在我的经历里面是切肤之痛，一开始第一年没有做调试和断点系统，结果……当然如果您集成Blockly，本身是会有一个初步的断点调试Sample的，但是仍然需要您自己去做很多相关的工作，因为调试不简简单单是一个断点就完了的。局部数据怎么看，全局数据怎么看，运行时数据表怎么看，都需要工作量。调试系统我印象里自己是前后花了3个多月的时间才算搞稳定，而且还只是个初步能用的版本。

关于脚本机制：

图脚本的运行机制如何？是直接解释还是翻译为其它目标脚本代码？自己做解释器，那有的做的，我当时选的就是这条路，是因为当时已经决定了最后是生成目标C++代码，解释器就是个临时搞出来，然后方便自己做调试器的选择。如果是要翻译为目标脚本代码、则需要看本身项目脚本的引入情况。没有一个有效的脚本系统的情况下，首先得先去做一套脚本系统。有脚本系统的情况下，就牵扯到图本身翻译为脚本语句的问题。Blockly这种还好，有Samples帮你做，而且本质上这就是一个序列式的图表化。但是如果是那种完全无限制的连通图，像UE4的Blueprint这种的，那么节点环路时的代码如何生成？（一不小心就是个死循环和大量废代码，或者大量function）。Latent（Co-routine）节点要不要有？有该怎么去生成代码？（一般是Functor）策划连的代码性能出问题了该怎么处理、怎么定位？

关于逻辑和同步性：

同步性该怎么抽象？我没有太好的答案，因为我当时的做法挺混蛋的，这个事儿我也交给策划了，（当然，后面看UE4的蓝图也是一个样，稍微有那么点感觉自己好像也不是那么笨：P）。但是这个说实话，并不是很棒的方案，策划用不好的情况下带来的问题要比解决的问题多，到最后程序得去做同步图，那意义就不大了。当时我其实构想了一些新思路，但是推想过程中就有很多问题，强调通用性的话是没法做的，基于项目，钉死一系列假设，理论上是可以把同步过程也收束住的，但是代价就是不能那么灵活了，而且以后换一类项目这个工具都需要重新翻新。

关于项目和团队：

最后还有个问题：策划为什么要用？怎么推广？Help怎么做？Sample怎么做？因为不同项目团队，由于构成不同、做的东西也不同，可能做事的方式和方法已经形成定势，或者各有各的势力范围，推广这个东西是一个讲政治的事情，有些人会认同，有些人会反对，由此导致的一系列的问题怎么解决，策划用这套东西做出来的东西出了问题，最后是谁的责任？如果是策划的责任，那么从策划的角度来讲，为什么要接这个工作？会给他带来什么足以让他去承担风险的利益？这些虽然可能做的时候不需要考虑，但是推广的时候可能很难避开这些问题。因此导致团队内部的矛盾和风波，在多数情况下可能会得不偿失，而使用这套体系要重新磨合团队，这个磨合期大概要多久？从小的方面来说，业务逻辑从大到小有很多很多部分，表现型逻辑这按理说不应该是传统策划的事情，而应该是动作和特效的工作，单纯游戏机制的话则远不需要那么复杂，UE4有蓝图，Unity也有一套类似插件（我忘了名字了），现有的框架是否已经足够完成业务？

（2017-6-7补充两句）关于这个，我的感觉是一般策划主管、系统设计师并不会太推崇这个东西，因为他们业务过程中实际上需要聚焦的重点并不在这些地方。具体某个模块，特别是表现模块、技能设计师、关卡设计师这种机制-表现混合方面的设计师则会比较愿意用，毕竟这比去看程序大爷的眼色要好很多。对于后者，问题是是否真的有必要使用图系统，还是说简单封装的Lua脚本就可以做到？这两个的开发不在一个量级上。

如果您需要现成的参考的话，UE4里面有一套Blueprint系统是有代码的，它的调试、数据打通、包括Native代码生成这些Feature都是做的比较完善的，可以参考一下结构设计（虽然个人不完全认同它全部的设计，但是作为一个完整系统，这个的参考价值是很高的）。HTML5的连线图系统很多，一部分也可以F12扒代码学流程。

如果您还在选型，我强烈建议您基于Blockly来做选型，而不要考虑连线图这种，连线图看起来很好，但它引入的问题比它看起来能解决的问题要大得多。而且策划，全功能交予本身其实也是有问题的，一般来说用图都多是用一些抽象度较高的功能，这种情况下，连线图所提供的高灵活性其实是蛮鸡肋的，绝大多数情况下用不到。而典型的Co-routine机制，比如Wait-for总共也就那么几种，用到的地方也不会很多，对应做一些特殊节点来处理就好。大部分情况下策划只需要处理好一些简单接口的调用序列、以及读写数据就已经足以完成绝大多数他们需要的东西了——可以参考War3编辑器，基本都是简单序列+数据读写，足够做出丰富的功能了。

但即便如此，打通数据、提供调试功能、以及对项目组的一系列深远影响，可能都会在铺开的过程中慢慢体现出来。个人感觉，一旦开始这个业务，很可能需要的时间是来自于后续的一系列团队反馈的实际问题。

因为毕竟 从开始做的那一刻起，可能我们的定位已经变了，从一个游戏项目的开发者变成了一个游戏工具服务的提供者 ，这一点我也是直到最后才意识到，对于游戏工具服务要考虑的一系列问题，都需要考虑，都需要解决，而 这跟搞业务其实是有很大不同的 ！

我虽然做过这么一套东西，团队对我也没有指责和太多不满，但是，我现在内心深处充满了深深的悔恨和愧疚，一定程度上可以说这样的一次冒险，是我理想主义、不成熟和轻狂的表现！虽然做的过程中把客户端服务器的接口体系、类体系重新捋了一遍，项目组据说在后续的使用过程中，在技能设计和boss战上也因此可以由策划自己做出来一些玩法。但是，很可能我对项目带去的问题，比解决的问题要多，当时如果能选择更保守一些的方案，比如类似War3编辑器这样的方案，也许最后的结果能比现在会好很多很多。

就像Behavior Tree，它是AI的一个比较新的方案，看起来它也能解放策划的生产力，但它并不适用于所有的项目类型、同样不适用于所有的项目组织形态，比如那种全游戏只需要一类AI吃遍天下的，这种基本不需要那么繁重的试验任务，设计上也有很明确的思路，只要策划总结思路出来，程序或者脚本将其实现出来就可以了，上BT反而是舍近求远。所以同样是BT技术，有的团队能用好，有的团队用就尽是灾难，还不如最后回到传统的AI状态机体系。同样的道理，我不是说类似UE4的Blueprint这套体系没有用，我只是想说，这套系统非常适合原型期小团队快速出原型。一个不基于原型开发来组织的团队形态，是根本不可能调度好这种图系统的，就跟你程序需要一个核心架构设计，所有类结构都只能从这个核心架构设计思路向外延展的道理一样。不基于原型开发来的组织形态，一开始堆就是几十上百人，核心图、外围图很容易就做乱套了，对于这样的团队形态，反而看起来笨拙的程序堆功能、策划写文档是最稳态的结构。换句话说， 为了灵活来做了一套工具，但团队组织上根本就不容许这样的灵活，那么这个灵活带来的唯一作用就只是破坏 。

此外，图系统真正的优势，和让策划去写脚本、调数据表的道理是一样的，要同时打通跟其它各个工作流之间的关系才能体现出来。在图开发的过程中，可以有效地指向资源、指向动画和特效、引用数据、进行数据监测和流程调试、且对于可能的错误有所预判，才能体现出它的真正优势。而工作量和设计上恐怖的地方恰恰在这里 。UE4的蓝图为什么推荐，恰恰是它同时已经打通了跟动画、特效、场景等一系列外围系统的通道，如果它能恢复到UE3当年Atlas的水准，那它将更加恐怖地能够胜任大规模MMORPG的原型设计。原型期前面说了，而一旦脱离原型期，进入到资源和数据的铺量阶段，个人感觉这个时候宁可游戏的核心逻辑体系、无论是图做的还是代码做的，都不要发生大的变动较好。这时候的调整更多发生在外围逻辑、拓展逻辑和表现力逻辑上，用图的重点恰恰是在这几个工作流部分，但这部分如果用脚本的话，同样很轻量，学习成本同样会很低，策划连写个PlaySound，Delay，PlayAnimation 这种序列都学不会？真学不会，给他们做个读表、根据表来调这个那个的，整体成本也要比做一套这么老大的系统要简单很多啊！

国内的开发团队少有严格意义上那种策划先行的原型开发的流程，特别是Unity开发团队就更是如此了，这种情况下，我个人感觉还是得结合自己项目团队和项目的实际来决定技术选型，先针对小系统去做小的工具，慢慢滚出一套大系统来，可能会比我当时激进的那条路要更稳一些。

当然，以上所有这些，也许只是一个老兵畏畏缩缩、没有冲劲、混吃等死的表现。到底怎么样，我相信其它人一定有比我更聪明的方法来更好地解决这些问题，或者规避掉这些问题。无论如何，实践是检验真理的唯一标准。个人惟愿题主在项目中推进这套选型之前，能先自己玩一阵子，介绍给朋友玩一阵子，或者先去玩玩UE4的蓝图体系，再认真考虑考虑再做决定。

无论如何，祝题主好运！