说到游戏中的“引导类系统”,最常见的就是所谓“新手引导”,这些专门设计的游戏流程,让玩家一步步的按规定顺序去操作游戏。而“任务系统”,也是最著名的引导类系统,这个最初只是基于NPC机关的小玩法,现在已经成为几乎所有游戏的标配。并且后续还出现了“每日奖励”,“日常任务”,“活动任务”,甚至“成就系统”等各种变种。这几个系统的核心逻辑,都是策划预设了一条“任务链”,让玩家通过操作,来改变自己在“任务链”上的位置。另外一种很特别的引导类系统,就是商店。最古老的游戏中都会有商店,到现在的游戏,商店系统的形态变得更加多样化,比如专门使用某种货币的兑换系统(使用人民币的商城系统)。拍卖行作为玩家的物品互动系统,实际上也是一种商店系统,只不过其价格和商品不是系统设置,而是玩家操作的而已。
虽然从产品角度来说,都是引导玩家进行某些行为,但是以上两类系统的核心逻辑是有所不同的,因此我打算分成两个部分来描述。
任务系统族:
任务系统的基础数据模型,是一个预设的任务库,存放着大量的任务链以及具体任务。而玩家则有一个任务列表,存放着已经完成的任务、接受后但未完成的任务。具体的任务最重要的是包含着任务完成条件和完成进度的数据,这些任务条件一般来说都是必须全部完成的。因此我们可以抽象出任务系统的基本数据模型:
“任务项”中的“接受条件容器”和“完成条件容器”中,都应该分别对应着两类对象,即“接受条件”和“完成条件”。“接受条件”可以有多个不同的子类型,如判断前置任务是否完成的,玩家是否符合等级,是否具备某个道具等等。而“完成条件/进度”也应该有多个子类型,如“对话操作”“杀怪操作”“物品收集操作”……游戏中一切的操作都应该可以成为完成条件,具体实现则由游戏的操作中,添加钩子处理程序,对玩家身上的完成条件的检索,然后根据游戏操作的逻辑,对这些玩家身上的“完成条件/进度”做修改。这些模型的方法应该有:
由于任务系统的变种种类繁多,所以可能会导致设计大量的“接受条件”和“完成条件进度”类型,所以这些对象的部分属性如“描述文字”等静态内容,应该采用共享数据的形式出现,而不应该反复拷贝。下图初步描述了任务系统族类型的关系:
商店系统族:
商店系统的数据核心模型,是一系列可供展示、销售的商品,用于购买商品的货币,以及为这些商品提供展示之地的商店模型。当然这里的商品可能不一定对应于RPG系统里面的物品道具,因为有些商品是权限、等级等不能放入背包里的东西,也有可能是某种属性、状态等等。但是我们还是推荐用RPG系统中的道具来承载,这样编程的复杂度会比较低。
商店系统看起来非常简单,但是最复杂的地方在于“购买”环节,因为购买得到的商品,不一定是放入背包的货品,所以商品的“被购买”应该是一个可扩展的虚方法函数。这样商品也可以扩展为背包货品类商品和其他商品类。需要注意的是,买入玩家销售的物品,这个功能并不是非常容易重用,这涉及到如何对玩家物品的估价的问题,因此这个能力应该从最基本的“商店”系统扩展,而不应该加入商店系统中。商品系统的对象方法应该有:
商店系统的表现形式非常多样,但是核心逻辑关系却异常简单:
至此,已经描述完主要的引导类系统的设计。这些设计本身可能并不能完成非常复杂的游戏逻辑,但是其基础逻辑却足够简洁。这样基于其开发的上层代码,就具备了一个比较统一的实现结果,便于构造出更多能重用或修改使用的系统。
明天接着讲:
感谢大家的阅读,如觉得此文对你有那么一丁点的作用,麻烦动动手指转发或分享至朋友圈。如有不同意见,欢迎后台留言探讨。