作者: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系统的硬链接和软链接。没有被强引用的实体,才可以被垃圾回收。玩家间的引用关系是弱引用关系,玩家角色和背包间的关系是强引用关系。
游戏对象系统的设计(一)
最新推荐文章于 2023-08-17 09:43:20 发布