使用架構開發遊戲
優點：耦合性低，重用性高，部署快，可維護性高，友善管理。提高開發效率，降低開發難度
缺點：增加了系統結構和實作的複雜性，需要額外花費精力維護，不适合小型程式，易影響運作效率
常見架構
MVC
- 表現層（View）：遊戲畫面。UI
- 邏輯層（Controller）：資料接口，操作控制，AI
- 資料層（Model）：資料儲存，圖檔、聲音等資源
我的SFramework中，View層是單獨的，Model我放在基類中，Controller則在派生類，實作了MVC的分離（如果要重構的話我可能會用組合代替繼承）
舉例： PlayerHUD+PlayerCtrl（PlayerYuka）+IPlayer
注意圖中的調用關系
MVC
優點：實作了階層化設計，是一個基礎常用的架構
缺點：MVC如果沒有用好，容易出現某一層過重的現象（如View）。MVC更适合橫向鋪量的項目。遊戲（非UI部分）則不太合适。
MVVM
MVVM 模式将MVP中的 Presenter 改名為 ViewModel，基本上與 MVP 模式完全一緻。
MVP中，View 與 Model 不發生聯系，都通過 Presenter 傳遞。
唯一的差別是，它采用雙向綁定（data-binding）：View的變動，自動反映在 ViewModel
SFramework中，View不能直接修改Model，他們之間通過事件通信
uFrame&MVVM
uFrame架構模仿了MVVM這種架構模式（事實上并不包含Model部分，且多出了Controller部分）
在uFrame中，使用Element這個概念将業務分拆成三部分：
- ViewModel：儲存遊戲中對象的資料結構，例如血量、經驗、金錢等等。
- Controller：處理遊戲業務邏輯。例如加血、減血之類的。
- View：遊戲世界中可以見的對象，和ViewModel綁定，以在遊戲中進行展現。
uFrame是可視化的，功能似乎友善實用，但是由于收費，我沒有深入過，不便過多評價
PureMVC
pureMVC架構引入了多種設計模式、消息機制（使用觀察者模式，釋出/訂閱模式）來解耦各個子產品
我曾使用過PureMVC架構開發過一個demo，它通過ApplicationFacade，Mediator，Proxy，Command架設項目，由SendNotification()進行互動
優點：強解耦，實作了MVC高度分離
缺點：增加代碼量，降低執行效率，函數調用層次較深，容易找不到消息發送源。Facade作為單例接口，本應管理MVC，Model、View、Controller卻提供了 getInstance()方法，讓人奇怪
MVCS
架構與架構
StrangeIOC支援依賴注入（即控制反轉（Inversion of Control，縮寫為IoC）），可以有效降低耦合度
但是IOC複雜而緩慢，而且是基于Mono的，是以我沒有選用
ECS
Entity Component System
Unity本身的元件開發就是ECS架構，ECS很适合遊戲開發，在遊戲引擎中比較常見，谷歌曾在Github上釋出了一個名叫Entitas的ECS架構，下面我們就來介紹
- Entity就是隻有資料的GameObject對象，不包括方法
- 每一個Entity擁有Component元件，負責Entity資料處理
- Group是擁有相同Component的Entity集合
- Context就是建立銷毀Entity的工廠
- Collector收集器提供了簡單的方法來處理Group中Entity變化的反應。
ECS的教程現在還比較少，詳細的我也不友善介紹了，感興趣的可以在這些架構中選一個深入
其他
TRAP架構
TRAP是一個學長制作的單機遊戲，他在這個遊戲中使用了自己原創的架構，SFramework也從中參考了不少設計思路。TRAP有分UI部分和遊戲部分，封裝了Unity事件和輸入控制，使用單例、Manager和NotificationCenter進行消息傳輸，不過目前未開源
GameFramework
基于 Unity 5.3+ 引擎的遊戲架構，國人原創，開源
詳情可以去官網檢視 簡介
SFramework
Sunset Game 制作組自主設計研發的一款Unity通用遊戲架構，設計思想類似MVC+ECS。
遊戲架構 SFramework
不限于3D-ARPG遊戲的萬能架構 Unity-Framework
- 獨立設計開發的原創遊戲架構，持續更新中
- 控制遊戲生命周期，架構盡量不繼承Monobehavior
- 基于單例模式，外觀模式，橋接模式等設計模式
- 可使用PhysX實體引擎，動畫幀事件等基于Monobehavior的功能