由于各种各样的原因，最近决定对自己做一次回滚操作。其中一项就是回过头来重新搞cocos2dx，做2D游戏。

一年多没有关注cocos2dx了，变化很大，最重要的可能要数cocos creator的推出了。具体的内容大家可以看王哲今年年初发的那篇文章《对不起，我们来晚了》。正好最近空闲比较多，也研究了一下这款新编辑器。总体来讲，有以下几点感受：

1、编辑器设计思路全面倒向Unity

打开编辑器的第一个感觉——跟Unity好像！界面布局，功能模块，资源管理，组件化，脚本管理，操作方式。都跟Unity很像，所以像我这种用过Unity的人上手就非常容易。这一条，我觉得是一个很大的进步。当初我们从cocos2dx转向Unity一段时间后，我曾信誓旦旦的说过：再也不想回去搞cocos2dx了。其中最大的一个原因就是编辑器上的差距。

我们当时用过的cocos studio我觉得是一个很大的弯路，从工作流的角度看，它更像是unreal，分成了动画编辑器，UI编辑器，场景编辑器，数据编辑器。思路就是建立一套游戏开发的流水线，然不同的角色专注于一个编辑器的使用。但是这需要有一个前提，就是大团队、大项目可以这样去组织开发，但是它并不适合小团队，而在我看来小团队才是cocos最需要关注的目标客户。当时我们的整个项目，就只用到了UI编辑器和动画编辑器，而在分工上也没法做到那么清晰，经常需要一个人打开两个编辑器去做一件事。反而更不方便。加上cocos studio编辑器本身的稳定性和效率有各种各样的问题，而且跟引擎配合的并不是很好，经常需要为了编辑器去改引擎代码，打补丁。所以那次用cocos studio并不是一个美好的回忆。

回过头来看cocos creator，借鉴了Unity已经被验证过的设计，这条路我觉得走对了。

2、全面倒向JS

在王哲的文章中，大篇幅的解释了选用JS作为开发语言的原因。我觉得已经说的很清楚了。打开编辑器后，我用Spy++抓了一下窗口，马上就体会到了他们做这种决定的决心。

连他们的编辑器都是用JS做的。其实整个编辑器就是一个Chrome浏览器，编辑器中的所有内容其实就是一个网页。编辑器的所有功能都是用JS实现的。仅从编辑器的开发上讲，这样做的优势很大，就是开发快。我们当时做浏览器的时候就深有体会，我们用C++吭哧吭哧做的UI和一些效果，人家FE用JS分分钟就实现了。当时腾讯的一版QQ浏览器（已被砍）的主UI就是用Chrome + JS的方式做的，我当时也跟同事们讨论过这样子做是否可行，在当时看来，这样做的有一个很大的劣势，就是浏览器的启动速度。我们当时对这一点可是极其敏感的，所以就不考虑了。但是同样的技术用在一个游戏引擎的编辑器上，就没有问题了。

3、路还很长

看到这些以后，我还是有些小激动的，就用它试着做了个demo玩一玩，看看是否可以考虑用它来做项目。玩了几天初步的感觉还可以，至少编辑器的本身的稳定性还不错，没出什么大乱子。但是如果用它来做商业项目，我觉得目前这个版本还是算了。主要有以下几点：

1、Html5与Native并没有做到无缝衔接。理想状况是，我写的同一套代码，在网页版下开发调试，最后一键打包到各个平台上。这一点目前并没有实现，原因是JSB的绑定和网页版JS的接口还不匹配，这个亏我是吃过的。当初开始用cocos2dx做游戏的时候，就选择了用cocos2dx-html5开发，然后同一套游戏代码用JSB打包。但定好技术路线开始做的时候，才发现，根本不行，两个版本的接口并没有统一，有一些接口需要自己去做JSB绑定，虽然自己去绑并不难，但是对开发团队来说，发现不行-找原因-绑定-测试这些都是成本。而且当时在网页版上开发，游戏一复杂，就有很严重的效率问题，最后没办法，还是回到windows JSB版上做开发了。

2、缺少一些必要的功能，比如自定义shader，我觉得这一点很重要，否则很多效果没法做。虽然目前可以用一些hack的手段用上自定义shader，但是毕竟不是公开接口，缺乏安全感。

3、缺少编辑器内的调试方法，就是Unity中的Scene窗口，可以在游戏运行的过程中，去编辑场景中的各个节点，验证一些想法，这样可以大大提高开发效率。目前cocos creator采用的方式是另外开启一个浏览器，或者模拟器窗口，去调试游戏，尽管chrome提供了很方便的调试环境，但是不能直接在场景中进行编辑。按说按照目前的编辑器技术架构，这一点是可以实现的。只不过这个功能的开发成本可能要大一些。

现在对这套东西的认识还很浅，就先写这些，后面也会持续的关注。

最近这两年的经历告诉我一个团队做出一种选择，并不像外人看到的那么容易。cocos2dx团队一路走到今天在外人看来牛逼也罢，傻逼也罢都不重要，重要的是早日找到正确的路，坚定地走下去。