[居安思危]从cocos2d(x)到unity看游戏研发、设计中一些要点

ldhhp

可以发表自己的看法，但请不要误导民众，为unity当枪手。
1：“物是人非，cocos2dx的用户已经大幅度减少，无数人转投了unity的怀抱",说明一下数据来源。
2：有讲到unity的软肋吗？
3：你真的了解cocos2d吗？
4：复用有多大价值呢？

ArmyShen

作者用过cocos2d-x吗？做UI不方便，笑了...

Yuki001

比较2种解决方案的优劣，最好是放在具体的项目（问题）背景中，做什么项目，人员知识结构如何，都会很大影响解决方案的选择。cocos2d-x较为适合2D以及效率优先，自定义比较多的项目中。由于用cpp写，所以程序需要有cpp的背景。unity3D比较适合简单3D项目，容易开发简单原型，但效率和自定义方面，工程管理与控制方面不足。在大型项目中往往被引擎本身束缚。
另外component 系统，是oop中的组合抽象化，只是oop中间的一种形式而已，被oop范式包含，和oop非对立。另外component系统只是在领域模型层才有作用，代替领域模型中实体的复杂的继承树而已。
另外我也想喷cocos2d-x，仔细看了下那代码，写的混乱不堪。注释中式英文看的都想吐了。要不是中国人写的支持方面好些，我真不建议用这个引擎底层。猴子他们用的Haxe+NME其实是一种比较好的方案，其他国外替代的引擎也有不少。

243884919

这篇文章我觉得说的有失偏颇。unity3d在跨平台的技术方案比cocos2d-x做的更易于使用，但cocos2d-x只是用起来不那么方便，需要换个平台再编译和一些小的细节。如果是发双平台，团队里有android上开发有经验的同学是有必要的。unity3d的第三方工具插件确实比cocos2d-x多，但是工具插件够用就用行，有的工具确实也需要自己开发。比如做个可视化的关卡编辑器，unity3d也没有呀，只能是自己再做插件。

猴与花果山

Yuki001 发表于 2013-8-20 13:38
比较2种解决方案的优劣，最好是放在具体的项目（问题）背景中，做什么项目，人员知识结构如何，都会很大影 ...

大多我表示非常同意，但是有2点我要指出：
1，unity的好处真的不是在3d这么简单的，这个要说得一大篇论文了。我觉得从你的回帖水平来看，应该是我不用多解释你也知道我要说啥的，不过我倒是真不乐意用unity就对了。
2，component和oop真是对立的，如果你被oop思路束缚了也可以说他们很相似，但是我觉得这个更像是“拿了一把锤子，看什么都是钉子”的思路。其实要用好component这种模式，真得忘记光所有oop的概念，这是程序员很难转换的原因，因为大多时候思路被oop固化了。从oop到component这个变化就像学习太极剑——“无忌，太师傅教你的掌握了多少了？”“太师傅，我全忘记了”。
其实我们用了entity system后，很多程序员发生了要么跟不上不愿意学了（关键是这玩意儿不流行），要么就很快能掌握，跨度很大，关键在于扭转思路的节奏。

独孤逍遥

表示听不懂，压力真大。

tgame

楼主没用过unity，就在说unity的优点，真可笑。

funcman

能在自己完全不懂的情况下写出大段的内容，在下实在是佩服，佩服~

Yuki001

又仔细看了下文章和回复，我发现大部分的回复（包括我自己的）其实都没抓住猴子的要点，其实帖子的重点是游戏设计，cocos2d-x和unity 只是用来做例子引申的，结果因为举的例子牵涉到了cocos2d的支持者，所以貌似后面不少喷的其实没理解帖子的内容。实际上帖子说到的设计问题相当不错，不仅仅在游戏上面有用，在各种产品（包括游戏引擎）方面都是很有意义的。

哦，另外关于component系统，很多程序员不适应是因为component系统不仅仅牵涉到了领域模型建模（对象数据与行为设计，以及对象关系设计），还牵涉到对象内部的逻辑拆分，这部分工作不少人没经验。其实简单来说工作多了一步，就是对对象进行打标签，在设计好对象以后，给对象几个正交的标签来分解逻辑。例如一个游戏中间的角色，可以被打上："有生命值的"，“可攻击的”，“可释放技能的”，“可附加buff的”等等，然后对每个角色的标签进行汇总，得到的就是组件集合。(HPComponent，AttackerComponent，"SkillComponent","BuffCompnent"...)，然后按标签组合就变成了一个具体的对象。这种component因为逻辑纵向拆分，所以内聚性比较强，很容易复用和组合。例如我有一个障碍物，如果需求变更说这个障碍物可破坏有血量，那直接可以加入一个HPComponent，这部分血量控制的逻辑就可以复用了。
说Component系统是被oop包含的原因是：1.compoent 本身最后还是要被entity组合成为具体的领域对象，有对象的存在就是oop的一个特征。2.component的实现其实是oop中的组合的运用。

猴与花果山

Yuki001 发表于 2013-8-21 19:06
又仔细看了下文章和回复，我发现大部分的回复（包括我自己的）其实都没抓住猴子的要点，其实帖子的重点是游 ...

嗯，你这个障碍物的举例非常到位了，这的确是component的特色，所以其实啥概念的称呼之类就不纠结了，说的都是一件事情了。
我个人认为这将是未来游戏开发的走势，这也是为什么我说策划应该去写逻辑代码的主要原因吧，毕竟你说的“纵向拆分”真的只有策划可以，至少目前来看是这样，程序员很多实在没法去做，因为不太容易了解详细的需求，但是游戏设计确实有事这么个“奇特”的玩意儿。
但是眼下entity也好、unity也好、cocos2dx也好，本质上在动画的管理上存在着很多不太愉快的点，要具体举例挺难说，这是我们眼下着手正在解决的麻烦，需要经过好几个项目的历练之后才能说个大概了，我想这种不爽你应该也能大概理解的吧。
不过的确，本篇我本就没讨论cocos2d和unity谁更好，因为这种讨论没有意义，自己用的无论如何都会说很好这是人之常情，我只是希望借这个分析来理性的看看游戏设计的时候的一些很容易就被忘记了的点是真的……