MOBA 遊戲技能系統設計 2.0

隨着遊戲開發的完整度提高，技能系統的設計複雜性也愈來愈高，致使了用模板方式的配置方法和處理方法會致使如下幾個問題：

1. 代碼冗餘
2. 排錯困難
3. 配置項冗餘
4. 熟悉業務流程時間長
5. 擴展性低

 

通過我思考決定重寫之。分析如下幾個觀點，因爲早期設計上的侷限，和實際開發預期的不符，技能系統也必然會成爲策劃腦洞大開的一個點，而且也會成爲MOBA遊戲體驗的深度核心項之一。因而一個成熟的MOBA技能系統應該包含一下幾點：

1. 代碼流程清晰
2. 錯誤定位精確
3. 配置項定位精確
4. 熟悉業務流程時間短
5. 擴展性強

 

　應該還有一些我沒有想到或者沒有記錄到的點，在此就說明以上幾個。

 有一些程序在設計一些高擴展性同時又是核心要素的系統時，不出意外的也會遇到以上的幾個問題。

 

　這裏的核心關鍵就是：

　　在設計之初對將來的需求是未知且不可預測的。

 

　那麼我是怎麼解決以上的幾個問題的呢？

 

　由於我一直在使用 Unity 作前端開發。深知Unity的ECS (實體組件系統) 架構體系帶來的便利。

　因而我打算根據ECS的架構方式的模子去設計，但不徹底根據ECS的架構來，保持對具體項目需求的貼切。

 

　因而我設計了以下三個層：

1. 流程控制層
2. 原子函數層（技能）
3. 邏輯層（技能）

　有時候我認爲這個設計很像行爲樹。好吧確實有點像，但又不是那麼像。這裏不深究，留疑。核心仍是留在解決需求上。

　流程控制層具有如下幾個組件：

1. CtrlBase -> 做爲全部流程控制的基類
2. CtrlBreak -> 用於中斷全部流程控制組件
3. CtrlCondition -> 用於流程控制中的分支操做
4. CtrlDelayTime -> 用於流程控制中的延時執行操做
5. CtrlDuration -> 用於在一段時間內執行一組動做
6. CtrlSequence -> 用於序列執行一組動做
7. CtrlTimeLine 組件 -> 用於建立一個時間軸，讓全部流程組件在這個時間軸上執行

 

　原子函數層（技能）具有如下幾個組件：

1. SkillCondition -> 提供技能條件的斷定
2. SkillEntity -> 提供技能實體的操做
3. SkillFightObjMap -> 提供戰鬥對象查詢獲取等操做
4. SkillInOutValueToPlayer -> 提供對戰鬥對象角色的數值輸入輸出
5. SkillPlayuerCtrl -> 提供對角色的控制操做
6. SkillTarget -> 提供技能對象的具體信息

 

　邏輯層（技能）：

1. SkillBase -> 全部邏輯層的基類 定義全部的技能邏輯層數據
2. Hero1/skill_1 -> 英雄1的技能1邏輯對象
3. Hero2/skill_2 -> 英雄2的技能2邏輯對象
4. ...類推

 

　從以上的結構中能夠直接看出目前的冗餘層在邏輯層，而邏輯層的支撐在控制層和原子函數層，隨着開發深度的愈來愈高，控制層和原子函數層的操做組件會愈來愈多或功能性愈來愈強。則爲邏輯層提供的操做/組合方式更爲豐富，則可實現的動做會更爲強大。

 

　而且從排錯來講只要控制層和原子層確保無誤（實際也必須無誤），基本錯誤定位能直接找到對應技能的邏輯層，且邏輯層沒有多餘代碼，每一句都和技能的具體邏輯有所關聯，線性排錯。難度低。如若錯誤出在原子或控制層則是一批技能同時出現問題，也好定位。

 

　因此這裏已經作到代碼流程清晰，錯誤定位精確。

 

　同時由於每一個技能有獨立邏輯層則配置的定義也能夠獨立，這裏也作到了配置項定位精確。

 

　基於以上幾點精肯定位的特性致使熟悉業務的時間就所以變短了。

　又由於原子函數層/控制層的支持性可擴展，具體技能的業務邏輯可定製，因此擴展性強了。

 

　基於這種設計模式，帶來的好處可見是很是大的，可是同時也致使了必需要讓程序長期來維護或定製具體的技能模塊。因此我一直認爲策劃是能夠具有一些腳本功底的，只要咱們保證原子函數層和控制層提供的是安全接口。則能夠對策劃放開腳本編寫，甚至能夠用弱類型解析類腳本語言來提供具體的技能邏輯定製。

 

　還有一種方案是開發一款可以生成邏輯層的流程編輯器，將原子函數層和控制層反射導入。生成邏輯層代碼。不過這個成本過高並且規則很差定製。有可能還沒程序直接編程性價比更高。因此我沒有選擇開發流程編輯器的方式。

 

　這個架構在我實際運用中，感受仍是很是好的，由於大多的技能其實類似性仍是蠻高的，若是技能難度不高，原子函數不須要迭代添加，則進行邏輯組合的時候實際效率很高。我剛剛開發完這套系統，重構現有的技能（10個左右）也就花了3個小時左右吧。相比模板開發的方式我認爲在定製和排錯擴展的方面效率要高的多，並且對開發者的友好度更高。

 

　總結下來我認爲全部的設計都應該創建在更貼切實際開發需求上，我認爲全部的系統設計都應該創建在需求的不可預知和靈活性擴展上，同時也須要衡量它的性價比，不作過分設計，不墨守成規。