新手引导很多游戏都有。但是有的做的却不是那么如意。有时候引导卡死，却找不到问题。其实很多时候和设计的机制有关。本文假设引导是一种强制性的引导。一个引导由很多步骤(比如要玩家点哪里，点哪里，这些都是一个个步骤)组成。

1、引导的发起

后端关注的是引导，因此，后端只要各种事件触发一个引导，把这个引导ID发给客户端，就完成了引导的发起。

客户端收到服务端发的引导ID，就会获取这个ID对应的步骤列表。然后播放这些步骤，等待玩家交互完成。

2、引导的结束

当前端执行完引导步骤时，把引导ID通过一个引导完成的协议发送给客户端，这样好吗?我觉得这种做法是不安全的。

如果是通过客户端来通知服务端引导完成，会出现2种情况：

以强化装备为例子

情况1：先请求强化装备，再请求引导完成。

可能在你请求强化装备的时候，这个请求发出去了。但是突然断线了，引导的请求没发出。这时候。下次上线，他还是会让你引导。但是，你可能已经没了强化材料。玩家卡死。

情况2：先请求引导完成，再请求强化装备。

请求引导完成发出，断线，请求强化没发出。然后玩家下次上线，不会再经历引导。

或许聪明的你会想到可以把引导ID带在强化装备的包里面，一次请求完成。这样是可以解决上面两种情况。

但是，这样，相当于，就把强化装备和引导耦合了。而且，以后可能有升级技能的引导，那么你升级技能的协议也要带上引导ID。这样设计无疑不是最好滴。

因此，通过客户端来通知服务端引导完成是不靠谱的。应该由服务端自己的内部事件来触发。

比如一个强化装备的引导，客户端最后肯定会请求服务端要强化装备。

这时候服务器就可以判断当前是否有强化装备的引导。有的话判断是否满足完成条件。满足就完成引导。