【游戏性基础系统】
游戏性基础系统（gameplay foundation system）：
1）运行时游戏对象模型（runtime game object model）
2）关卡管理及串流（level management and streaming）
3）更新实时对象模型（real-time object model updating）
4）消息及事件处理（messaging and event handling）
5）脚本 （scripting）
6）目标及游戏流程管理（objectives and game flow management）
其中1）运行时对象模型是最复杂的，通常它需要提供以下功能：
1）动态地产生（spawn）及消灭（destroy）游戏对象。
2）联系底层引擎系统
3）实时模拟对象行为
4）定义新游戏对象类型
5）唯一的对象标识符（unique object id）
6）游戏对象查询（query）：根据ID查找对象，或是根据任意条件做高级查找，如寻找玩家20m以内的所有敌人
7）游戏对象引用（reference）
8）有限状态机（finite state machine, FSM）
9）网络复制（network replication）
10）存档及载入游戏、对象持久性（object persistence）
【运行时对象模型架构】
游戏对象模型的2种架构：
1）以对象为中心（object-centric）：每个对象含一组属性及行为，这些都会封装在那些对象实例的类之中。游戏世界只不过是游戏对象的集合。容易产生单一庞大的类层次结构（monolithic class hierarchy）。一个类越是在类层次结构中越深的地方，就越难以理解、维护及修改。因为要理解一个类，就需要理解其所有父类。
此方式最大的问题是，当设计层次选择了某个标准，就很难甚至不可能用另一个完全不同的标准分类。比如按物种分类的生物，要按颜色分类就不好办。mix-in类可以改善改方式。一个类可以派生自主要继承层次结构中的一个且仅一个类，但也可以继承任意数量的mix-in类（无基类的独立类）。通常更好的做法是合成（composition）或聚合（aggregation），而不是继承他们。
把Window派生自Rectangle类。然而，一个视窗并不是一个长方形，它只拥有一具长方形，用于定义其边界。因此，这个设计问题的更好解决方法是把Rectangle的实例安置于Window类之中，或是令Window拥有一个Rectangle的指针或参考。面向对象设计中，“有一个”的关系称为合成（composition），合成的对象与主对象有同样的生命周期。对于主对象与子对象生命周期不同步的设计，称为聚合（aggregation）。
要降低游戏类层次结构的宽度、深度、复杂度，一个十分有用的方法是把“是一个”关系改为“有一个”关系。业界成熟的方式是使用组件模式:
1）“枢纽”HUB组件模式
2）通用组件模式
3）纯组件模式
2）以属性中心（property-centric）：每个游戏对象仅以唯一标识符表示。我们先定义游戏对象可能含有的属性集合，然后为每个属性建表。此设计更能有效地使用内存，因为我们只需存储实际上用到的属性。SoA(struct of array)的性能优于AoS(array of struct)
【世界组块的数据格式】
原文：http://www.cnblogs.com/tekkaman/p/3649018.html