cocos2d-x 数据驱动的游戏开发

～～～～我的生活，我的点点滴滴！！

里面内容是转自秦大牛的文章，看了好多次都没有完全理解其中精髓，也没有灵活运用于项目中，惭愧～～，记于此，方便每日观看～～～

在2002年的GDC大会上，Scott Bilas做了一个题目叫做《A Data-Driven Game Object System》的演讲，他在自己的博客上说怀疑自己是第一个提出这个概念的人，但肯定是第一个对公众解说这个概念的人。

这个概念引起了游戏圈内广泛的讨论，至今已形成比较完整的理论，维基百科上称作Entity-component-system(ECS)，或者更简便的称作Entity System。到今天，著名的游戏引擎Unity甚至完全基于ECS来构建。

然而国内社区似乎很少讨论ECS，我们常使用的Cocos2d游戏引擎默认也不支持（最近的2.1.4版本加入了简单支持，后面分析）ECS。本文将详细探讨ECS的工作原理，优点及不足，以及它和游戏引擎的关系，还会简单分析Unity中ECS实现的方法，最后提供一个基于Cocos2d-x实现ECS的完整的源代码实例。

面向对象在游戏设计中遇到的问题

ECS的出现起源于面向对象的架构风格在游戏设计中遇到了一些问题。在现代软件设计中，通常使用面向对象的思想来抽象各种实体，数据模型，业务逻辑，它工作的很好，我们用易于理解的名词例如Car，People等类来描述软件中的各种概念，通过继承，多态来表述同类事物的不同特征和不同行为，如下图：

图1. 《Ghost in the Sea》中部分类结构

然而这样的设计方式在游戏开发中却遇到了困难，例如在上面结构图中，船是不同于英雄的类，但是其实船也是可以产生资源的，它是否应该继承于“资源”类呢？如果他们是相互独立的，意味着有部分重复代码；其次，如果设计需求中新加入一种敌人，它可以“远程”攻击轮船，用什么攻击呢，我们给它配一把“枪”，我们有一些解决方法：

• 使用C++中的多继承，让新加的敌人同时继承于“枪”和“远程”。
• 从“远程”继承，复制“枪”的代码。
• 为了清晰表达一个新的类型，干脆新建一个类，复制两个类中的代码。
• 把代码移至父类中，不同的子类执行不同的方法。

我们看到，不管使用哪一种方法，都需要对程序进行不同程度的修改，修改的原因是为了代码重用，修改的结果却使得类的职责不再清晰。这就是面向对象在处理交叉关系时遇到的问题，这不仅涉及到每次变更都要重构类的结构，更加重了理解和处理这些关系的负担。并且这会占据很多时间：在项目开始的时候，绞尽脑汁把简单的数据库转化为面向对象世界复杂的关系，在每次需求变更的时候重构这种关系。

而在整个游戏开发过程中这样的变更非常频繁。每一次变更可能会影响到很多地方，对游戏的稳定性也是非常不利的。而应对这种频繁复杂的需求变更正是基于组件的架构最擅长的。

基于组件的架构风格

基于组件的架构设计风格核心思想是组合优于继承（prefer composition over inheritance）,即是通过将各个相对独立的数据和逻辑组织成一个组件（而不是通过继承）来实现代码重用。这样我们可以通过不同的组件组合形成不同特征的对象，这样形成一个扁平而不是树形的结构，如下图：

图2 基于组件的扁平的架构设计风格

从上图可以看到，一个GameObject本身包含很少的信息，它仅仅是由一些组件组成，这些组件的组合决定一个特定GameObject的特征和行为。这样就可以应对不同的需求同时保持比较稳固的架构。如果新的需求加入一种新的数据和行为，我们就定义一个新的组件，如果新的需求具有不同的行为组合，我们就为这类对象添加不同的组件组合即可，这对已有程序不会有什么影响。

基于组件的设计还使我们将精力集中在逻辑及数据本身，而不是绞尽脑汁去抽象各种类层次结构，继承关系。软件设计关心的是数据和行为，面向对象是为了重用代码，简化设计的一种方法，它不是程序设计的规则和原则，它也有它的局限性。因此我们可以说基于组件的设计风格和面向对象的设计风格是两种比较独立的方法，读者有必要区分这两个概念。