從「一對多通訊噩夢」到「優雅解耦架構」的救贖之路

📚 目錄

1. 前言：三年來最常用的設計模式
2. 什麼是觀察者模式？為什麼遊戲開發離不開它？
3. Unity 開發中沒有觀察者模式的災難現場
4. Unity Events vs C# Events：選擇適合的工具
5. 實戰重構：從緊密耦合到鬆散耦合
6. 進階應用：打造企業級遊戲架構
7. 性能優化與最佳實踐
8. 總結與學習資源推薦

---

前言：三年來最常用的設計模式

在我三年的遊戲前端工程師經驗中，要說哪個設計模式最實用、最能解決實際問題，絕對是觀察者模式（Observer Pattern）。

從第一個專案的角色升級系統，到後來參與的大型 MMORPG UI 框架，再到最近的即時戰略遊戲，觀察者模式到處都用得到。它解決了遊戲開發中最核心的問題：怎麼讓多個系統協同工作，但又不要互相依賴得太緊密。

記得剛入行時，我寫的程式碼就像義大利麵一樣亂：玩家升級時，要手動更新 UI、播放音效、儲存進度、檢查成就...每個功能都硬塞在升級函數裡。結果一個函數 200 行，改任何一個子系統都要動到核心邏輯。

直到真正搞懂觀察者模式，整個開發世界都不一樣了。今天想把這三年的實戰經驗完整分享給大家。

---

什麼是觀察者模式？為什麼遊戲開發離不開它？

🎯 核心概念說明

觀察者模式就是定義物件間的「一對多」依賴關係。當一個物件狀態變了，所有依賴它的物件都會自動收到通知並更新。

簡單講：

• Subject（主題/被觀察者）：狀態會變化的物件
• Observer（觀察者）：需要對狀態變化做反應的物件
• 通知機制：狀態改變時，自動通知所有觀察者

🎮 在遊戲開發中的實際應用

想像你在玩 RPG，角色升級時會發生什麼？

傳統緊密耦合的做法： 升級函數 → 直接呼叫 UI 更新 → 直接呼叫音效播放 → 直接呼叫成就檢查 → 直接呼叫資料儲存...

觀察者模式的做法： 升級事件發生 → 廣播「玩家升級」事件 → 各個關心這事件的系統自動回應

🔥 為什麼遊戲開發特別需要它？

1. 系統超複雜：現代遊戲有 UI、音效、特效、AI、網路一堆子系統
2. 需求變個不停：遊戲開發就是在不斷改需求
3. 團隊協作：不同工程師負責不同子系統
4. 要能測試：需要獨立測試各個功能模組

觀察者模式讓這些問題都能解決。

---

Unity 開發中沒有觀察者模式的災難現場

🚨 災難案例一：RPG 角色升級系統

我第一個專案遇到的慘案：

玩家角色升級時，需要同時處理：

• UI 更新：等級顯示、經驗條、角色面板、技能點提示
• 音效播放：升級音效、語音提示、背景音樂變化
• 視覺效果：升級光效、角色發光、粒子爆炸
• 遊戲邏輯：解鎖新技能、增加屬性、重算戰鬥力
• 資料同步：本機儲存、伺服器同步、成就檢查
• 社交功能：升級通知、好友動態、排行榜更新

最初的惡夢設計：所有邏輯都寫在一個 LevelUp() 函數裡，這函數最後變成 300 行的怪物！每當 UI 設計師說要調整升級面板，或音效師要換升級音效，我都要在這巨大函數裡小心翼翼地改。

連鎖反應更慘：

• UI 系統重構 → 升級邏輯要改
• 音效系統優化 → 升級邏輯要改
• 新增成就系統 → 升級邏輯要改
• 網路協定更新 → 升級邏輯又要改

結果一個看似簡單的「角色升級」功能，變成整個專案最難維護的部分。

🎭 災難案例二：MMORPG 的公會戰系統

另一個專案開發公會戰功能時的挑戰：

公會戰開始時，需要通知：

• 所有線上玩家：顯示戰爭開始的全服公告
• 參戰公會成員：傳送到戰場、切換 UI 模式、啟用戰爭技能
• 觀戰玩家：開放觀戰介面、更新排行榜
• 伺服器系統：記錄戰爭開始時間、初始化戰場狀態
• GM 工具：即時監控戰爭進度
• 直播系統：自動開始錄製精彩時刻

初期的災難實作： 公會戰管理器要持有所有這些系統的參考，戰爭開始時一個一個呼叫它們的方法。程式碼變成：

戰爭開始() {
    通知所有玩家系統.顯示公告()
    玩家傳送系統.傳送參戰者()
    UI系統.切換戰爭模式()
    技能系統.啟用戰爭技能()
    觀戰系統.開放觀戰()
    排行榜系統.更新顯示()
    伺服器同步.記錄開始時間()
    GM工具.開始監控()
    直播系統.開始錄製()
    // 還有 20+ 個其他系統...
}

這設計的問題：

• 公會戰管理器變成「神級類別」，要了解所有子系統
• 新增任何相關功能都要改核心邏輯
• 系統間依賴關係亂成一團
• 沒辦法獨立測試任何功能

🎰 博弈遊戲的連鎖反應噩夢

在老虎機專案中遇到的典型問題：

玩家觸發「大獎獲勝」時，需要同時處理：

• 金幣系統：增加玩家金幣、更新 VIP 經驗、觸發充值引導
• UI 回饋：播放獲獎動畫、更新餘額顯示、彈出慶祝彈窗
• 音效特效：播放大獎音樂、震動手機、觸發全螢幕特效
• 社群分享：自動截圖、產生分享內容、推送到社群
• 資料統計：記錄獲獎資料、更新玩家標籤、觸發個人化推薦
• 防作弊檢查：驗證獲獎合法性、記錄異常行為

原始的緊密耦合設計： 老虎機控制器算出大獎後，要手動呼叫所有相關系統。這導致：

• 核心遊戲邏輯跟周邊功能混在一起
• 新增行銷活動要改遊戲核心程式碼
• A/B 測試不同獲獎回饋要大改程式碼
• 不同地區的本地化需求讓程式碼分支過多

---

Unity Events vs C# Events：選擇適合的工具

在 Unity 實作觀察者模式，主要有兩種方式：Unity Events 和 C# Events。根據實戰經驗，選對工具很重要。

🛠️ Unity Events：視覺化配置的好幫手

適合的場景：

• 需要在 Inspector 設定的事件
• 原型開發和快速測試
• 設計師需要參與設定的邏輯
• 簡單的一對多通訊

實際應用案例： 在角色升級系統中，用 Unity Events 讓策劃直接在 Inspector 設定升級時要觸發的音效和特效，不用工程師介入。

設定流程：

1. 在角色控制器定義 OnLevelUp Unity Event
2. 在 Inspector 把音效組件、特效組件、UI 組件拖進事件列表
3. 選擇要呼叫的具體方法（如播放音效、顯示特效）
4. 策劃隨時可以調整設定，不用改程式碼

優點：

• 視覺化設定，直觀好懂
• 不用寫程式碼就能建立事件連接
• 適合快速原型開發
• 設計師友善

缺點：

• 效能開銷比較大
• 除錯困難（看不到呼叫鏈）
• 沒辦法在執行時動態控制
• 型別安全性比較差

⚡ C# Events：工程師的精準工具

適合的場景：

• 需要在執行時動態註冊/取消註冊
• 對效能要求較高的系統
• 複雜的事件邏輯和條件判斷
• 需要傳遞複雜資料的事件

實際應用案例： 在 MMORPG 專案中，用 C# Events 實作動態 Buff 系統。不同 Buff 可以在執行時監聽角色各種事件（攻擊、受傷、移動等），根據條件觸發效果。

核心概念：

• 用 event Action 或 event Action<T> 定義事件
• 透過 += 和 -= 操作符管理監聽器
• 事件只能在定義它的類別內部觸發
• 有完整的型別安全保障

優點：

• 效能優秀，開銷小
• 型別安全，編譯時檢查
• 可以傳遞複雜的資料結構
• 支援執行時動態管理
• 除錯友善，可以追蹤呼叫鏈

缺點：

• 需要寫程式碼管理事件訂閱
• 對初學者不夠直觀
• 忘記取消訂閱可能導致記憶體洩漏

🎯 選擇策略

我的建議：

• 原型階段：用 Unity Events 快速驗證概念
• 正式開發：用 C# Events 建立穩定架構
• 混合使用：UI 相關用 Unity Events，遊戲邏輯用 C# Events

---

實戰重構：從緊密耦合到鬆散耦合

✅ 重構案例一：RPG 角色升級系統重生

重構策略：把單一巨大升級函數拆成事件驅動的分散式系統。

核心架構改進：

角色控制器（Character Controller）：

• 只負責角色核心狀態管理（等級、經驗值、屬性）
• 定義清楚的事件介面：OnLevelUp、OnExperienceGained、OnStatsChanged
• 經驗值達到升級條件時，觸發升級事件並傳遞相關資料

UI 回應系統（UI Response System）：

• 專門的 UI 管理器監聽角色事件
• 包含等級顯示更新器、經驗條動畫控制器、屬性面板刷新器
• 每個 UI 組件都可以獨立開發測試

音效回饋系統（Audio Feedback System）：

• 獨立的音效管理器處理所有升級相關音效
• 根據升級資料動態選擇音效（如連續升級時的特殊音效）
• 支援音效的動態載入和卸載

成就檢查系統（Achievement System）：

• 監聽角色狀態變化事件
• 獨立檢查各種成就條件
• 可以輕鬆新增成就類型而不影響核心邏輯

重構效果：

• 原本 300 行的升級函數縮成 20 行
• 新增功能不用改核心角色邏輯
• 可以獨立測試每個子系統
• 支援執行時動態開啟/關閉某些回饋功能

✅ 重構案例二：MMORPG 公會戰的優雅解法

重構思路：建立中央事件系統，讓所有子系統都透過事件溝通。

新架構設計：

公會戰管理器（Guild War Manager）：

• 只負責戰爭狀態管理和規則執行
• 定義戰爭相關的所有事件：開始、結束、階段變化、勝負決定等
• 不用了解任何具體子系統實作

玩家通知系統（Player Notification System）：

• 監聽戰爭事件，向相關玩家推送通知
• 根據玩家類型（參戰者、觀戰者、其他玩家）發送不同通知
• 支援多種通知方式（UI 彈窗、聊天訊息、推送通知）

戰場管理系統（Battlefield Management System）：

• 處理玩家傳送、地圖載入、技能啟用等戰場相關邏輯
• 監聽戰爭階段變化事件，動態調整戰場環境
• 獨立管理戰場特殊規則和限制

資料統計系統（Statistics System）：

• 即時記錄戰爭資料和玩家表現
• 為排行榜、回放系統、資料分析提供支援
• 可以輕鬆擴展新的統計維度

架構優勢：

• 公會戰管理器變得簡潔清楚，只處理核心邏輯
• 新增功能（如直播、錄製、新通知方式）不用改核心戰爭邏輯
• 可以根據不同伺服器設定動態開啟/關閉某些功能
• 支援 A/B 測試不同戰爭機制

✅ 老虎機系統的完美改造

重構目標：把複雜的獲獎處理邏輯分解成獨立、可設定的子系統。

新系統架構：

老虎機核心引擎（Slot Core Engine）：

• 專注遊戲核心邏輯：旋轉、停止、結果計算
• 定義獲獎事件：OnWinAchieved、OnJackpotHit、OnBonusTriggered
• 不涉及任何 UI、音效或行銷邏輯

獎勵發放系統（Reward Distribution System）：

• 監聽獲獎事件，處理金幣發放和 VIP 經驗更新
• 支援不同獎勵倍數和加成計算
• 處理防作弊檢查和異常獲獎攔截

回饋效果系統（Feedback Effect System）：

• 統一管理所有視覺和聽覺回饋
• 根據獲獎金額和類型選擇對應特效組合
• 支援自訂特效序列和組合效果

行銷活動系統（Marketing Campaign System）：

• 監聽遊戲事件，觸發相應行銷活動
• 處理分享獎勵、首勝獎勵、連勝加成等
• 可以獨立設定更新，不影響遊戲核心

重構成果：

• 核心遊戲邏輯與行銷功能完全解耦
• 支援熱更新行銷活動而不影響遊戲穩定性
• 可以為不同地區設定不同回饋效果
• A/B 測試新功能時不用改核心程式碼

---

進階應用：打造企業級遊戲架構

🏗️ 全域事件系統設計

大型遊戲專案中，通常需要全域事件管理系統：

事件匯流排（Event Bus）架構：

• 中央化的事件註冊和分發系統
• 支援事件優先級和條件過濾
• 提供事件生命週期管理（延遲觸發、重複觸發、自動取消）
• 具備完整除錯和日誌功能

事件分類管理：

• 遊戲邏輯事件：角色狀態、戰鬥結果、關卡進度
• UI 互動事件：按鈕點擊、面板開關、輸入驗證
• 系統事件：網路連接、資源載入、錯誤處理
• 分析事件：使用者行為、效能指標、商業資料

🎯 模組化事件設計

按功能模組劃分事件：

• 玩家模組：等級變化、技能學習、裝備更換
• 社交模組：好友申請、聊天訊息、公會活動
• 經濟模組：貨幣變化、商店購買、市場交易
• 戰鬥模組：傷害計算、技能施放、戰鬥結束

事件資料標準化：

• 定義統一事件資料格式
• 包含時間戳記、事件源、目標物件、相關資料
• 支援事件序列化和持久化
• 便於事件回放和分析

🔄 事件驅動的狀態機

遊戲狀態管理：

• 用事件驅動狀態機管理遊戲不同階段
• 每個狀態只監聽相關事件
• 狀態轉換透過事件觸發，邏輯清楚
• 支援狀態嵌套和並行

AI 行為系統：

• NPC 行為透過事件觸發
• 支援複雜行為鏈和條件判斷
• 可以動態新增新行為模式
• 便於除錯和優化 AI 表現

---

性能優化與最佳實踐

⚡ 效能優化技巧

1. 事件頻率控制

問題：某些事件（如位置更新、血量變化）觸發頻率太高。

解決方案：

• 用事件聚合：把短時間內多個相似事件合併
• 實作事件節流：限制事件最大觸發頻率
• 用緩衝機制：延遲觸發非緊急事件

2. 記憶體管理優化

常見陷阱：

• 忘記取消事件訂閱導致記憶體洩漏
• 事件參數包含大型物件參考
• 匿名函數導致額外記憶體分配

最佳實踐：

• 在 OnEnable/OnDisable 管理事件訂閱
• 用物件池技術重用事件資料物件
• 避免在事件回呼中建立臨時物件

3. 除錯和監控工具

開發期間的除錯支援：

• 事件觸發的視覺化顯示
• 事件呼叫鏈追蹤功能
• 事件效能即時監控
• 未處理事件警告機制

⚠️ 常見陷阱和解決方案

1. 循環依賴問題

問題場景：A 系統監聽 B 系統事件，B 系統又監聽 A 系統事件，形成循環。

解決方法：

• 建立清楚的事件流向圖
• 用中介者模式避免直接循環依賴
• 實作事件深度限制，防止無限循環

2. 事件順序依賴

問題場景：某些功能要求事件按特定順序處理，但觀察者模式不保證順序。

解決方法：

• 用事件優先級系統
• 實作事件階段化處理
• 有順序要求的操作用回呼鏈而非事件

3. 異常處理

問題場景：某個事件監聽器拋出例外，影響其他監聽器執行。

解決方法：

• 在事件分發器加入例外捕獲
• 為每個監聽器提供獨立例外處理
• 實作事件處理容錯機制

---

總結與學習資源推薦

🎯 關鍵要點回顧

這篇文章深入探討了觀察者模式在 Unity 遊戲開發中的應用：

1. 核心價值：把一對多的緊密耦合關係轉成鬆散耦合的事件驅動架構
2. 實作方式：Unity Events 適合快速原型，C# Events 適合正式開發
3. 應用場景：角色系統、UI 管理、遊戲狀態、AI 行為等各方面
4. 架構設計：事件匯流排、模組化事件、狀態驅動等企業級模式
5. 效能優化：頻率控制、記憶體管理、除錯監控等實戰技巧

觀察者模式不只是設計模式，更是思維方式。它教我們如何構建可維護、可擴展、可測試的遊戲架構。

🚀 進階學習資源

如果想深入學習更多遊戲開發的設計模式和架構技巧，強烈推薦以下兩門課程：

📖 Programming Design Patterns For Unity: Write Better Code

這門課程深入講解在 Unity 開發中最實用的設計模式，包括：

• 觀察者模式的進階應用
• 單例模式的正確使用方式
• 工廠模式在遊戲物件建立中的應用
• 狀態機模式在遊戲邏輯中的實作

每個模式都有完整實戰案例和重構範例，非常適合想提升程式碼品質的 Unity 開發者。

📖 Unity C# Scripting Intermediate - Upgrade Your C# Skills

這門課程專注於提升 C# 程式設計技能，幫你掌握中級開發者必備技能：

• 升級 C# 腳本技能：從基礎語法到進階應用的完整提升
• 實作不同的資料結構：學會選擇和使用最適合的資料結構來優化遊戲效能
• 向量數學的學習與實作：掌握遊戲開發中不可或缺的數學基礎
• 精通物件池技術：透過實例學會優化記憶體使用和效能
• 四元數的清晰概念：徹底理解遊戲中旋轉計算的核心
• 物件導向程式設計精進：建立正確的 OOP 思維和設計模式基礎

這兩門課程相輔相成，能讓你從程式設計新手變成有架構思維的資深開發者。

💡 實踐建議

掌握觀察者模式需要大量實踐。建議：

1. 從小專案開始：在簡單遊戲原型中嘗試用事件系統
2. 重構現有程式碼：找到專案中緊密耦合的程式碼，試著用觀察者模式重構
3. 建立個人範本：整理出適合自己開發習慣的事件系統範本
4. 參與團隊討論：跟同事分享觀察者模式應用經驗
5. 持續學習：關注遊戲開發社群最新架構趨勢

記住，好架構不是一次到位，而是在不斷實踐和重構中逐漸完善。觀察者模式提供強大工具，但怎麼用它解決實際問題，還需要在實戰中不斷探索。

希望這篇文章能幫助你在遊戲開發路上寫出更優雅、更好維護的程式碼！

---

🔥 想要更多遊戲開發技巧？記得關注我們後續文章，會繼續分享更多實用的程式設計模式和 Unity 開發經驗！