个人关于Cocos2d-x的一些看法及其发展展望。

总体来说,cocos2d-x是一个优秀的库。

Cocos2d-x没有很复杂的一个架构,基本上是一些以单件形式提供的管理器和是一些围绕SceneGraph(CCNode及其派生类)展开的类。这个设计使得cocos2d在结构上很简洁,使用者很容易上手。

同时cocos2d的设计者充分利用了现成的一些游戏开发中的工具,将这些工具整合到引擎中来,例如BMFont、TexturePacker等工具,使得制作素材很方便。

作为一个跨平台的游戏库,cocos2d-x已经做的非常好。 但如果将cocos2d-x定位为一款跨平台的游戏引擎,我觉得Cocos2d-想可以朝以下几个地方发展:

1、cocos2d-x可以提供一个好的游戏框架:
cocos2d-x提供的一些Demo,以及教人写程序的方法基本是让开发人员编写一个CCScene的子类,通过子类化的方式来实现具体的逻辑,作为教学这样非常好。
作为正式开发,个人建议cocos2d-x可以提供一个具体的游戏框架,这个框架在总体上提供了一个移动平台的游戏的通用功能(例如:LoadingScene, TitleScene, HighscoreScene等等),游戏开发人员要做的只是根据自己游戏的情况来选择定制自己的游戏。

2、cocos2d-x对游戏逻辑的支持可以增强:
对开发这来说,怎么编写游戏逻辑是一个麻烦的问题,Cocos2d-x用SceneGraph的方式来管理场景,很自然地,游戏开发人员肯定希望使用cocos2d-x提供的方式来管理对象,这样就要从CCNode等对象派生,甚至有的开发人员还建议直接从CCSprite等万能类派生类编写功能代码。这样做的方式并非不可以,但作为一个好的开发人员,你以后会发现这样带来的问题非常多,例如:游戏复杂了之后,你会发现继承关系层次很多,导致代码需要不停重构来适合新的需求,最后你设计的基类越来越复杂等等。

现在比较主流的方式是使用Entity-Component系统来组合出我们的逻辑。关于Entity-Component系统这里就不再细说。仅仅简单说明一下:游戏中的对象为一个Entity,每个Entity使用由一个或多个Component构成。
例如游戏中的雷电游戏中的一架飞机可以由:Flyable(可飞行Component,提供飞行功能)、Shotable(可发射Component,提供发射子弹的功能)、Sprite(Sprite Component,提供显示功能)、Colliable(碰撞Component,提供碰撞检测的功能)构成。

当然仅仅有Entity-Component系统,对于游戏框架来说还是不够的。例如:当子弹击中飞机的时候,是直接调用函数吗?直接调用当然不好。首先子弹和飞机都是Entity,在外部来看,你不知道他们由什么Component组成,直接查询Component并调用Component的函数,这明显就违背了封装的原则。如果提供了消息系统Event System,通过给Entity发送消息,Entity中的组件收到消息后,由组建去处理自己关心的消息,这样不仅实现功能,而且结构有漂亮。

3、cocos2d-x对游戏开发工具的支持:
对于游戏开发引擎来说,优秀的工具永远是第一位的。有了工具,游戏开发者就可以很快的时间做出原型,然后在这个基础上,通过快速迭代优化数值和表现来快速开发游戏。

以Cocosbuilder这样一款工具来说吧,目前阶段cocos2d-x要做一款这样的功能的工具,还需要改善一下代码。最基本的就是提供持久化(Persistence)的支持。可以任何时刻将游戏的内容或者编辑器中制作的内容保存到磁盘文件。以后需要的时候可以打开保存的文件。
要实现这些,我觉得有几点基础需要增加:
1、提供RTTI的支持;
可以让一个对象在运行是判断是否是某类对象(PS:别告诉我用dynamic_cast来实现。),具体实现可以参考很多现成的方案;

2、提供类工厂的支持;
可以根据文件中的保存的类名等来构造出相应的类,例如:读到"CCNode"的时候,可以根据"CCNode"来创建出CCNode对象;

3、提供对象属性的设置;
当读取到一个属性名称和数值的时候,提供一个方式来设置对象的属性。例如读取到:Position的时候,提供一个方式来设置node->setPosition(xxx)。

以上这些是个人的一点设想,希望大家也提出自己的意见。

这些建议都非常好,这些功能相信在不久的将来肯定会出现滴

希望早点实现,很看好cocos2D:lol

多谢楼主中肯的建议。

目前entity-component的呼声最高,我也和Ricardo Quesada讨论过此事,但他主导的cocos2d-iphone似乎没有很强的意愿来实现这个功能,认为这个结构会加大引擎运行时的开销。cocos2d现阶段的重点仍然是More Data, Less Code路线以及javascript binding

开发工具方面,CocosBuilder的作者vik已经被Zynga收去旧金山,目前是全职地改进CocosBuilder,cocos2d-x也已经添加了对ccb格式的支持,我们打算在2.0里面添加这块,因为CocosBuilder v1.1之后就只支持cocos2d-iphone 2.0以上了。

关于marshalling, Ricardo为了照顾cocos2d-x而没有用NSCoder,而是用了一个俄罗斯人的方案。这块地方我还没仔细看,原理上也是序列化为xml文件。

”这个结构会加大引擎运行时的开销“,游戏基于引擎,引擎有完备的框架,游戏效率不会低的。因为按照ccnode体系来编写代码,这些代码经常无意识的造成紧耦合,对于简单Demo写起来快,缺点不突出,对于复杂游戏就是在挖坑,缺点放大。通常程序员是要成长的,写一段时间胶水代码,必然向往高级工具,高级工具通常依赖健壮的框架设计,框架其实也是引擎。

More Data, Less Code => Data driven

同意lz的看法。

超级版主现身了…

跨平台和容易上手两个特点就足够吸引人了,只要不断完善肯定会有越来越多的人使用

其实主要就是组合方式和继承方式的区别,各有利弊。cocos2d发展为组合方式只是时间问题。

主要是庞大继承树会提高复杂度,让人不易掌握。
目前cocos2d-x的继承树还是比较简单的。

我觉得最优先的功能应该是 batch group node。

当 sprite 数量一多,使用 CCSpriteBatchNode 就是优化的必然选择。但是 CCSpriteBatchNode 有一些限制。

例如一个角色由几个部件组成,每个部件是一个 sprite,整个角色则是一个 node。把这个 node 加入 batch node 是不行的,即便这些组成角色的 sprite 和 batch node 是同一个 texture。

理想情况应该是用 CCNode 保持对象层次结构,渲染则交给 CCSpriteBatchNode 负责。

对于游戏框架,我觉得即便要做也不应该放入 cocos2d-x 里。可以做成一个基于 cocos2d-x 的 game framework。

赞同你的想法, 做一个单独的框架,仅仅依赖cocos2d-x,在cocos2d-x之上的一层。

谁想实现Entity-Com…谁就去实现啊,作为扩展包的方式放出来就好了,不要污染cocos2d本身的纯洁性嘛{:soso_e113:}

html5的好写不

:(不太明白。。。

好贴 顶了

— Begin quote from ____

walzer 发表于 2012-4-18 16:31 url

多谢楼主中肯的建议。

目前entity-component的呼声最高,我也和Ricardo Quesada讨论过此事,但他主导的coc …

— End quote

既然定位了C++,就不要整太多的订制。
entity-component之类的东西,放到demo里足够了,就像楼主提到的各种游戏屏。
引擎本身应该专注于跨平台和灵活性,走脚本语言路线是不是太舍本求末了?

  • 本帖最后由 newman2088 于 2013-2-18 10:37 编辑 *

— Begin quote from ____

dualface 发表于 2012-4-19 22:49 url

对于游戏框架,我觉得即便要做也不应该放入 cocos2d-x 里。可以做成一个基于 cocos2d-x 的 game framework …

— End quote

这个是正解。另外,我觉得cocos2d-x应该尽量保持和cocos2d-iphone一致,单加的功能尽量以扩展包的形式提供。我是初学cocos2d-x,以前对cocos2d有一些了解,呵呵。

“作为正式开发,个人建议cocos2d-x可以提供一个具体的游戏框架,这个框架在总体上提供了一个移动平台的游戏的通用功能(例如:LoadingScene, TitleScene, HighscoreScene等等),游戏开发人员要做的只是根据自己游戏的情况来选择定制自己的游戏” 对这段相当同意。另,实现Event机制,动态类型识别都是很能排得上用场的,但用C++实现会导致效率的降低,好在现在硬件都够强悍,效率问题可以退而求其次。

邪恶的顶一下 哈哈