论可复用的游戏服务器端开发框架（二）

RPG系统的可复用模型

RPG系统主要负责提供游戏中提供“积累、成长”的快感，也是驱动玩家反复进行游戏操作的重要系统。RPG系统能提供这种作用的最基本逻辑，是以玩家为中心，为其赋予了一系列的可成长的数值，然后这些数值可以用在战斗系统或者RPG系统本身。

因此，RPG系统是由一系列子系统构成，而这些子系统，又由一个内在逻辑驱动，具备一些共性的行为和数据特征。我们使用面向对象的方法，可以比较清晰的分析出来其结构。我们从需求侧可以看到，RPG系统包含的子系统有：

• 角色属性系统：提供玩家的等级、攻击力、防御力、敏捷、智慧等一系列游戏需要的数值属性，以及一些特殊的非数值属性，如“黑暗魔法抗性”“防穿刺物理攻击”
• 技能天赋系统：技能和天赋本质上也是角色身上的属性，但是技能是有一定的等级的，而天赋除了等级，还可以提供玩家自行分配的操作。有些天赋的分配会直接赋予玩家新的技能。
• 武器装备系统：武器装备主要指角色身上那些有装备栏位限制，但是可随意修改装备状态的系统。武器本身可以携带大量数值，这些数值会由其他系统计算读取。同时装备本身也有可以修改的空间，比如打孔、改名、升级，可以说是一个小型的角色系统。
• 物品道具系统：物品道具的主要内容包含名字、数量、作用。这些道具有一些是可以消耗的，而另外一些则会作为永久性唯一道具存在于玩家身上。它和武器装备的差异在于，一般没有很复杂的附加数值，但是数量会很多，甚至成千上万，通常以“堆叠”的形式出现。

我们基于这些系统的共性，可以大概总结出一个基础共性的模型。

对于以上的数据模型，其行为方法也是比较明显的：

• 角色
  • 新建角色，返回ID
  • 根据ID从持久化或缓存中读取角色load
  • 把角色存储到持久化数据中save
  • 属性的get/put/list
  • 技能的get/put/list
  • 背包内容的put/get/list
  • 装备的arm/unarm/get_by_position
  • 装备栏的add/remove/list
• 属性
  • 根据ID构造
  • 对于各成员属性的getter/setter
• 技能
  • 根据ID构造
  • 对于各成员属性的getter/setter
• 物品
  • 根据ID+数量构造
  • 对于各成员属性的getter/setter
  • 使用（可能消耗）
• 装备
  • 根据ID构造
  • 对于各成员属性的getter/setter
  • 被装备armed触发的效果回调
  • 被脱下unarmed触发的效果回调

需要注意的是，这里的技能、属性、物品如果不带可修改的能力的话，可以采用单例以及享元的模式，这样可以大大减少对于内存的消耗，根据这些属性和方法，我们大概可以画出这样的类关系图：

对于以上设计，可能读者会问，这些系统完全没有考虑到游戏客户端和服务器通信的问题，也没有考虑登录在线的实现，仅仅是一些数据结构的列举，真的能用吗？为此，我就把相关的一些系统试着画一下类结构图。

这里的命令系统主要是负责网络通信的一套系统，把客户端的操作变成对“玩家对象”的方法函数的调用；而登录系统是一个负责玩家在线的缓存系统，可以让命令系统获得“玩家对象”；玩家对象则由负责通信的对象和负责数据的角色对象两者组合而成，玩家对象除了对数据的存取和读写外，还会使用通信的对象来完成诸如说话、战斗等操作。

像这种数据建模，从一开始看似乎并没什么特别的优势，但是如果你需要快速开发一个游戏的时候，你可以从一套模板代码开始扩展或者修改，会比完全从头开发要快的多。有一些通用的逻辑，比如背包大小检查，物品负重判断，天赋总数控制，都可以直接添加到这个中层MudLib的代码里面，这样就确确实实的减少了代码的编写。

社交类系统的可复用模型

在线游戏由于可以让不同的玩家在游戏中互动，所以产生了比单机游戏有趣的多的感觉。多人合作和竞争的操作，以及多种人际关系的玩法，都是现代游戏所热衷的设计，特别在国内的MMORPG中，对于玩家关系所依赖的玩法更加丰富，国战、结婚、帮派等等都是很常见的社交类系统。社交类系统包含我们常见的好友系统、公会系统、组队系统、聊天系统、邮件系统等等。而这些丰富的系统，其背后也由两个核心的逻辑系统组成：玩家关系；玩家间交互。常见的系统有：

• 聊天系统：一般有玩家间私聊、多频道聊天等功能，为在线沟通的主要系统。聊天内容除了文字外，还有表情图，角色、物品链接等功能。
• 邮件系统：则是离线沟通的主要系统，还承担着游戏内物品道具的寄送功能。很多任务、活动、交易系统都是用邮件系统来发物品给玩家。
• 公会系统：属于需要玩家主动建立的玩家组织，公会主要的功能是对玩家进行分组管理，并会根据玩家组织的数据，添加更多的附属功能。家族、帮派是公会系统的不同名称。公会系统除了展示成员，设置成员等级等等界面功能外，往往还附带公会基地、仓库，成员升级机制等等。这些理论上不属于社交类核心范畴，而属于扩展功能。这些功能的开发工作量也比较大，也许这一块的代码难以抽象到中层中去，但是如果中层可以服用，则部分高层倒是可以通过修改代码来重用的。
• 好友系统：每个玩家都有一个好友关系的列表。另外有的游戏还扩展出固定名称和人数的特异好友系统，如结拜系统、师徒系统、夫妻系统等。

交互系统和玩家关系是整个中层系统的核心，他们具备的数据关系可以大概如下记录：

以上类型的成员方法：

• 交互消息
  • 内容的getter/setter
  • 发送方/接收方的getter/setter
• 交互系统
  • 发送一条消息
  • 收取一条消息
  • 设置收取回调通知
• 玩家关系
  • 加入一个角色
  • 列出所有角色
  • 删除一个角色
  • 新建关系列表，返回ID
  • 根据ID从持久化或缓存中读取角色load
  • 把角色存储到持久化数据中save

在实现社交类系统的时候，最常见的难题是对于社交系统对象的单例操作。由于游戏服务器可能是多进程多物理机器的。要实现跨机器投递交互消息，是需要额外的处理能力的。有一些实现者会采用ActiveMQ之类的消息队列服务来承载，有些则使用数据库存储做交换。但是增加额外的服务会增加整体的运维和开发的复杂度，因此GameOS（底层）提供的跨机器数据缓存就是必不可少的部分。基于这个基础功能，实现消息队列或在线消息投递都会非常的简单。

明天接着讲：

引导类系统的可复用模型

感谢大家的阅读，如觉得此文对你有那么一丁点的作用，麻烦动动手指转发或分享至朋友圈。如有不同意见，欢迎后台留言探讨。