Unity《ATD》塔防RPG類3D遊戲架構設計（二）

目錄

• 《ATD》 遊戲模型
• 《ATD》 遊戲邏輯
• 《ATD》 UI/HUD/特效/音樂
• 結語

---

前篇：Unity《ATD》塔防RPG類3D遊戲架構設計（一） - KillerAery - 博客園

---

《ATD》 遊戲模型

《ATD》策劃案部分摘取：

分析了策劃案後，顯而易見裏面劃分了這4種遊戲模型：
英雄，怪物，陷阱，塔

最初想到的是使用繼承的方式來實現這些遊戲模型（如圖）：

然而考慮到如今的英雄/怪物/陷阱/塔類型已經足夠太多了，並且之後還可能會擴展更多。
若用繼承的方式，其派生類數量將到達一個小團隊難以維護的地步。

再想到Unity的GameObject-Component機制，因而最後我採用組合組件的方式來設計這幾個遊戲模型。

至於以前設計Skill機制的時候，爲何反而採用繼承的方式，緣由以下：

1. 策劃案裏，Skill的種類只有8種，因此須要編寫的派生類比較少，而英雄/怪物/陷阱/塔全部種類總共加起來有二十多種。
2. Skill不是GameObject，沒有Unity提供的GameObject-Component機制，不太方便接納組件（除非本身再實現一套組件模式）。
3. 實際上，還有個設計Skill的思路就是把Skill設計成一個行爲樹，經過組合節點來生成一個Skill。然而這個想法在當時被我二選一時捨棄了。

首先爲了統一術語，避免遊戲模型和Unity的GameObject弄混淆，咱們定義了一個稱之爲 個體（Individual） 的名詞，來表示一個遊戲模型單位。

那麼如何表示一個個體遊戲對象呢？
首先咱們須要編寫一些個體遊戲對象必要的組件腳本類。

對於一個個體遊戲對象，它可能由以下圖構成：

通常來講行爲和輸入都應該放在一塊兒統稱爲控制器，然而實際上在遊戲裏，輸入來源多是玩家，也多是AI，所以把個體對象行爲和輸入分離是個好的選擇。

也就是說它得有屬性，行爲，操控行爲的輸入，還得能夠容納Buff機制，Skill機制和裝備機制（實際被砍了）。

根據這些需求分化出來很多組件類：

而後爲了解耦各組件的依賴關係，特別是跨遊戲對象的組件依賴，因而還額外引入了一個 消息系統組件 ，實際上就是用於實現觀察者模式。
每一個個體對象都必須帶一個消息系統組件，且其餘編寫的組件類基本上都依賴這個消息系統組件。

例如，A個體用指向性技能對B個體進行釋放，則由A個體的 技能系統組件 發送消息給B個體的 消息系統組件 ，而後消息再轉發給B個體的 Buff系統組件，從而讓B個體受到該Buff影響。

最終個體遊戲對象的組件依賴關係圖：

而後經過一個GameObject而後添加好模型，而後放置一些組件從而組合出來一個個體遊戲對象。

一個怪物個體遊戲對象示例：

---

《ATD》 遊戲邏輯

先說明一下，全局遊戲邏輯的全局並非指變量的全局暴露，而是說負責遊戲世界的總體邏輯。
全局遊戲邏輯設計的話相對輕鬆一點:

1. 首先爲了更好管理個體遊戲對象，引入了 對象工廠 來控制個體有對象的生命週期。
2. 金錢管理器 負責玩家的金錢數據管理，例如擊殺獎勵，關卡結算獎勵。
3. 塔管理器 負責用規則限制塔的邏輯，例如建造一個塔的位置限制，建造塔的金錢消耗。
4. 關卡管理器 負責生成每波怪物。

爲了輔助這些邏輯，還額外引入了消息系統組件，路徑管理器，怪物生成器三個腳本。

構造以下：

《ATD》遊戲對象目錄設置：

引入消息系統是爲了讓遊戲邏輯能夠監聽個體對象之間的交互消息，從而作出一些符合遊戲邏輯的行爲。
例如，監聽到基地個體對象死亡的消息，應判斷遊戲失敗。

遊戲邏輯比較多腳本都須要讀入配置文件數據的功能，方便動態更新遊戲。

此外，腳本應在Inspector面板應提供一些可調的邏輯參數，方便調試全局邏輯（例如金錢數調99999999）。

---

《ATD》 UI/HUD/特效/音樂

應爲UI/HUD/特效/BGM各自編寫一個 UI管理器/HUD管理器/特效管理器/音樂管理器 ：
一是方便管理顯示，二是更好的與遊戲邏輯/遊戲模型來交互。

而後也要爲這些管理器引入 消息系統組件 用於輔助，從而接受一些重要的消息來改變顯示效果。
舉個例子，Buff特效管理器，經過監聽遊戲模型的Buff消息，來給對應的遊戲模型生成Buff特效對象。

此時，項目總體架構關係如圖：

是否是感受有點像MVC視圖？（笑

---

結語

至此，《ATD》的整體程序結構已經十分明朗了，下一篇應該是最後一篇，已經懶得再寫多點了。
大概內容時將更詳細介紹其中一些具體實現時出現的問題以及解決方案（包含一些trick），還有一些工具。

暫時就先寫到這。