【總結】遊戲框架與架構設計（Unity爲例）

使用框架開發遊戲

 

優勢：耦合性低，重用性高，部署快，可維護性高，方便管理。提升開發效率，下降開發難度

缺點：增長了系統結構和實現的複雜性，須要額外花費精力維護，不適合小型程序，易影響運行效率

 

常見框架

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。 簡介

 

還有更多優秀框架能夠在GitHub中找到~