当前位置:首页 > 开发 > 移动开发 > 正文

基于cocos2d-x的游戏客户端优化

发表于: 2015-10-21   作者:互联网   来源:转载   浏览次数:
摘要:   cocos2d-x并不是一个适合网游客户端(mmo)的游戏引擎,越是大型游戏,这个小引擎就越无法驾驭(虽然它非常受欢迎)。 之前我在原来的公司使用的是自主研发的C3引擎,已经对外开放(尚未开源),后面如果我有提到c3引擎,那么指的就是这个2.5d游戏引擎。          我想起我上个月刚离职的时候,

  cocos2d-x并不是一个适合网游客户端(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的提示,但是依然不够方便,因为这些弹出框都很卡很慢。接触过mmo客户端开发的应该都有体会资源不存在是经常发生的事情,尤其是大家一起开发功能的时候,资源总是最后才正确且完整。  这个时候记录个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思路非常简单,生成字形的时候一个文字一个文字的进行生成,把生成的字形保存到一个512*512的纹理上,然后渲染的时候取这个生成好的字形进行绘制。 

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

 

       优化进行中。。。。。。。

       最后再牢骚下,我敢打赌cocos2d-x的js脚本支持并不是一个正确的选择,如果是吸引html的开发者,我勉强认同cocos2d-html5,但是说实话,用html来开发网页游戏在几年内都不会是一个正确选择。而cocos2d-html5更像是给html开发人员的玩具,并且悲剧的是这个玩具还有些难,大多数html开发者无法掌握这个玩具,只能用它写写斗地主之类的小游戏。有能力用它写出捕鱼达人的开发者要么是顶尖的html开发者,要么会像我一样更习惯用c++来写代码。

      正确的跨网页平台方向应该是像c3或者是unity3d一样,内部使用llvm把c++代码直接编译成flash或html5代码,这样现有的游戏只要经过非常简单的移植就可以在网页上面跑了。像unity3d那样支持js固然不错,但是这个不是必须的,我如果用unity3d,我选择脚本语言会是c#而不会是js,相信很多游戏开发者都会做出这样的选择。所以cocos2d-x费了那么大力气搞js,完全是走弯路了。有这个时间还不如把发布做好,把c#支持加进来(不加也无所谓,lua也凑合,就比c#慢几倍而已)。如果cocos2d-x不能在mmo相关功能上提供更多的支持的话,那么它对我而言就是一个玩具,而不是一个强力武器

基于cocos2d-x的游戏客户端优化

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

编辑推荐
基于cocos2d-x的快速的游戏开发–回合制游戏 开发时间:3天 开发工具:cocos2d-x和cocostudio 开发
本教程基于子龙山人翻译的cocos2d的IPHONE教程,用cocos2d-x for XNA引擎重写,加上我一些加工制作
本教程基于子龙山人翻译的cocos2d的IPHONE教程,用cocos2d-x for XNA引擎重写,加上我一些加工制作
移动互联网浪潮正在彻底改变人们日常的生活习惯和生活方式。相应的,基于移动终端和感应交互的游戏
本教程基于子龙山人翻译的cocos2d的IPHONE教程,用cocos2d-x for XNA引擎重写,加上我一些加工制作
[Cocos2d-x相关教程来源于红孩儿的游戏编程之路CSDN博客地址:http://blog.csdn.net/honghaier 红孩
作者:张子良 声明:版权所有,转载请注明出处 一、概述   基于任何平台实现的云盘系统,面临的首
作者:张子良 版权所有,转载请注明出处。 一、概述 首先明确概念,这里的小文件是指小于HDFS系统Bl
进入2013年,手机游戏市场持续升温,多款游戏收入节节攀升。据口袋巴士最新发布的《中国手机游戏四月
客户端很简单,就是开一个线程处理用户的数据发送和接收,并做出相应的界面处理。 由于其简单,我就
版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号