新手引導很多遊戲都有。但是有的做的卻不是那麼如意。有時候引導卡死，卻找不到問題。其實很多時候和設計的機制有關。本文假設引導是一種強制性的引導。一個引導由很多步驟（比如要玩家點哪裡，點哪裡，這些都是一個個步驟）組成。

　　1、引導的發起

　　後端關注的是引導，因此，後端只要各種事件觸發一個引導，把這個引導ID發給客戶端，就完成了引導的發起。

　　客戶端收到服務端發的引導ID，就會獲取這個ID對應的步驟列表。然後播放這些步驟，等待玩家互動完成。

　　2、引導的結束

　　當前端執行完引導步驟時，把引導ID通過一個引導完成的協議傳送給客戶端，這樣好嗎？我覺得這種做法是不安全的。

　　如果是通過客戶端來通知服務端引導完成，會出現2種情況：

　　以強化裝備為例子

　　情況1：先請求強化裝備，再請求引導完成。

　　可能在你請求強化裝備的時候，這個請求發出去了。但是突然斷線了，引導的請求沒發出。這時候。下次上線，他還是會讓你引導。但是，你可能已經沒了強化材料。玩家卡死。

　　情況2：先請求引導完成，再請求強化裝備。

　　請求引導完成發出，斷線，請求強化沒發出。然後玩家下次上線，不會再經歷引導。

　　或許聰明的你會想到可以把引導ID帶在強化裝備的包裡面，一次請求完成。這樣是可以解決上面兩種情況。

　　但是，這樣，相當於，就把強化裝備和引導耦合了。而且，以後可能有升級技能的引導，那麼你升級技能的協議也要帶上引導ID。這樣設計無疑不是最好滴。

　　因此，通過客戶端來通知服務端引導完成是不靠譜的。應該由服務端自己的內部事件來觸發。

　　比如一個強化裝備的引導，客戶端最後肯定會請求服務端要強化裝備。

　　這時候伺服器就可以判斷當前是否有強化裝備的引導。有的話判斷是否滿足完成條件。滿足就完成引導。