前期的系统设计，是在BB的基础上制作的，因为前设计者不是专业的系统策划，所以该系统留下了很多的坑，在接过这个坑之后，做了很多补充和逻辑、功能上的修补，已经可以制作比较完善的强制+触发引导，基本框架已经稳定，后续可以往里添加内容了。
不过，就在这个时候，游戏内添加了任务系统，而且要像GOW系游戏那样制作详尽的任务引导。所以在原有的系统构架上，又添加了任务引导的支持。但就是这个支持，引发了任务引导和触发引导逻辑处理上的问题（因为这两种引导都有同样的特点：触发时机不定，完全视玩家的行为而定，一旦同时触发，从优先级上考虑，应该是触发引导覆盖任务引导，但是从玩家体验上考虑，玩家正在跟随任务引导去完成一个任务，这个时候突然来了一个触发引导，又去引导玩家做和当前所做的事情完全不相关的事情，玩家时崩溃的，引导设计也是失败的），这些问题在触发引导应用不多的时候，暴露的还不多，当我们将大量的引导从强制引导转到触发引导上时，就暴露无疑了。
为了解决这个问题，于是添加了互斥规则（不得不说，互斥规则是个好规则，可以避免陷入bug循环，并能帮助设计者和开发人员理清逻辑思路。在玩家体验不受影响的情况下，互斥规则应当多多使用）：在触发引导进行时，不能进行任务引导；在任务引导完成前，不能进行触发引导。而这也带来了新的问题：
问题1：如果在任务引导过程中，触发引导的触发时机达到，但又无法触发，那这段触发引导怎么处理？
解决方案：保证触发引导的严谨性，首先触发时机做多次检测，而不是一次就结束，其次在触发引导开始前，先检测引导目标是否已经被玩家完成，若完成，则该段引导不再触发。
-
问题2：任务引导什么时候算结束？
- 解决方案：结束的条件有这么几个：1、引导流程完全走完；2、引导流程中途中断。中断的情况又有如下几种：1、玩家未操作，指引光圈自己消失；2、玩家没有按照引导操作，而是去做了其他操作，导致引导光圈消失（玩家打开新界面或者关闭当前指引对象所在界面，引导光圈都会消失）。
引导系统的打断规则图例：
系统应用
首先，明确一下这三个引导模块的区别：
引导的强制程度：强制引导>触发引导>任务引导
玩家的掌控感： 任务引导>触发引导>强制引导
引导的强制程度和玩家的掌控感这两个维度，足以描述各个引导模块的特点了，越强制的引导，对玩家游戏体验的破坏性越强，玩家的掌控感越低，越不强制的引导，对玩家游戏体验的破坏性越低，玩家的掌控感越高。
引导中其实还有模态非模态的问题（模态是指玩家不能点击其他位置，只能点击指引目标，非模态则是除了点击指引目标之外，玩家还可点击其他位置），这三个模块中，强制引导和触发引导是模态的，区别在于强制引导是玩家进入游戏后所必经的流程，并且有非常强的容错性，需要玩家从任意位置退出游戏，回到游戏后都能继续接上引导；而触发引导则是根据玩家行为，通过事件或者检测条件触发的引导，这些引导，如果玩家在触发时机之前，已经完成了引导目标，则不会出现在游戏中对玩家造成困扰。任务引导是非模态的，该种类型的引导其实也是通过一个事件去触发，只不过大部分的触发事件是任务中的引导按钮点击事件。游戏中大部分的不需要强制玩家操作的引导，都归到任务引导类里面。
