「分享」纯手工自制最适合Creator的地图编辑器

Cocos 引擎

于 2017-09-06 00:00:00 发布

阅读量56

点赞数

原文链接：https://mp.weixin.qq.com/s?__biz=MjM5ODAxNTM2NA==&mid=2659645465&idx=1&sn=8890c39d8478c149a0874d561e2d6307&chksm=bda360f28ad4e9e45736d633ec58a20974dc4f9551cfff01ddc3d0d0c98d50edeeefcdc4d84b&scene=27

版权

感谢社区ID：隐形人友情分享

前言：

头几年就想做一个自己的地图编辑器，最近总算是有点时间，就抽空做出来这么一个东西。原本是打算集成一些我自己常用的代码，随便点点就能出游戏的软件。但是又不想屈居于一种类型的游戏，想灵活多变工程量还是蛮大的，所以就先放出来见见光吧。

编辑器名为黑小孩，下面开始正题，我不想夸它怎么怎么样，好与坏自己感受吧。

特点

黑小孩基于plist编辑图块，可自定义图块大小。

黑小孩图层分为地形层和对像层两种，其中每个地形图层都可以重新定义图块大小和图块数量。

黑小孩的对象层，拥有更多的图块属性，且在导出JS文件时，不对其进行任何操作。

黑小孩可完美导出ccc的fire文件，和记录所有地图信息的JS文件（以下只演示fire文件）

黑小孩可以添加调用属性，其中包括ccc的碰撞组件和记录位置大小的点矩形等信息。

黑小孩拥有强大的边缘生成功能，可以对图块的上下左右四个方向，最多进行六种不同图块的随机生成。

黑小孩集成了Plist生成功能，可不借助外部软件，进行图片分割。

无图区

每个功能都截图，估计我能玩一天，实在是太费事了，所以图片先到这儿吧。这里只是介绍不是教程，教程我在下面会放。介绍一下你们关心的事吧。

首先说一下黑小孩与ccc的兼容，因为黑小孩是反向支持ccc的，它不可能自定义一个ccc不认识的格式，让ccc运行。所以黑小与ccc兼容方式很简单，就是黑小孩发布ccc认识的文件。这样来说，其实黑小孩每个图层就是一个空Node，每个图块就是添加在这个图层Node里的子Node。你改变这个图层Node上下层顺序，甚至从显示列表删除，都随意。

黑小孩可以发布fire和js两种文件，但是主打js，原因很简单，因为ccc不适合编译过多的node，试想一下我一个地图有几百个图块（Node），ccc是可以操作的，但是几千几万呢？ccc还能操作？你不用去试，我直接告诉你答案，不能。不用达到上万，几千就够了。那是一种什么感觉，你可以静静的看着它们，你可以缓缓的滑过它们，但是你不可以移动它们，更别说全选了，否则，没有否则！

然后，JS文件中的图块全部都是动态加载的，所谓的动态加载就是素材文件必须全部在resources文件夹，这里要注意。

其实，一开始我原定是输出三种格式的，分别是fire文件、js文件、和fire加js文件，就是通过fire加js绑定免去了纯JS文件的动态加载。但是看了一下原理之后，得出了两个字‘麻烦’，果断弃。

性能（单指JS文件）：

黑小孩发布的JS地图文件，已经做了性能优化，即池对像存取，显示区外清除。比如一个图层Node有一万个图块，但是他们都是相同的，那么JS文件new出的Node可能就只用三四十个，就是刚好足够屏幕显示的，其他全部通过池调换。

再有就是显示区外清除，也拿一个有一万个图块的Node图层比喻，比如这个图层有一万个Node图块，但是在显示区内只有三个，那么进行for(var i=0;i<图层.childrenCount;i++)，这里的childrenCount实际只有三，而非一万。

这种算法不怕定义几万甚至是几十万个图块，怕同屏图块宽高小而多。就是Draw call数量大。

超大地图

我对超大地图没概念，就本身而言，现在黑小孩能达到的数量，已经够我用了，但是实现超大地图的过程，却很吸引我。我大概已经重写了两三个大的部分，以让黑小孩完成对超大地图的支持，但似乎还有几部分要重写，所以打算完成图块动画部分，再对进行超大地图的实现。

现在黑小孩支持图块数量上限差不多是六万，拿宽高100*100的图块来计算。如果做一个高是1000的横版地图，那它的图块数量比就是10*6000，换成地图宽高就是1000的高度*60万的宽度。如果换成1比1的正方形地图，数量比差不多240*240，换地图宽高是24000*24000。

基本情况就是这样，不出意外，以后我大概会把上限提到十几万，甚至是几十万。

关于导出文件大小和优化

因为记录的东西多，所以与TiledMap相比，同等图块数量下，体积是要比TiledMap大的，但这是相对的。

黑小孩的特点是灵活，利用地形图层的一些特征，可以很好的优化它。

举例来说，如果一个图块是32*32的，恰好一个图层要平铺满这个图块。那么如果这个图层宽高是960*960，那么平铺满这个图层就要30*30=900个图块，而JS文件也会记录900图块的信息。但是如果在美工上稍做一点小小的修改，将这个图块的宽高平铺改成96*96的，也就是三倍。那么铺满宽高为960*960的图层，只需要10*10=100的图块。与30*30的文件记录量相比，整整少了八倍。

你甚至可以保留原32*32的图块，利用plist的自定义图块和每个图层可随意图块大小的特征，在边边角角的地方切回原32*32的图块进行修补。可以说如果你plist文件设计的好，不但不会影响你的地图信息，甚至可以在JS文件大小与性能优化上，得到很好的提升。

值得一提的是，尽量不要在地形图层中放过多的超过宽高设置的图块，因为文件记录就是按照地形图层设置的宽高来的，这可以看成一个二维数组，如果地形图层的地形宽高是10*10，而图块是15*15，那么JS文件不仅会在arr[0][0]记录这个图块的ID，也会在arr[0][1]与arr[1][0]记录这个图块的ID。

数量少了不会有什么事，但是多了不但JS文件会变大，性能也浪费，所以尽量不要这么干，但也不用刻意，只要不过份就行。这个过份的量我认为几百甚至过千，都没问题，当然，你也可以按照你的需求来，也没关系，只是如果哪天有人非得这么干，还放了非常多。就不要找我问导出的JS文件为什么那么大了，否则，不好意思，屏幕那边的我一定在眯着眼鄙视他。