在我們專案的實際檢驗中， 發現了一些簡單的問題。

之前我把功能設計的很靈活， 但是使用起來，可能需要去考慮一些東西。
比如下面這個場景：
我需要玩家去 拖拽我們遊戲中的3d建築， 但是玩家又不能去操作UI。 在這種場景下， 如果專案是接管了 unity的原生的全部事件系統， 做這個東西可能會簡單很多， 如果沒有接管過來， 而且也沒有一個輸入的簡單管理類的話。 估計你就寫一些特別傷感了程式碼了。 我們的遊戲有一個簡單的Input的管理器， 但是隻是管理 部分事件， 不包括UI的事件，因為UI的事件是由ugui管著的。 所以在這裡， 策劃可能需要配置， 1. 關閉UI輸入事件。 2. 如果上一部關閉了禁止建築操作的節點， 那麼也需要在這裡開啟。 3. 如果下一步需要開啟UI事件，遮蔽建築點選事件， 那麼我在下一步需要配置 開啟UI輸入事件 和 建築點選事件 這麼來看的話。 節點的自由組合是特別的靈活， 但是組合比較繁瑣， 如果不小心遺漏東西的話， 就很容易出現BUG， 而且還不好復現。
所以在架構中， 引用了公共節點這種概念： 公共節點由一個指令碼持有， 是指令碼的所有的步驟的共有節點。 每當我要進行一個step的時候， 那麼我就需要把公共節點執行一次

。
引入了公共節點之後， 在每個指令碼中， 我初始加入3個公共節點： 1. 關閉UI輸入 2. 關閉攝像機操作 3. 關閉建築點選。。。 等等 所有影響新手引導流程的輸入源。 然後在每一個步驟中， 我需要什麼輸入源， 那麼我就開啟什麼輸入源， 這樣就不會有輸入源忘記關閉或者遺漏，導致點穿的情況出現。
為了優化使用者體驗， 我們可以對一些顯而易見的節點做特殊的優化， 比如某個節點是讓玩家點選某個UI元素， 那麼我們可以在程式碼中顯示的直接開啟UI輸入， 同時在編輯器的顯示中提示策劃，這個節點會開啟UI輸入源。 某個節點是讓玩家點選某個建築， 那麼我們可以在程式碼中直接開啟建築點選輸入等等。 。 這樣既節省了策劃使用編輯器編輯的時間，也節省了我看他們製作的指令碼的時間。畢竟檢測某個步驟的輸入源是否正確的關閉，這種事情還是很費時間的， 而且不好進行測試。
所以有些時候，給與一些善意的限制，其實感覺是有必要的。 只是這個怎麼去尋找，需要靠實際經驗去檢驗。

最後再談談我一直比較介意的這套系統的一個問題， 就是反射用的比較多。
反射用的多，在編輯模式下，我其實不是特別在意的。 因為編輯模式，效率再慢，也只是策劃體驗，而且PC機，一般情況下也不會特別慢。 主要是在執行時的時候， 當新手引導邏輯根據儲存好的鍵值對，使用反射反序列到遊戲例項上， 我覺得這個特別消耗效率。
現在有2個解決方案去解決這個問題：
1. 第一個解決方案： 我們遊戲的Node的種類是有限的， 就算Node種類再多， 應該也就不到100種。 我們對每種Node再反射完成之後， 記錄好它的反射結構， 下次需要的時候，直接拿反射好的結構去賦值。這樣能解決部分問題。
2. 動態生成程式碼的形式生成新手引導的C#初始化程式碼。 但是很不好的體驗就是每次一進行修改， 就會有編譯行為產生。
2. 使用指令碼語言， 動態生成指令碼語言的程式碼。如果使用指令碼語言， 那麼資料就沒有型別轉換一說， 直接進行賦值了。所以也能繞過去。 比如使用lua。