游戏新手引导前后端代码设计2个要点

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

　　1、引导的发起

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

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

　　2、引导的结束

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

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

　　以强化装备为例子

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

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

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

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

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

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

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

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

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