BoomEditor是一个windows下用于cocos2d的UI编辑器

cocos2d下的主流编辑器对比

• cocoscreator ccc的思想和主流引擎编辑器思想是一样的，组件化的系统，资源和代码的统一管理，变量的反射和绑定。这些特性很好，但它还是有自己的痛点:

• cocos2d下大量项目都使用lua而不是js，ccc对使用lua的人来说，基本没有什么用，即使出了lua版本，但也只是简单的一个解析库而已，很多ccc的控件不能用，更不用提代码反射和绑定。
• ccc的代码绑定让所有业务逻辑的代码都生成到了一个脚本文件，这在热更新的时候非常不便
• 控件的丰富虽然方便了程序的开发，但也导致了臃肿和运行效率的下降

• cocostudio 其实ccs还是可以的，但是在做好2d和做好3d中迷失了方向，结果3d没做好，2d也没做好，典型的，ui界面的动画，看似可以创建多个动画，但其实屁用没有，所有动画都会在布局文件解析为场景的时候全部播放，连一个选择手动播放和自动播放的机会都没有;对于解析布局文件，ccs只给出了解析方法，并没有给出解析方案，有些经验的人才能做到用C++搭建一个框架，然后用ccs解析界面，串起游戏流程，经验更丰富的人才能将布局文件跟脚本关联起来串起整个游戏流程，而这些ccs一个示范都没有给出。

• cocosbuilder 作为一个ui编辑器，ccb还是很好的，它在c++层给出了解析方案，所有想要关联布局文件的类必须继承一些接口，用户代码通过实现这些接口来绑定变量和回调函数，你一旦理清它的解析流程，就会知道如何串起整个游戏流程，即使维护别的ccb项目，也能轻易上手，但是它对脚本并不友好，cocos引擎目录下的testjs和testlua虽然有对应的脚本解析的列子，但并不实用，对实际项目几乎没有参考价值，网上也没有看到相关的blog去尝试在脚本环境中使用ccb，我有尝试过将ccb的解析和对应脚本关联起来，通过ccb文件自动生成关联的脚本文件，可以用，但比较依赖于具体项目，通用性不大，就没有公布出来，也没有用于具体项目。

在我看来，可能对于大多数开发者来说，并不是想要一个高度集成的引擎编辑器，而只是一个ui编辑器+类似prefab的东西+对应脚本(lua, js)的解析方案就足够了，ccc除了lua的解析方案，基本全齐了，ccb和ccs其实也有类似东西，不过它们都是引用的布局文件，只是引用，但可以改变根节点的一些属性，比如位置，缩放。而ccc的预制则是完全克隆一个，可以对它进行添加删除等操作。

ccs和ccb可以引用布局文件，如果一个布局文件对应一个c++对象或者lua对象或者js对象，那么，如果一个布局文件中引用另一个布局文件，讲道理，那么也应该引用对应的c++对象或者lua对象或者js对象。但是当ccs解析的时候无论你引用了多少布局文件都只会生成一个场景树，并把根节点返回出来，对应的引用对象呢？场景树里面自己找吧。但是ccb在c++层就做得很好，你如果引用一个布局文件，生成整个布局文件的时候它会把关联的对象创建出来并返回给你。在脚本层，ccb和ccs一样只能拿到根节点(我关联ccb布局文件和脚本对象的时候改了不少源代码才关联上的)。

ccs和ccb中的引用来嵌套布局文件，而ccc的prefab则是通过复制的方式来嵌套布局文件，克隆和引用哪个好？引用的话只要改了原布局文件，所有引用该布局文件的地方都可以同步更新，但也必须保持和原布局文件一样，克隆的话虽然可以改动，但是prefab本身的改动并不能反映到用了该prefab的布局文件中，除非选择回退，但是回退又完全撤销了自己的改动跟新prefab一样，但这可能不是大多数期望的用prefab的目的，大多数用prefab的目的应该是引用的布局文件和原布局文件保持大部分一致，但又有自己的单独的一些改动。但市面上没有哪个编辑器这样做。

对比之后，我理想中的UI编辑器的样子大概就出来了，常规的UI编辑器功能+属性可修改的布局文件引用机制+脚本（lua，js）解析方案，这就是BoomEditor

快速开始

打开BoomEditor下GameUIEditor.exe，点击File->OpenDirection,选择本SampleProject目录。该工程是一个斗牛牛游戏界面的简单示范，资源来自某个上线的游戏。发布的时候，选择project->setting，设置发布目录，设置完成后，选择project->publish，发布之后，发布目录下就有用于游戏的资源和布局文件了。代码实例参考Sample-lua和Sample-js文件夹。

功能说明

• 支持新建文件，新建目录（需要在打开工程目录之后），目前只支持Node和Layer类型的布局文件
• 支持Crtl+S保存布局文件，切换布局文件的时候也会自动保存;支持Crtl+Z撤销更改
• 支持视图的缩放以及移动，可设置UI的设计尺寸
• 支持常规的节点元素，Node,Sprite,Layer,Label,ClipingNode，和一些ui元素，对应着cocos下gui命名空间下的元素，Scale9Sprite,Button,CheckBox,LoadingBar,Slider,TextField
• 支持节点元素的拖拽，复制，剪切（剪切只能作用于同一个布局文件），删除，粘贴操作，目前还不支持快捷键，只能通过鼠标右键单击来操作
• 支持资源的拖拽，图片资源支持plist，png，jpg，字体资源支持fnt，ttf
• 支持嵌套布局文件，可对每一个嵌套的布局文件进行编辑，且在编辑的时候只能编辑当前布局文件所包含的内容，页面上不属于该布局文件的不可编辑
• 支持Label的字典，字典文件为工程根目录下的language.json，设置Label的Text的时候，会首先查看字典文件有没有对应的键值对，有就显示键值对的值，如果没有就会显示原始内容
• 支持编辑动画，动画模式下支持节点的位置，缩放，透明度，旋转的变化

特殊说明

• 一些属性是只读的，不允许设置，例如Sprite和Label的Size属性
• 复制和粘贴节点的时候，Layer只能作为Layer的子节点或者根节点，不能作为其他元素的子节点
• 对于图片资源文件请拖拽，因为单个图片资源和plist的处理方式不一样
• 对于常规的Node节点属性，编辑器中多了PositionType和SizeType属性，这两个属性参照了cocosbuilder的这两个属性，原理和作用都与其一样
• 嵌套的布局文件只能修改属性，不能在其布局文件中添加节点或者删除节点，要编辑嵌套的布局文件，请选择该节点，然后单击EditFile按钮，编辑完毕后，点击Parent返回上一级，或者点击Home返回根布局文件

解析库说明

解析库在LoaderLib目录下，Loader.js和Loader.lua分别对应js和lua版本，require方式请参考main.js或main.lua。解析库暴露了5个接口出来：

• setScriptBindingFunc

• 用于设置布局文件与脚本对象关联的函数，这个函数接受一个字符串指向该布局文件的路径，返回一个应该与该布局文件关联的对象

• beginLoad

• 接受两个参数，参数1为布局文件的数组，参数2为这些布局文件解析完后的回调

• creatByFile

• 接受两个参数，参数1为布局文件路径，参数为将要成为其父节点的节点（creatByFile不会addChild到这个父节点，只是在解析的时候需要这个父节点的size），返回解析出来的场景树的根节点对象

• getMember

• 用于解析后绑定对象到变量，详细参考Sample-js或Sample-lua的代码

• playAnim

• 用于播放动画，详细参考Sample-js或Sample-lua的代码

FAQ

• 什么是属性可修改的布局文件引用机制？
• 这种机制本质上还是和ccb和ccs一样，不过给了用户改变其属性的机会，但只能改变属性，不能增加节点，删除节点，改变节点顺序。编辑器会记录用户改变的属性，并跟原布局文件进行比较，然后会比较差异属性，并保存到布局文件中，在解析的时候，修改后的属性会覆盖原先的属性，这样既保存了引用的布局文件的大部分属性，又能有自己的独有属性，可以参考SampleProject中的Poker.bui和Player.bui

• Loader是如何关联布局文件和脚本的？
• 在开始解析的时候，Loader会调用根据setScriptBindingFunc设置的函数来获得一个脚本对象，然后解析布局文件，根据布局文件的根节点的属性来设置这个脚本对象的属性，所以，这个脚本对象必须是一个node对象，然后根据布局文件创建子节点以及设置子节点属性，并添加到脚本对象的节点树种，同时也会记录每个节点的uuid，name，以及node对象的引用，也会记录Button等控件的回调函数，解析完成后，就会调用脚本对象的loaded函数，并将成员列表和回调函数列表作为参数，由脚本对象内部来进行变量绑定和回调函数绑定

• 发布工程的时候不能发布为二进制文件吗，json解析效率没有问题吗？
• 如果用脚本来解析，解析json是非常方便的事情，解析二进制返回会比较麻烦。json解析确实是有效率的问题，但需要实际测试，如果有效率问题，可以使用beginLoad来异步解析，甚至可以在游戏开始的时候全部解析并缓存起来，需要的时候在创建为场景树

• 这个编辑器为什么这么大？用的什么技术？
• 程序由1个winform的壳以及4个浏览器窗口加1个渲染窗口组成的，把浏览器嵌入到winform里面用的是CefSharp，渲染窗口是cocos-js实现的一个窗口程序，由winform作为其父窗口来实现的，5个浏览器窗口分别用于显示工程目录资源（主要用fancytree实现），布局文件节点信息（主要用fancytree实现），控制台信息（空内容的html页面），节点属性信息（vuejs实现的属性绑定以及属性变化监视），动画编辑窗口（cocos-html5实现的一个html界面，其界面本身就是由BoomEditor制作的，相当于一部分功能的自举），帧属性窗口（同样基于vuejs实现）。程序大的主要原因是CefSharp本身很大（可以理解为自带一个chrome程序），而且cocos-js也不小。所以导致很大。

• 只比较了这几种编辑器，还有其他编辑器呢？
• 也有试过其他编辑器，确实没有理想中的编辑器，比如x-studio365，确实很强大，功能很多，但是不能引用布局文件(如果有，也是ccs那种),没有对应的脚本解析方案，还有fairy gui，没有cocos的解析库，没有布局文件引用，也没有脚本解析方案。

• 为什么只开源了部分代码，编辑器本身不开源吗？
• 几个html界面是源码，编辑器的解析部分编译成了jsc，这部分的代码其实比较乱的，我需要花点时间整理下，winform部分没有开源的打算，winform部分我也没做混淆，你如果反编译，也是看得到代码的。

• 编辑器既然不开源的话会持续维护吗？
• 会持续改进的，因为这是我对这几年游戏开发的思考的一个成果，也希望得到更多的人来认同我这么一个想法，更多的人来使用它。

交流群

qq群：465795366

一些预览