1、拆分成指引小组
把指引步骤，尽量拆分的细一些。比如，虽然创建英雄祭坛和招募英雄是连续的步骤，但是，应该拆分成两组指引，创建，招募各代表一组。最理想的情况是，每一步只跟服务器进行一次信息同步。这样，就比较容易进行断点返还。
每一个小组有一个编号 比如 1000，每一个小组中的每一步都有一个小步骤编号如1，2，3。这样每一步的指引就有一个唯一的编号=小组编号 +步骤编号， 如1001。
2、每一步的触发条件
指引系统的每一步，不应该自己一步步驱动，也不应该通过计时控制，而应该是有游戏的业务逻辑驱动的。触发条件会有这几类：
*进入场景
*打开界面
*收到数据包，并成功
*关闭界面
为了不让指引代码散落在游戏代码各处，难以维护，我们在这些位置，让他们抛出一些通用的消息。然后在指引系统中设置监听。并处理逻辑。当然为了优化，可以在一个指引小组开启的时候，再设置监听，小组结束后清除这个小组的所有监听。
3、限定条件
因为触发条件是一条通用消息，这种消息发出的很频繁（比如打开英雄界面，每次打开都会发送这样一条消息），所以指引需要用一定的条件去判断这条消息是不是真的触发这一条指引。
这里存在两种情况：
1）小组内的指引，这种比较简单，因为小组已经开始，所以收到消息之后，只需要判断当前当前的小组对不对，还有上一条指引的ID是不是匹配，就可以断定，应不应该出这一条指引。
2）小组开始的指引，这个判断会比较麻烦，判断条件大概会分为下面几类：
*当前是不是在指引中（确保不会同时出现两个指引小组）
*第一次打开，或者进入某某某
*某功能是否开启
*玩家等级
*基地等级
这些判断条件的组合，一定要是开启指引的充要条件。否则就会出问题。这是真个最麻烦的一点，最考验细节的一点。
4、断点返还机制
每一个指引小组，有两种可能，开启断点返还，和不开启断点返还。前者只要关键步骤没有进行过（例如，指引创建建筑过程中，创建成功的服务器回包），那如果再次满足条件，还会开启指引。后者是只要指引开启过了，那就不会再次指引了。
实现方式，以指引小组为单位，在服务器或者本地记录一个bool值，记录这个指引小组是否开启过。需要开启断点返还的指引步骤，在关键步骤结束后，就将这个bool值置为true，它将会成为这一步指引是否开启的判断条件。对于不使用断点返还的指引小组，在指引开始的第一步就置为true即可。
如果一个指引，需要的前提条件比较多，指引繁复，那为了保险起见，还是做成不支持断点返还的为好。