前篇：Unity《ATD》塔防RPG類3D遊戲架構設計（一） - KillerAery - 部落格園
《ATD》 遊戲模型
《ATD》策劃案部分摘取：
分析了策劃案後，顯而易見裡面劃分了這4種遊戲模型：
英雄，怪物，陷阱，塔
最初想到的是使用繼承的方式來實現這些遊戲模型（如圖）：
然而考慮到現在的英雄/怪物/陷阱/塔型別已經足夠太多了，而且以後還可能會擴充套件更多。
若用繼承的方式，其派生類數量將到達一個小團隊難以維護的地步。
再想到Unity的GameObject-Component機制，於是最後我採用組合元件的方式來設計這幾個遊戲模型。
至於之前設計Skill機制的時候，為什麼反而採用繼承的方式，原因如下：
- 策劃案裡，Skill的種類只有8種，所以需要編寫的派生類比較少，而英雄/怪物/陷阱/塔所有種類總共加起來有二十多種。
- Skill不是GameObject，沒有Unity提供的GameObject-Component機制，不太方便接納元件（除非自己再實現一套元件模式）。
- 實際上，還有個設計Skill的思路就是把Skill設計成一個行為樹，通過組合節點來生成一個Skill。然而這個想法在當時被我二選一時捨棄了。
首先為了統一術語，避免遊戲模型和Unity的GameObject弄混淆，我們定義了一個稱之為 個體（Individual） 的名詞，來表示一個遊戲模型單位。
那麼如何表示一個個體遊戲物件呢？
首先我們需要編寫一些個體遊戲物件必要的元件指令碼類。
對於一個個體遊戲物件，它可能由如下圖構成：
一般來說行為和輸入都應該放在一起統稱為控制器，然而實際上在遊戲裡，輸入來源可能是玩家，也可能是AI，因此把個體物件行為和輸入分離是個好的選擇。
也就是說它得有屬性，行為，操控行為的輸入，還得可以容納Buff機制，Skill機制和裝備機制（實際被砍了）。
根據這些需求分化出來不少元件類：
然後為了解耦各元件的依賴關係，特別是跨遊戲物件的元件依賴，於是還額外引入了一個 訊息系統元件 ，實際上就是用於實現觀察者模式。
每個個體物件都必須帶一個訊息系統元件，且其他編寫的元件類基本上都依賴這個訊息系統元件。
例如，A個體用指向性技能對B個體進行釋放，則由A個體的 技能系統元件 傳送訊息給B個體的 訊息系統元件 ，然後訊息再轉發給B個體的 Buff系統元件，從而讓B個體受到該Buff影響。
最終個體遊戲物件的元件依賴關係圖：
然後通過一個GameObject然後新增好模型，然後放置一些元件從而組合出來一個個體遊戲物件。
一個怪物個體遊戲物件示例：
《ATD》 遊戲邏輯
先說明一下，全域性遊戲邏輯的全域性並不是指變數的全域性暴露，而是說負責遊戲世界的整體邏輯。
全域性遊戲邏輯設計的話相對輕鬆一點:
- 首先為了更好管理個體遊戲物件，引入了 物件工廠 來控制個體有物件的生命週期。
- 金錢管理器 負責玩家的金錢資料管理，例如擊殺獎勵，關卡結算獎勵。
- 塔管理器 負責用規則限制塔的邏輯，例如建造一個塔的位置限制，建造塔的金錢消耗。
- 關卡管理器 負責生成每波怪物。
為了輔助這些邏輯，還額外引入了訊息系統元件，路徑管理器，怪物生成器三個指令碼。
構造如下：
《ATD》遊戲物件目錄設定：
引入訊息系統是為了讓遊戲邏輯可以監聽個體物件之間的互動訊息，從而做出一些符合遊戲邏輯的行為。
例如，監聽到基地個體物件死亡的訊息，應判斷遊戲失敗。
遊戲邏輯比較多指令碼都需要讀入配置檔案資料的功能，方便動態更新遊戲。
此外，指令碼應在Inspector皮膚應提供一些可調的邏輯引數，方便除錯全域性邏輯（例如金錢數調99999999）。
《ATD》 UI/HUD/特效/音樂
應為UI/HUD/特效/BGM各自編寫一個 UI管理器/HUD管理器/特效管理器/音樂管理器 ：
一是方便管理顯示，二是更好的與遊戲邏輯/遊戲模型來互動。
然後也要為這些管理器引入 訊息系統元件 用於輔助，從而接受一些重要的訊息來改變顯示效果。
舉個例子，Buff特效管理器，通過監聽遊戲模型的Buff訊息，來給對應的遊戲模型生成Buff特效物件。
此時，專案整體架構關係如圖：
是不是感覺有點像MVC檢視？（笑
結語
至此，《ATD》的總體程式結構已經十分明朗了，下一篇應該是最後一篇，已經懶得再寫多點了。
大概內容時將更詳細介紹其中一些具體實現時出現的問題以及解決方案（包含一些trick），還有一些工具。
暫時就先寫到這。