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

引导类系统的可复用模型

说到游戏中的“引导类系统”，最常见的就是所谓“新手引导”，这些专门设计的游戏流程，让玩家一步步的按规定顺序去操作游戏。而“任务系统”，也是最著名的引导类系统，这个最初只是基于NPC机关的小玩法，现在已经成为几乎所有游戏的标配。并且后续还出现了“每日奖励”，“日常任务”，“活动任务”，甚至“成就系统”等各种变种。这几个系统的核心逻辑，都是策划预设了一条“任务链”，让玩家通过操作，来改变自己在“任务链”上的位置。另外一种很特别的引导类系统，就是商店。最古老的游戏中都会有商店，到现在的游戏，商店系统的形态变得更加多样化，比如专门使用某种货币的兑换系统（使用人民币的商城系统）。拍卖行作为玩家的物品互动系统，实际上也是一种商店系统，只不过其价格和商品不是系统设置，而是玩家操作的而已。

虽然从产品角度来说，都是引导玩家进行某些行为，但是以上两类系统的核心逻辑是有所不同的，因此我打算分成两个部分来描述。

任务系统族：

任务系统的基础数据模型，是一个预设的任务库，存放着大量的任务链以及具体任务。而玩家则有一个任务列表，存放着已经完成的任务、接受后但未完成的任务。具体的任务最重要的是包含着任务完成条件和完成进度的数据，这些任务条件一般来说都是必须全部完成的。因此我们可以抽象出任务系统的基本数据模型：

“任务项”中的“接受条件容器”和“完成条件容器”中，都应该分别对应着两类对象，即“接受条件”和“完成条件”。“接受条件”可以有多个不同的子类型，如判断前置任务是否完成的，玩家是否符合等级，是否具备某个道具等等。而“完成条件/进度”也应该有多个子类型，如“对话操作”“杀怪操作”“物品收集操作”……游戏中一切的操作都应该可以成为完成条件，具体实现则由游戏的操作中，添加钩子处理程序，对玩家身上的完成条件的检索，然后根据游戏操作的逻辑，对这些玩家身上的“完成条件/进度”做修改。这些模型的方法应该有：

• 任务项
  • 用ID从持久化中load出来并构造
  • 各属性的getter/setter
  • 返回此玩家是否能接受
  • 更新并返回此任务的完成状态
• 玩家任务集
  • 根据玩家ID，从持久化设备中save/load出玩家任务集
  • 接受任务
  • 放弃任务
  • 输入一个“完成条件”的类型，返回所有符合此类型的“完成条件和进度”对象
• 接受条件
  • 输入玩家对象，返回是否满足此条条件
• 完成条件和进度
  • 返回已完成进度
  • 返回总进度
  • 修改已完成进度

由于任务系统的变种种类繁多，所以可能会导致设计大量的“接受条件”和“完成条件进度”类型，所以这些对象的部分属性如“描述文字”等静态内容，应该采用共享数据的形式出现，而不应该反复拷贝。下图初步描述了任务系统族类型的关系：

商店系统族：

商店系统的数据核心模型，是一系列可供展示、销售的商品，用于购买商品的货币，以及为这些商品提供展示之地的商店模型。当然这里的商品可能不一定对应于RPG系统里面的物品道具，因为有些商品是权限、等级等不能放入背包里的东西，也有可能是某种属性、状态等等。但是我们还是推荐用RPG系统中的道具来承载，这样编程的复杂度会比较低。

商店系统看起来非常简单，但是最复杂的地方在于“购买”环节，因为购买得到的商品，不一定是放入背包的货品，所以商品的“被购买”应该是一个可扩展的虚方法函数。这样商品也可以扩展为背包货品类商品和其他商品类。需要注意的是，买入玩家销售的物品，这个功能并不是非常容易重用，这涉及到如何对玩家物品的估价的问题，因此这个能力应该从最基本的“商店”系统扩展，而不应该加入商店系统中。商品系统的对象方法应该有：

• 商品
  • 属性的getter/setter
  • 以id从持久化设备中构造
  • 被购买行为（虚方法）
• 商店
  • 列出商品，可能带分页接口
  • 卖出商品

商店系统的表现形式非常多样，但是核心逻辑关系却异常简单：

至此，已经描述完主要的引导类系统的设计。这些设计本身可能并不能完成非常复杂的游戏逻辑，但是其基础逻辑却足够简洁。这样基于其开发的上层代码，就具备了一个比较统一的实现结果，便于构造出更多能重用或修改使用的系统。

明天接着讲：

战斗系统的模型构建思考

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