現在的項目算是半個ue3項目移植，策劃要求將原先的教程添加新步驟，第一個教程很快寫完，但是卻花了一下午的時間來查一個bug：
當時看到的現象是怪物格擋次數少了一次（原先是3次），乍一看是個很普通的問題，仔細追了下代碼，發現是由于格擋計次額外多了一次，所以在第二次判斷就跳出了，但問題是額外的那一次自增操作的進入位置是xxxPawn里某個state的label又重入了一次，但是在這里加斷點發現，堆棧沒有更上層了（也就是說是直接從c++層調用過來的），于是就懷疑到是否是新加的代碼誤執行了PopState函數（popState的c++實現會調用gotolabel），最后發現才是某一個if中少加了新的判定，因此沒有跳過這段pop。。
這就是UE3狀態機的一個暗藏邏輯，一個actor原先在state A中，A里有默認執行的Begin標簽，那么在第一次進入這個state A時，會默認走一遍Begin的邏輯，但如果再pushState B(注意，不是gotostate B)，那么當將popState B的時候依然還是將state A的Begin標簽再走一遍的。
回頭看這段思路，其實錯誤很簡單，但是由于游戲原先教程并非是我們寫的，使得我并不了解其實各種跳轉的原因，切state的邏輯大量在c++層和腳本層穿插混合，使得整個調試過程中，即使花在定位問題的時間也是很多（如果可以看到堆棧，估計半小時就定位到問題了）
除了吐槽FSM之外，我也在質疑自己的思考方式，遇到這種問題，花費半個人力日嘗試去完全理解原作者的邏輯是否是最高效的方式呢？如果我當初選擇直接按照舊代碼的邏輯完全拷貝粘貼同樣的代碼，是否就能規避掉這個問題？