游戏对象系统的设计（一）

        作者：dlite@163.com

        为实现完全的数据驱动逻辑，我们的设计中，游戏中的对象都被抽象为实体，实体包括属性和方法。这样设计的另外一个好处是，在集群中，我们可以以统一的方式处理对象状态的变化，也就是实体属性的变化。这篇文章主要描述实体和属性的基本特性，后续文章还会记录其他相关设计。

类型和实例

        类似于OOP中类和对象的关系。每个实例都有一个指向类型的引用，类型信息还用于存放属性的缺省值。

实体的属性特征

        A、一般可见性

        为避免不必要的数据传递和复制，每种属性都会标记出其可见性。可定义成下面几种按位或的组合。

        客户端可见：如玩家服饰的材质属性。

                服务器端可见

                其他玩家可见

        其他实体可见

        例如，只在客户端可见的属性发生变化时，没必要传输到服务器端。

        B、基于LOD的可见性

        用于描述有位置信息的实体的属性可见性。为节约存储空间，可以预定义下述集中距离常量。

                无限

                很近

                稍近

                中

                稍远

                很远

        实际实现时，这些常量可配置为具体的距离值。如，“稍远”表示区间：[50米, 100米)；“很近”表示区间：[0, 10米)。

        C、持久性

        主要考虑数据的持久性存储要求。游戏中一些数据是需要持久化存储的，一些是不需要持久化存储的。对于需要持久化存储的数据来说，有些要求确保写入成功，有些可以容忍短期的丢失。另一方面，为保持游戏的流畅性，对于实体属性的变化，我们不可能把每个属性的变化都及时反映到持久性存储中（例如保存到基于磁盘的数据库中）。因此，我们定义了下述3中持久化级别：

        临时的

        异步写入：回写（write back）

        写入同步：直写（write through）

        持久化级别，在集群中的节点间进行数据复制和故障切换的时候，也会用到。

实体间的关系

        实体可以嵌套包含。例如，背包是玩家角色的子实体。这样就涉及到子实体生命周期的管理。为实现对象生命周期的自动化管理，传统的方式会定义两种关系，一种是拥有关系，另一种是共享关系。例如，玩家角色和背包间的关系就是拥有关系；玩家角色和组队间的关系就是共享关系。在一些支持垃圾回收的语言中，例如 Java，这两种关系往往都被抽象成引用关系。

        但用一种引用抽象对象间的关系，也会带来问题。考虑使用引用机制的游戏处理好友关系的情况：假设玩家A是玩家B的好友，也就是玩家B引用了玩家A，如果后来玩家A注销了帐号，但没有显示通知B，那么玩家B还持有对玩家A的引用，单纯的依赖引用的垃圾回收机制就不能奏效。此时必须引入被引用对象的有效性判断机制，如果被引用对象无效，则自动删除对其引用。由此，我们可以引入强引用和弱引用两种关系，类似于Unix系统的硬链接和软链接。没有被强引用的实体，才可以被垃圾回收。玩家间的引用关系是弱引用关系，玩家角色和背包间的关系是强引用关系。