重構心得

最近一直在做有關技能和戰鬥相關的代碼整理，也史無前例血淚交加的進行了3次重構，程序員果然是一群與眾不同的群體，如此的樂於推翻自己過往的工作，卻又樂此不疲。

但是話說回來，每一次的重構都帶來的意想不到的效果，雖然說中途會遇到一些小問題，但是大體上來說，重構帶來的好處是非常多的，特別適合項目前期探索階段。

戰鬥技能的腳本系統

一般遊戲都免不了需要接觸戰鬥系統，戰鬥無非就是單位/技能/Buff/飛行物/事件這些模塊而已。而這其中的核心就是技能。 最開始做的一版架構下，每一個技能都由腳本進行處理，通過技能表直接映射到技能文件，新加一個技能新寫一個腳本文件，這樣的好處是，技能邏輯可以做的非常靈活，而且調試也比較方便，直接在相應的技能中output或者斷點就好了。

第二次重構

不過上述做法缺點也是很明顯的，新加一個技能必須重新新一些一個腳本。雖然可以通過模版的方式減少後續的操作，但是追求完美的程序是不會止步於此（閑的蛋疼）的，考慮到多數技能可能只是中途的某些元素不一樣，其實多數流程大體上都差不多（造成傷害，搜索單位，移動目標，顯示特效，播放動作，等等），那麽我們是不是可以將這些元素獨立出來，並提供一個可以配置的機制，這樣任何一個技能只是基礎元素的組合，程序只需要維護一個個的基礎元素就好。這樣就形成了第二次重構的思路基礎。具體設計上，我們獨立出來了一個效果的概念，技能可以擁有多個效果，效果可以主動施放的時候觸發，也可以被動監聽事件的時候觸發，效果內部是一個個的基礎元素，我們稱之為操作，操作附帶條件，這樣一個效果內就形成了一個簡單的邏輯，技能施放本質上就是走效果內部的邏輯流程。工作中實際情況是，重構結束後技能應用配置上也確實達到了預期的效果，程序員不用再維護一個個的技能了，確實蠻爽的，但是需要著重註意的一點是，對基礎元素的設計一定要慎重，我們現在光是傷害就有5種基礎的操作，沒辦法，需求就是要支持不同類型。所以基礎元素的設計一定要根據具體的遊戲需求來。

第三次重構

最開始的設計上，邏輯和顯示是一一對應的，完全的所見即所得，遊戲中進行到了什麽步驟，比如回合制中等待玩家操作，單位A移動中這些情況下，邏輯也是完全處於這個狀態的，這種設計的好處是在於，所見即所得，調試清晰，缺點也非常的明顯，就是邏輯和顯示存在耦合。舉個例子就是施放技能，當顯示復雜一些的時候，邏輯甚至需要去讀取某一個模型的執行時間來決定邏輯自身需要協程式的卡住多久，這種設計下實現邏輯會非常復雜，特別是邏輯存在各種各樣事件的時候。這個需求促使了我們進行了第三次重構。首先我們分析，由於我們自己是一個回合制遊戲，遊戲中並不存在過多的玩家操作，甚至可以非常簡化，即輪到玩家的操作，施放一下技能，後續的邏輯（直到下一輪之前）都是確定的。那麽我們可以這樣設計：玩家操作後（主要是技能施放），邏輯就開始進行運算，在一幀之內將所有的結果都計算完畢，亦即邏輯已經停留在了下一回合階段，在這個過程中邏輯會輸出一系列的顯示流，通知顯示進行處理。顯示層根據顯示流來進行一個個具體表現的處理，諸如顯示單位，播放動作，播放特效等等。這樣的好處是，將復雜的表現和清晰的邏輯分開，表現層只關心自己的表現，而邏輯可以更清晰的處理自己最終輸出數據的結果，分離的算是比較完美。這種設計的復雜度會更多的交給表現，甚至是表現需要負責進行表現的排序處理等等。不過這種設計帶來的好處實在是太多了，過往我們需要做諸如遊戲開始後整個邏輯屏幕抖動一下/播放各種特效後遊戲才真正開始這樣的效果，是需要修改邏輯的，現在邏輯已經完全不關心這個了，全部交給表現來處理，可以做很多豐富的效果。

總結

總而言之，對於產品來說，好的遊戲都是磨出來的，而對於程序來說，好的設計也都是重構出來的。 與君共勉！！！

近期重構技能的一些心得