收藏产品经理能力模型

浅谈任务模块的设计思路

2023-02-05  本文已影响0人  何处生才

任务模块是所有游戏必备的一个模块,每日任务、连续签到等都是任务模块中的一种表现形式,甚至很多活动也都是由任务组成的,比如春节期间很火的集福卡活动。今天就让我来分享一下我对设计一个通用的任务模块的想法。

了解任务

在开始设计任务模块之前,我们先通过几个例子来深入了解一下任务:

通过以上的几个例子,我们可以发现任务的描述是有规律的:通过/完成/收集等+关卡/物品/签到天数等+获得金币/抽奖机会/徽章/水晶等,总结一下就是任务=动作+数值变化+奖励。

动作是一个很泛的词,在系统里发生的任何操作都可以称之为动作,比如分享到朋友圈、收藏物品、点赞某篇帖子等,而动作的发生就意味着必然会影响到系统中的数据,比如每次签到会让签到天数加一,签到七次后用户的签到天数就达到了七,这就是数值的变化。理论上来说,只要有动作,都可以设计出对应的数值。再来说奖励,奖励就是对用户完成任务的一种正向的反馈,可以是任何东西,比如金币、抽奖机会、解锁新地图、成就徽章等等。

从上述可知,任务本质上就是完成某个动作导致数值变化进而获得了奖励。

验证设计

在了解到任务的构成并且大概对任务有了新的描述方式后,我们可以尝试用刚刚的例子来验证一下:

经过上述例子的验证,我们可以发现刚刚得出的任务描述方法看似都可以描述得了所有的任务,但是又存在一个很大的问题——描述动作繁琐,比如最后一个例子收集红玫瑰动作,假设某个游戏里存在红玫瑰、黄玫瑰、粉玫瑰等,那就需要定义收集红玫瑰动作、收集黄玫瑰动作、收集粉玫瑰动作等,打倒小野怪的例子也是一样,如果存在很多种野怪,就会存在重复定义动作的情况,这从系统设计上来说就是冗余的不合理的,应该是“收集”为一个动作,红玫瑰黄玫瑰粉玫瑰等只是动作执行的对象。

重新定义

重新回到最开始对任务的了解,其实我们对任务的描述是没有问题的,但仔细琢磨就会发现“任务本质上就是完成某个动作导致数值变化进而获得了奖励”这句话里其实多了非必要的因子——动作。从动作、数值以及奖励的关系我们也可以发现,奖励的获取其实跟动作没有直接关系,而是数值变化直接导致了奖励的获取。因此我们可以在设计通用的任务模块时考虑把动作单独拎出来,也就是说任务=数值变化+奖励,而动作只是触发数值变化的一种方式。

这时候我们就会发现,当我们用新的任务结构去描述刚刚的例子就合情合理了:

写在最后

以上便是我对任务模块的逻辑部分的设计思路,由数值和奖励组成的任务模块理论上是可以支撑绝大多数任务场景的(奖励理论上也可以是数值变化,感兴趣的朋友可以往深去思考如果设计成数值变化会有什么影响),对于后续的具体设计我就不展开多讲了,有了框架后只需要往框架上去补充完整就好。大家如果有什么其他的想法,欢迎留言探讨。

上一篇下一篇

猜你喜欢

热点阅读