Cocos Creator 的组件式编程 以及分工策略 一分钟上手流程

与初学c语言编程时用的“线性”编程不同，Cocos Creator（简称CCC）采用流行的组件式编程模式，一方面摒弃了OO（面向对象）里关于继承、多态这些抽象的概念，另一方面引进类似并发机制的组件化思维，像搭积木一样形象。Unity和UE4（虚幻4）都采用了这种编程模式，因此通过学习CCC来提高学习编程的兴趣，进而也为学习更高级的游戏引擎（Unity和UE4）熟悉环境。

下面我们自顶而下，讲述一个游戏的开发思路。参考实例请看上一篇博客《初学者使用Cocos Creator制作第一个小游戏以及脚本编辑器的选择》http://blog.csdn.net/stillwater123/article/details/79186404

技术总监

一个完整的游戏由多个场景构成，技术总监负责从游戏策划那里划出分这些场景，以及场景的跳转（cc.director.loadScene('xxx');）逻辑。还要协调各场景负责人和美工等的进度安排。

场景

一个场景一般只由一个人负责，这是由于CCC的场景文件是一个“不便分割”、“不便分工”的组织结构，两个人一先一后开发是可以，但倘若另个分支同时开发，没有便捷方式来合并。

场景划分的原则：
1、技术上：场景切换后一般要从内存中释放场景中所有内容，再次切入时需要重新载入这些内容，所以要适当划分，防止游戏在不适当的时候卡顿。
2、内容上：一般一幅新的（背景）画面或者主题可以作为一个新的场景。

通常，游戏开始和游戏结束的画面是单独的场景；一个关卡是一个场景，如果关卡过长，也可划开成多个场景进行衔接。

一个场景通常需要一个管理整体流程的主流程脚本（比如Game.js），挂载在一个生命期横亘全程的游戏对象上面（比如Canvas）。

层级管理器

负责管理游戏对象（包括预设体）的父子（结点）关系、渲染顺序等。

对象的“缩进”代表了父子结点关系（Cocos引擎规定所有游戏对象都是挂载在它的父结点上的，场景也是一个结点，是所有对象的祖先结点），子结点的Position，Rotation，Scale等属性都是相对于它的父节点的相对值；并且作为父节点的一部分随着父节点的变换而变换（包括移动、选择、缩放等）。

对象在（缩进的）同层中的先后顺序代表了它们的渲染顺序，越靠下的越晚渲染，因此靠下的对象会覆盖在靠上的对象上面，即靠上的对象可能会被遮挡一部分甚至全部遮挡。父子关系的对象，子对象会覆盖在父对象上面，因此也符合“越靠下的越晚渲染”原则。

游戏对象

游戏对象（包括预设体）一般需要在它的属性检查器里挂载一个贴图，或者一个动画，由游戏美工负责绘制。有的还需要挂载物理属性、特效等。

游戏对象有的需要挂载js脚本，在脚本中定义自己的一些属性（事实上，一个脚本是一个（继承自cc.Component的）类，这些属性是它的类公有成员）。

游戏对象之间互相访问、修改属性的方式（比如A对象要访问（或修改）B对象的某个属性）：
Step1：在A的属性里定义对象B，然后在CCC的层级管理器里把B拖拽到A的属性检查器里的对应脚本的对应属性框上面；或者在A脚本的onLoad()里用cc.find()赋值给一个变量，这时这个变量不必在A的属性里定义，比如

// Game.js
    this.player = cc.find('Player', this.node);

这样便得到B的对象引用，再用B.getComponent('脚本').属性得到该属性的引用，比如

// Game.js
    this.player.getComponent('Player').jumpHeight

多个游戏对象（包括预设体）可以由多人分工负责，一个游戏对象可能会有一到多个js脚本（组件）来控制。

属性检查器

一个对象如果有多个脚本，它们的执行顺序（包括onLoad，start，update等）与其在属性检查器里的前后顺序一致（http://blog.csdn.net/alpha_xiao/article/details/52102231）。

注意：

为了便于游戏流程的可读性和统一管理，建议技术总监和场景负责人合理划分主流程脚本与游戏对象脚本的功能范围。