從混亂的 UI 程式碼到清晰的架構分層

📚 目錄

1. 前言：UI 架構選擇的困惑與重要性
2. 為什麼 UI 和遊戲邏輯混在一起是災難？
3. MVC 模式：經典的三層分離
4. MVP 模式：更適合 Unity 的選擇
5. 實戰比較：老虎機系統的兩種實作
6. 選擇指南：什麼時候用哪種模式
7. 總結與學習資源推薦

前言：UI 架構選擇的困惑與重要性

在我三年的遊戲前端工程師經驗中，UI 架構設計絕對是最容易被忽視，但又最影響後期維護的關鍵因素。特別是在 Unity 開發中，很多工程師會把 UI 邏輯和遊戲邏輯混在一起寫，短期看起來開發很快，長期卻是維護噩夢。

記得剛進公司試用期時，主管給我的第一個任務是開發一個符合 MVC 架構的踩地雷遊戲。當時我對 MVC 只有理論認識，以為就是把程式碼分成三個檔案就搞定了。結果做出來的 View 還是在監聽 Model、Controller 還是在直接操作 UI 組件，根本不是真正的 MVC。主管看了搖搖頭，讓我重新研究什麼是「真正的架構分離」。

那次經驗讓我深刻體會到：架構模式不是為了符合某個名詞定義，而是為了解決實際的開發痛點。後來做老虎機遊戲時，我把所有邏輯都寫在一個巨大的 UI 控制器裡：旋轉邏輯、獎勵計算、UI 更新、音效播放...全部混在一起。結果策劃要調整獎勵公式時，我要在 UI 程式碼裡找；美術要換旋轉動畫時，我要在遊戲邏輯裡改。完全是一團亂。

後來真正學會 MVC 和 MVP 模式，整個開發世界都變得清晰了。今天想分享這兩種 UI 架構模式的實戰比較，幫你選出最適合 Unity 開發的方案。

為什麼 UI 和遊戲邏輯混在一起是災難？

🚨 典型的災難現場

想像你在開發一個老虎機遊戲，最直觀的做法就是把所有邏輯都寫在 UI 控制器裡：

一個 SlotMachineUI 類別包辦一切：

• 處理旋轉按鈕點擊
• 計算旋轉結果和獎勵
• 更新金幣顯示
• 播放旋轉動畫
• 顯示獲獎特效
• 儲存玩家資料

看起來很直接，實際上是災難的開始。

🎭 真實專案災難案例

在我參與的一個老虎機專案中，UI 控制器最後變成了 800 行的怪物：

當策劃說「獎勵公式要調整」：我要在 UI 程式碼裡找到獎勵計算邏輯，但它跟 UI 更新邏輯混在一起，改一個地方可能影響到 UI 顯示。

當美術說「旋轉動畫要重做」：動畫邏輯跟遊戲邏輯綁在一起，換個動畫可能會影響到獎勵計算的時機。

當要做 A/B 測試不同的獎勵機制：根本沒辦法單獨測試遊戲邏輯，因為它跟 UI 邏輯完全混在一起。

🎰 問題的根源

職責不清：一個類別同時負責遊戲規則、UI 顯示、用戶互動

依賴混亂：UI 組件和遊戲邏輯互相依賴，牽一髮動全身

測試困難：無法獨立測試遊戲邏輯或 UI 邏輯

擴展性差：新增功能時需要修改巨大的單一檔案

這就是為什麼我們需要 MVC 或 MVP 模式來解決這些問題。

MVC 模式：經典的三層分離

🎯 MVC 的核心概念

MVC（Model-View-Controller）是最經典的 UI 架構模式，把系統分成三個層次：

Model（模型）：負責遊戲邏輯和資料管理

View（視圖）：負責 UI 顯示和渲染

Controller（控制器）：負責處理用戶輸入和協調 Model、View

🔧 老虎機的 MVC 設計

SlotMachineModel：

• 管理玩家金幣、旋轉結果、獎勵計算
• 不知道任何 UI 相關的東西
• 當狀態改變時通知觀察者

SlotMachineView：

• 管理所有 UI 組件的顯示
• 監聽 Model 的變化並更新顯示
• 不處理任何遊戲邏輯

SlotMachineController：

• 處理旋轉按鈕點擊
• 把用戶操作轉換成 Model 的方法調用
• 協調 Model 和 View 的互動

🎮 MVC 的運作流程

玩家點擊旋轉按鈕 → Controller 接收輸入 → Controller 調用 Model 的旋轉方法 → Model 計算結果並通知變化 → View 監聽到變化自動更新顯示

⚡ MVC 的優缺點

優點： 職責分離清楚，每個部分都有明確定義。Model 完全獨立，可以單獨測試遊戲邏輯。View 可以有多個，比如手機版和平板版 UI。

在 Unity 中的問題： View 要主動監聽 Model，但 Unity 的 UI 系統更適合被動更新。Controller 和 View 的界線在 Unity 中不夠清楚。Unity 的事件系統讓 View 自己處理用戶輸入更自然。

MVP 模式：更適合 Unity 的選擇

🎯 MVP 的核心改進

MVP（Model-View-Presenter）是 MVC 的進化版，更適合 Unity 的開發方式：

Model（模型）：跟 MVC 一樣，負責遊戲邏輯

View（視圖）：變成被動的，只負責顯示，不主動監聽

Presenter（展示器）：負責協調 Model 和 View，處理所有的更新邏輯

🔧 老虎機的 MVP 設計

SlotMachineModel：

• 純粹的遊戲邏輯，計算旋轉結果、獎勵、金幣變化
• 提供公開方法讓 Presenter 調用
• 當有變化時發送事件通知

SlotMachineView：

• Unity 的 Canvas 和 UI 組件
• 只有簡單的顯示方法，不處理任何邏輯
• 用戶輸入透過 Unity 的事件系統處理

SlotMachinePresenter：

• 監聽 Model 的變化，主動更新 View
• 處理 View 的用戶輸入事件
• 把用戶操作轉換成 Model 的方法調用

🎮 MVP 的運作流程

玩家點擊旋轉按鈕 → View 的按鈕事件被 Presenter 監聽 → Presenter 調用 Model 的旋轉方法 → Model 計算結果並發送事件 → Presenter 接收事件並更新 View

⚡ MVP 的優勢

更符合 Unity 開發習慣：View 就是 Unity 的 UI 系統，Presenter 是 MonoBehaviour

責任分配更清楚：Presenter 明確負責協調，View 完全被動

測試更容易：可以 Mock View 來測試 Presenter 邏輯

擴展性更好：新增功能時主要修改 Presenter，不影響 Model 和 View

實戰比較：老虎機系統的兩種實作

🎯 需求場景

我們要實作一個老虎機系統，包含：

• 旋轉按鈕和自動旋轉功能
• 金幣顯示和下注金額調整
• 旋轉結果顯示和獲獎動畫
• 音效回饋和特效播放

🔧 MVC 實作方式

MVC 的挑戰： 在 Unity 中，View 要主動監聽 Model 的變化比較麻煩。UI 組件需要直接訂閱 Model 的事件，這讓 View 變得不夠「純粹」。

當有多個 UI 元素需要顯示同一個資料時，每個都要單獨訂閱事件，容易忘記或重複訂閱。

Controller 的定位尷尬，因為 Unity 的 Button 組件已經有自己的事件系統，額外加一層 Controller 反而複雜化。

🔧 MVP 實作方式

MVP 的優雅： Presenter 作為 MonoBehaviour，可以輕鬆在 Inspector 中設定對 Model 和 View 組件的引用。

View 完全被動，所有的更新都通過 Presenter，邏輯集中易於管理。

用戶輸入透過 UnityEvent 直接綁定到 Presenter 的方法，符合 Unity 的使用習慣。

🎮 實際程式碼結構比較

MVC 結構：

SlotMachineModel (遊戲邏輯)
SlotMachineView (UI + 事件監聽)
SlotMachineController (輸入處理)

MVP 結構：

SlotMachineModel (純遊戲邏輯)
SlotMachineView (純 UI 顯示)
SlotMachinePresenter (邏輯協調)

MVP 的結構更清晰，每個部分的職責更明確。

選擇指南：什麼時候用哪種模式

🎯 選擇 MVP 的時機

Unity 專案：MVP 更符合 Unity 的開發方式和組件系統 UI 密集型遊戲：老虎機、卡牌、經營類遊戲等有複雜 UI 的遊戲 需要多平台適配：可以輕鬆替換不同的 View 實作 團隊協作開發：UI 設計師、遊戲設計師、工程師可以並行工作

🎯 選擇 MVC 的時機

Web 開發背景團隊：如果團隊更熟悉傳統的 MVC 模式 簡單的 UI 系統：UI 邏輯不複雜，不需要太多協調 已有 MVC 框架：專案已經在使用某個 MVC 框架

🎮 實戰建議

新手開發者：建議從 MVP 開始，概念更簡單，更適合 Unity 小型專案：MVP 的 Presenter 可以簡化，不用完全按照模式來 大型專案：MVP 配合依賴注入框架，可以建立很靈活的架構

📱 不同遊戲類型的推薦

老虎機/博弈遊戲：MVP，UI 邏輯複雜，需要清晰的分層 動作遊戲：簡化的 MVP，重點在遊戲邏輯而非 UI 策略遊戲：MVP，複雜的 UI 狀態管理 休閒遊戲：根據 UI 複雜度決定，可以用簡化版本

總結與學習資源推薦

🎯 核心要點回顧

MVC 和 MVP 都是為了解決同一個問題：如何優雅地分離 UI 邏輯和遊戲邏輯。

MVC 的價值：經典模式，概念清晰，適合有 Web 開發背景的團隊。

MVP 的優勢：更適合 Unity 開發，Presenter 的職責更明確，測試和維護都更容易。

選擇建議：Unity 專案建議優先考慮 MVP，特別是 UI 邏輯複雜的遊戲。

重要的不是嚴格遵循某個模式，而是要有分離關注點的意識。讓遊戲邏輯、UI 邏輯、用戶輸入處理各司其職，這樣的程式碼才容易維護和擴展。

💡 實踐建議

架構設計需要循序漸進。從簡單的職責分離開始，把遊戲邏輯從 UI 程式碼中抽離出來。再逐步引入 Presenter 來協調不同部分。

不要為了用模式而用模式，要根據專案複雜度選擇合適的架構深度。小專案可以用簡化版，大專案再考慮完整的模式實作。

記住，好的架構是為了讓開發更輕鬆，不是為了炫技。如果架構讓開發變得複雜，那就是過度設計了。

🚀 進階學習資源

目前針對遊戲開發的設計模式的線上資源不多，讀相關的書又略顯枯燥。如果想深入學習更多遊戲開發的設計模式和架構技巧，強烈推薦以下兩門課程：

📖 Programming Design Patterns For Unity: Write Better Code

這門課程深入講解在 Unity 開發中最實用的設計模式，包括觀察者模式的進階應用、單例模式的正確使用方式、工廠模式在遊戲物件建立中的應用、狀態機模式在遊戲邏輯中的實作。每個模式都有完整實戰案例和重構範例，非常適合想提升程式碼品質的 Unity 開發者。

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

這門課程專注於提升 C# 程式設計技能，幫你掌握中級開發者必備技能：升級 C# 腳本技能、實作不同的資料結構、向量數學的學習與實作、精通物件池技術、四元數的清晰概念、物件導向程式設計精進。

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

希望這篇文章能幫助你選對 UI 架構，寫出更優雅易維護的 Unity 程式碼！

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