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

引导类系统的可复用模型

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

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

任务系统族:

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

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

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

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

商店系统族:

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

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

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

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

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

明天接着讲:

战斗系统的模型构建思考

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

原文发布于微信公众号 - 韩大(handa1740168)

原文发表时间:2016-01-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

像Apache Storm一样简单的分布式图计算

介绍 计算可能很复杂。对我们来说,这种复杂主要就是软件世界的人类驱动力。甚至有一个学科整个都围绕着问题解决和计算——计算机科学。 当一个人开始学习计算机科学时,...

2056
来自专栏HansBug's Lab

【作业】HansBug的前三次OO作业分析与小结

OO课程目前已经进行了三次的作业,容我在本文中做一点微小的工作。 第一次作业 第一次作业由于难度不大,所以笔者程序实际上写的也比较随意一些。(点击就送指导书~)...

3076
来自专栏钱塘大数据

【干货】一篇文章读懂物联网具体架构,推荐收藏!

导读:本文将为你分析物联网的架构方法,全文分为两部分,第一部分从一个抽象的角度了解IoT的参考架构,将涵盖更具体与完整的架构中的各种定义,而第二篇文章将通过实际...

3086
来自专栏Java Edge

软件设计七大原则实战(二)-开闭原则1 开闭原则的定义2 开闭原则的庐山真面目3 实例

开闭原则是Java世界里最基础的设计原则,它指导我们如何建立一个稳定的、灵活的系统,先来看开闭原则的定义: Software entities like cl...

892
来自专栏技术分享

微服务架构—自动化测试全链路设计

从 SOA 架构到现在大行其道的微服务架构,系统越拆越小,整体架构的复杂度也是直线上升,我们一直老生常谈的微服务架构下的技术难点及解决方案也日渐成熟(包括典型的...

1080
来自专栏H2Cloud

领域驱动设计-软件中的对象

软件中的对象 About DOMAIN-DRIVEN DESIGN 领域驱动设计是一种思维方式,目的在于处理具有复杂问题的软件项目。在传统的瀑布软件开发模型中,...

3365
来自专栏企鹅号快讯

像Apache Storm一样简单的分布式图计算

作者:Kobi Hikri 翻译:无阻我飞扬 摘要:本文从计算机领域的“祖师爷”艾伦·图灵提出的图灵机概念开始,介绍了图形计算的概念,并以示例介绍了apache...

17110
来自专栏我的博客

面试和笔试汇总

最近忙着找工作,也没有更新博客,今天一个朋友让我赶紧把博客更新下,说说最近的面试情况也可以好给他们一个参考,这就整理出来给大家分享~~ 笔试题目公开 get和p...

3326
来自专栏AI科技评论

动态 | 码农福音!CASIL开发代码移植系统,CTRL+C/V快速编程不再是梦想

问:对于码农来说,有哪些可以提高开发效率的技巧? 答:Ctrl+C、Ctrl+V。 ? (图片来源:知乎) AI科技评论发现:近日,麻省理工学院计算机科学与人工...

3419
来自专栏云计算D1net

干货:如何计算用户行为大数据

用户行为类数据是最常见的大数据形式,比如电信的通话记录、网站的访问日志、应用商店的app下载记录、银行的账户信息、机顶盒的观看记录、股票的交易记录、保险业的...

3175

扫码关注云+社区