引导系统开发记录

前期的系统设计,是在BB的基础上制作的,因为前设计者不是专业的系统策划,所以该系统留下了很多的坑,在接过这个坑之后,做了很多补充和逻辑、功能上的修补,已经可以制作比较完善的强制+触发引导,基本框架已经稳定,后续可以往里添加内容了。

不过,就在这个时候,游戏内添加了任务系统,而且要像GOW系游戏那样制作详尽的任务引导。所以在原有的系统构架上,又添加了任务引导的支持。但就是这个支持,引发了任务引导和触发引导逻辑处理上的问题(因为这两种引导都有同样的特点:触发时机不定,完全视玩家的行为而定,一旦同时触发,从优先级上考虑,应该是触发引导覆盖任务引导,但是从玩家体验上考虑,玩家正在跟随任务引导去完成一个任务,这个时候突然来了一个触发引导,又去引导玩家做和当前所做的事情完全不相关的事情,玩家时崩溃的,引导设计也是失败的),这些问题在触发引导应用不多的时候,暴露的还不多,当我们将大量的引导从强制引导转到触发引导上时,就暴露无疑了。

为了解决这个问题,于是添加了互斥规则(不得不说,互斥规则是个好规则,可以避免陷入bug循环,并能帮助设计者和开发人员理清逻辑思路。在玩家体验不受影响的情况下,互斥规则应当多多使用):在触发引导进行时,不能进行任务引导;在任务引导完成前,不能进行触发引导。而这也带来了新的问题:

  • 问题1:如果在任务引导过程中,触发引导的触发时机达到,但又无法触发,那这段触发引导怎么处理?

  • 解决方案:保证触发引导的严谨性,首先触发时机做多次检测,而不是一次就结束,其次在触发引导开始前,先检测引导目标是否已经被玩家完成,若完成,则该段引导不再触发。

  • 问题2:任务引导什么时候算结束?

    • 解决方案:结束的条件有这么几个:1、引导流程完全走完;2、引导流程中途中断。中断的情况又有如下几种:1、玩家未操作,指引光圈自己消失;2、玩家没有按照引导操作,而是去做了其他操作,导致引导光圈消失(玩家打开新界面或者关闭当前指引对象所在界面,引导光圈都会消失)。

引导系统的打断规则图例:

image.png

系统应用

首先,明确一下这三个引导模块的区别:

引导的强制程度:强制引导>触发引导>任务引导
玩家的掌控感: 任务引导>触发引导>强制引导

引导的强制程度和玩家的掌控感这两个维度,足以描述各个引导模块的特点了,越强制的引导,对玩家游戏体验的破坏性越强,玩家的掌控感越低,越不强制的引导,对玩家游戏体验的破坏性越低,玩家的掌控感越高。

引导中其实还有模态非模态的问题(模态是指玩家不能点击其他位置,只能点击指引目标,非模态则是除了点击指引目标之外,玩家还可点击其他位置),这三个模块中,强制引导和触发引导是模态的,区别在于强制引导是玩家进入游戏后所必经的流程,并且有非常强的容错性,需要玩家从任意位置退出游戏,回到游戏后都能继续接上引导;而触发引导则是根据玩家行为,通过事件或者检测条件触发的引导,这些引导,如果玩家在触发时机之前,已经完成了引导目标,则不会出现在游戏中对玩家造成困扰。任务引导是非模态的,该种类型的引导其实也是通过一个事件去触发,只不过大部分的触发事件是任务中的引导按钮点击事件。游戏中大部分的不需要强制玩家操作的引导,都归到任务引导类里面。

你可能感兴趣的:(引导系统开发记录)