Cocos2d－x 之大牛看法

（未完毕）

        cocos2d-x并非一个适合网游client（mmo）的游戏引擎。越是大型游戏，这个小引擎就越无法驾驭（尽管它很受欢迎）。 之前我在原来的公司使用的是自主研发的C3引擎，已经对外开放（尚未开源），后面假设我有提到c3引擎。那么指的就是这个2.5d游戏引擎。

         我想起我上个月刚离职的时候。c3的首席研究员（应该也是引擎圈内的一个大牛）对我说cocos2d-x没有什么技术含量，我还不以为然，当时我想的是，假设我自己开发一个游戏，首选必定是cocos2d-x。

可是真正到新的公司接触了使用cocos2d-x开发的一个类似神仙道的mmo才感觉cocos2d-x对于一个mmo引擎来说。差的非常多。与c3相比。差就差在几年。十余款mmo。上千位开发人员的检验。

尽管cocos2d-x的开发社区非常庞大，可是它适合刚開始学习的人去开发一个愤慨的小鸟、水果忍者，并不适合一个网游公司去开发一个mmo。尽管基于cocos2d-x有非常多不错的mmo，比方忘仙、神仙道。

可是我觉得那是一群牛x的开发人员通过自己的努力弥补了cocos2d-x的不足。

        能够觉得我不是一个牛人，可是一个团队能有一个牛人就已经万幸了，能有两个就可遇而不可求了。一个好的游戏引擎比方c3正是被我们这些普通开发人员来使用，它能够不次时代。能够不面向对象，可是它会很易于使用，而且很难被误用。

        牢骚发完了，以下是详细的优化：

        1、去掉libxml2，改用rapidxml来解析xml文件。

 rapidxml简直是一个大杀器。解析xml的速度甚至比纯文本解析和json格式还要快。其解析速度比libxml2快5倍，即便cocos2d-x中使用的是sax模型，而rapidxml是dom模型，使用rapidxml依旧要快许多。我们的游戏是全部配置文件都用xml来描写叙述，事实上大可不必，可是为了跟网页版本号配置统一。方便今后的维护，临时没有对配置格式进行改动。

而cocos2d-x底层对xml使用最频繁的地方就是Plist文件的解析了。

ios平台下还好，NSDictionary速度也很快（可是依旧比rapidxml慢一倍）。可是android下效果就很明显了。游戏启动时间大大缩短。 所以，为什么cocos2d-x还要用libxml2呢？

        2、游戏资源打包。  这个尽管是能够自己扩展的。可是却是须要引擎提供支持的。由于全部的图片读取都是属于引擎的内部代码。  当然不是全部的游戏都须要资源打包。可是一个有用（mmo向）的游戏引擎这个是必定要考虑的。 这一块儿牵扯到非常多东西，比方游戏资源更新，资源读取规则。读取失败后的异常处理。多线程载入时的同步机制等等。

        3、改动CCAssert，添加日志记录功能。   作为一个游戏引擎。cocos2d-x内部代码非常不健壮，非常多资源不存在或者是不小心的误用都会让程序挂掉。 这个对一个mmo来说是不可接受的。 CCAssert原来是一个简单的assert，这个在ios和android下就直接挂掉了，后面尽管改动为CCMessageBox的提示。可是依旧不够方便，由于这些弹出框都非常卡非常慢。接触过mmoclient开发的应该都有体会资源不存在是常常发生的事情，尤其是大家一起开发功能的时候，资源总是最后才正确且完整。  这个时候记录个log不就完了。

而cocos2d-x却并没有提供不论什么Log记录功能（实际文件Log而不是开发时用的CCLog）。 而引擎内部有大量的Assert，断定文件一定是存在的。断定某个配置一定是正确的，断定某个Frame一定是存在的，这个造成的问题就是一旦有配置错误，那么程序非常可能就崩溃掉了。而作为一个mmo，尤其是已经对外公布的情况下。这个时候出现表现异常(比方图片不显示)而不是崩溃会更加合理。   

        4、资源异步载入。尽管cocos2d-x有提供Texture的资源异步载入，可是这并不够用。 我们改动为这种形式。CCSpriteCache缓存图片的时候异步载入图片。这个时候能够获取到正确的CCSprite,仅仅只是里面的CCTexture并没有附上一个正确的纹理id，当图片载入完成，这个id就正确了，那么CCSprite在下一次Draw的时候自然就会渲染出正确的图片（这里要做下推断。假设纹理id不对那么就不进行渲染操作）。    还有须要注意的就是仅仅有一个线程载入图片是不够用的，依据须要可能要开3~5个线程来载入图片，才会起到异步载入图片的最佳体验。   当然，假设不过怕载入图片卡主主线程而不关心载入速度，那么就不须要这么麻烦了。

       5、加入一个高速渲染的CCFont，不管是哪个平台生成字形纹理的过程都是很慢的。假设一个mmo中有大量的文本、聊天等等。光生成字形的时间可能就要500~600ms，那这个游戏给人的感觉就是时不时一卡一卡的。 这个新的CCFont思路很easy，生成字形的时候一个文字一个文字的进行生成，把生成的字形保存到一个512*512的纹理上。然后渲染的时候取这个生成好的字形进行绘制。

 

       6、计划中： 人物图片使用骨骼动画切片处理，这个事实上应该比什么js脚本更应该加到引擎内部。这个要提供的不不过代码的支持，这个是从生产到结果的一站式技术支持。  不能引导生产流程的引擎不能说是游戏引擎。不能成为生产线的游戏引擎不能说是游戏引擎。

       优化进行中。

。

。。。。

。

       最后再牢骚下，我敢打赌cocos2d-x的js脚本支持并非一个正确的选择，假设是吸引html的开发人员，我勉强认同cocos2d-html5，可是说实话，用html来开发网页游戏在几年内都不会是一个正确选择。而cocos2d-html5更像是给html开发人员的玩具，而且悲剧的是这个玩具还有些难，大多数html开发人员无法掌握这个玩具，仅仅能用它写写斗地主之类的小游戏。

有能力用它写出捕鱼达人的开发人员要么是顶尖的html开发人员，要么会像我一样更习惯用c++来写代码。

      正确的跨网页平台方向应该是像c3或者是unity3d一样，内部使用llvm把c++代码直接编译成flash或html5代码。这样现有的游戏仅仅要经过非常easy的移植就能够在网页上面跑了。像unity3d那样支持js固然不错，可是这个不是必须的。我假设用unity3d。我选择脚本语言会是c#而不会是js，相信非常多游戏开发人员都会做出这种选择。所以cocos2d-x费了那么大力气搞js。全然是走弯路了。

有这个时间还不如把公布做好，把c#支持加进来（不加也无所谓，lua也凑合。就比c#慢几倍而已）。假设cocos2d-x不能在mmo相关功能上提供很多其它的支持的话，那么它对我而言就是一个玩具，而不是一个强力武器。