游戲的核心

模塊化（Modular）、可編輯（Editable）、可被測試化（Debuggable）

• 模塊化自不用多說，減少耦合性的根本。

• 可編輯則要求，一個項目中的所有開發(fā)者，甚至所有成員都應該可以對項目內容進行編輯or更改。

一、模塊化

系統(tǒng)之間不要直連在一起

模塊化要求我們不能讓我們的系統(tǒng)之間直接聯(lián)系在一起，比如如果你有一個庫存管理系統(tǒng)需要和游戲中的其他系統(tǒng)通信，但是我們又不想讓他們之間產(chǎn)生一個強連接，因為這會讓我們的系統(tǒng)非常不靈活，同時重新集成的時候會非常難受。

干凈的游戲場景

游戲場景中也應該盡可能干凈，場景直接不會傳輸任何數(shù)據(jù)， 這樣每次加載或卸載場景的時候開銷將非常小，這樣就可以使每個場景都只做單一職責，防止你在場景之間打洞傳輸。

預制體要獨立工作

每個預制體的功能要抽象到一定程度，這樣可以盡最大化減少沖突

組件化

unity引擎的最大優(yōu)勢，就是可以將每一件事劃分到一個具體的組件程度，做且僅作一件事。

二、可編輯化

基于數(shù)據(jù)的開發(fā)

盡可能讓我們的項目以數(shù)據(jù)驅動，這可以讓我們的游戲隨時進行更改，甚至在運行時。

不要每次都用代碼改變程序、高集成度的設計

可以用做很多小組件的模式來制作游戲，這樣不但可以快速開發(fā)，同時可以大幅度減少測試的成本

運行時更新游戲

更好隨時隨地的調試你的游戲

三、可調試化

最好又相應的視圖來做調試工作。

永遠不會修復你沒有遇到的錯誤

對于bug來說：

Scriptable Objects 基礎

• 可視化版Unity類

• 類似于Mono behaviour，但是沒有transform、GameObject這種原生組件（最終繼承自Object）

• 以asset的方式存儲

Scriptable Objects用例

• 游戲配置文件（雖然視頻里說了很多大型項目都在用這個來配置，但是不知道為什么國內都不用這個，從原生大小看確實比配置文件大）

• 背包系統(tǒng)的數(shù)據(jù)封裝

• 敵人狀態(tài)？（還沒實際用過,倒是做過狀態(tài)機）

• 音頻管理（一個asset中存一堆，然后獲取，類似工廠）

架構

別再濫用單例了?。。?！

P.S ：終于有看到有人講單例壞的地方了，下次用這個跟人battle。

從小到指甲邊緣起皮，大到核戰(zhàn)爭，一切都是由于單例引起的?。?/p>

單例模式的優(yōu)點

• 任何地方，拿到任何東西

• 持久化存在

• 很簡單的能理解

• 很“簡單”來構建項目（前人挖坑，后人遭殃）

缺點

• 剛性連接，每個系統(tǒng)沒法獨立存在

• 缺少多態(tài)性

• 測試起來非常困難

• 依賴噩夢，我們不想要一些東西的時候，它依然會存在

解決方案

• 減少全局的引用

• 控制反轉

模塊化數(shù)據(jù)

主要用于減少全局查詢數(shù)據(jù)的操作行為

我們以一個敵人的實體舉例

• xxxManager.Instance.MoveSpeed

以這種方式獲得變量的話會造成硬連接，同時非常依賴對應的manager被加載進來。

• 使用SO直接進行配置

這樣會把一個敵人的所有信息配置到一個文件中，造成一個巨大的冗余，同時擴展性與模塊性會變得很差。

解決上述問題的方案，就是：

Scriptable Object 變體

PS：使用 [CreateAssetMenu] 以相同的SO腳本創(chuàng)建出的不同Asset。

這樣就可以用這些變體來做對象的數(shù)據(jù)管理

但是這種每個變量都創(chuàng)建一次的方式非常麻煩，所以我們在上層又進行一次封裝

所以我們最終把DumbEnemy類做一些修改

再用一個實例來解釋這個，就是上圖

一個中間件通知player預制體受傷了，同時，對UI界面通知更新狀態(tài)，而不用讓玩家對象直接引用UI界面做更改。音頻界面同理。

這樣就可以讓這些數(shù)據(jù)以某種持久化的形式，加載在內存中，使得你在運行時也可以調試！