Cocos2d-x-3c 设计之路 CocosBase CocosNet CocosWidget

版本管理及下载列表

Download
CocosBase-2.2beta-3c.zip     http://pan.baidu.com/s/1kTfXoWJ
CocosBase-2.2.1beta-3c.zip   http://pan.baidu.com/s/1eQkRo3K    -- 修复了pushScene附带参数传递失败的BUG
CocosNet-2.2beta-3c.zip      http://pan.baidu.com/s/1i3p4NzB
CocosNet-2.2.1beta-3c.zip    http://pan.baidu.com/s/1bnmuyHh  -- 修复了组合收包时只处理1次的严重BUG
CocosWidget-2.2beta-3c.zip   http://pan.baidu.com/s/1bnBvGEb

Github
CocosBase   https://github.com/Jason-lee-c/CocosBase
CocosNet    https://github.com/Jason-lee-c/CocosNet
CocosWidget https://github.com/Jason-lee-c/CocosWidget

Google.code
CocosBase   https://code.google.com/p/cocosbase/
CocosNet    https://code.google.com/p/cocosnet/
CocosWidget https://code.google.com/p/cocoswidget/

Cocos2d-x-3c 设计之路

作者：李俊霖 [email protected]

QQ群：261286285 

此篇文章主要介绍以下几个框架 (Cocos2d-x-3c)
CocosBase   -- 场景管理及逻辑设计上的解决方案
CocosNet    -- TCP长连接解决方案
CocosWidget -- GUI系统的解决方案

Cocos2d-x

优点：高效稳定、易用(引擎本身)、开源、跨平台
缺点：缺少稳定及功能全面的工具链、上手难

出于对Cocos2d-x引擎的热爱，作者也需要来稍加点评，在优点上不想多做评论，正是因为它有着诸多优点才能让我们喜欢并使用它，以下主要来阐述一下作者个人对Cocos2d-x引擎缺点的看法与观点。作者属于爱较真的人，所阐述的缺点可能在各位读者眼中不能作为缺点而存在，确实Cocos2d-x其实算是一个比较完美的跨平台引擎了。由于3.0版本的发布，部分缺点已经得到了改善，那就先来说说3.0版本的问题。首先作者认为3.0版本定位不明确，通俗讲就是目标不明确，3.0版本在发布时明确表示出可以脱离cocos2d-iphone的老路，沿用新的技术 新的架构，不好的模块可以直接舍去或者重构，可是在3.0版本里却随处可见2.0版本的老设计，CCMenu体系，CCArray(被Vector所替换)，CCDictionary(被Map所替换)，2.0版本的触摸优先级等等，可否曾想过
作为一个新加入Cocos2d-x3.0阵营的开发者，在选择上如何定义？GUI体系包含CCMenu，CocosBuilder，CocosStudio，扩展库里的GUI组件，（不算作者开发的CocosWidget）这些该被开发者如何选择，如何使用呢？作者见过的已经不在少数的开发者选择组合使用CCMenu，CocosBuilder，CocosStudio，还有扩展库里的CCScrollView、CCTableView等，这样的做法是大错特错的，这些GUI系统从设计理论上来讲是完全不能被组合的。所以作者希望的是真正的重构与设计，而不是一味的兼容老版本。

跨平台环境和工程搭建基本属于要哭的节奏，如果不是作者利用业余的大量时间来研究Cocos2d-x，那么作者所在公司的项目进度还处在攀岩的速度，这也是为什么作者说它起步难的原因，虽然python模板解决了各个平台工程的生成问题，但是对于一个即将使用Cocos2d-x来开发游戏的公司和即将部署多平台项目的编程人员来讲，它们需要分别了解学习ios、android、win32 （暂时不考虑其他平台）的平台项目，其中属Android最为复杂，要部署一个Android可调试项目对于一个没有Android相关工作经验的人来说简直是噩梦。当然了，在开发跨平台项目的过程中了解这些是无可厚非的，但是我们是否可以想办法让这个过程变得更加傻瓜化，当需要了解具体内容时，再进一步跟进深入，这样会招来更多人的喜欢。

使设计更模块化（在3.0上稍有体现），使引擎本身更标准化，作者觉得引擎团队是否可以在对于引擎本身的设计上或者需求采纳上更为严谨，这点可以向c++标准委员会及标准库看齐这样可以使开发者置身于非常标准环境下去工作(这句话理解起来比较抽象，可以自行理解)。

读者拿到引擎首先就注意到的是，引擎是否能满足需求，那就取决于游戏本身的类型等等，那引擎到底能不能满足需求，作者只能这样答复，暂时还不能完全满足到此为止，每家公司或者每个游戏架构制定者会有不同的做法来实现满足自己的需求，我们可以称为“二次封装”，这种所谓的“二次封装”可能分为很多不同的形式，千变万化。有的基于Cocos2d-x的一个稳定版本开了一个单独的分支，从此维护自己的版本，有的则加入各种各样的逻辑架构、资源管理架构等等。作者只能感叹民间高手多啊。那么作者为引擎团队提供的建议还是"标准化"的概念，那么问题就很明显了，目前的标准化还不够