什么是架構？Untiy開發游戲使用什么架構合適？

我翻開知乎查看游戲架構瀏覽，這問題沒有專門答案，歪歪斜斜的每頁上都寫著"MVC"，“MVVC”,"MVP"，“uFame架構”幾個字。橫豎想了半天，最后在一個倒影年華 博主下發現一個很好的回答：

框架是為了解決一個又一個在Web開發中所遇到的問題而誕生的。不同的框架，都是為了解決不同的問題，但是對于程序員而言，他們只是 jar包而已。框架的優缺點的評論，也完全取決于其對問題解決程度和解決方式的優雅性的評論。所以，千萬不要為了學習框架而學習框架，而是要為了解決問題 而學習框架，這才是一個程序員的正確學習之道。

這段話適用于游戲開發。

游戲題材眾多，要通用的一個架構搞定所有題材幾乎不可能。但是游戲也是軟件，有些常識性的東西可以通用的。個人認為相比于框架，更重要的是設計理念。

0.關注點分離原則

關注點分離是日常生活和生產中廣泛使用的解決復雜問題的一種系統思維方法。大體思路是,先將復雜問題做合理的分解,再分別仔細研究問題的不同側面(關注點),最后綜合各方面的結果,合成整體的解決方案
許多游戲的對象都可以分為顯示表現部分，邏輯處理部分，數據存儲部分。

比如一個MOBA游戲的角色，就要把視覺相關的內容和核心邏輯給分離開。

角色表現部分：動畫、模型顯示、相關特效、UI等美術資源和控制模型動畫播放，生命值血條變化等改變對象顯示的部分代碼。

核心邏輯部分：控制對象行為（移動、***、技能），控制對象數值變化（被擊扣血、擊殺獲得金錢），處理業務邏輯部分。

數據存儲部分：記錄玩家自身屬性、如***、血量、防御力等。

角色顯示和邏輯分開的好處一是可以讓我們的代碼清晰，出了問題能直觀的去相應的代碼塊去找問題，二是分離代碼邏輯后，如果美術資源的更新，以及策劃的更新不會影響到主要的業務邏輯代碼，這就提高了游戲的可移植性。

/比如王者榮耀一個英雄有很多皮膚，不可能每一個皮膚都要去寫一套邏輯代碼，我們只要將顯示部分替換/
而邏輯和數據分離的好處是可以代碼復用減少耦合。

/比如我們游戲中有一個玩家和一個敵方小兵的對象，雙方實際上數據是相似的，我們就可以用一個角色數據腳本存儲雙方數據，而不用寫兩遍代碼在各自的邏輯里面。同時當雙方都扣血的時候，UI血條控制腳本能直接去角色數據腳本中取資源/

1.開放封閉原則

開放封閉原則（OCP，Open Closed Principle）是所有面向對象原則的核心。軟件設計本身所追求的目標就是封裝變化、降低耦合，而開放封閉原則正是對這一目標的最直接體現。

開放封閉原則主要體現在兩個方面：

對擴展開放，意味著有新的需求或變化時，可以對現有代碼進行擴展，以適應新的情況。

對修改封閉，意味著類一旦設計完成，就可以獨立完成其工作，而不要對類進行任何修改。

游戲開發中有很多的突發事件，經常會用到監聽觀察者模式。這種又叫做響應式編程的思想。

比如一款游戲從開發到發行對一個事件的處理是由簡單到復雜的。比如游戲戰斗結束，如果在戰斗管理器里面寫具體執行的邏輯代碼，那么后期策劃逐漸提出我們要在戰斗結束的時候加入“鏡頭變化”，“加入UI變化”，加入“服務器數據請求”等需求的時候，避免我們每次都要修改已經完成的功能，我們就將戰斗結束作為一個事件發送，哪個系統關心這個事件就在各自的邏輯代碼函數注冊到這個事件中。

這種編程方式廣泛用在游戲各個功能塊中，比如場景加載模塊，當場景加載后調用加載完成事件，誰需要在加載完成后處理什么事件邏輯，自己就去注冊調用就好了。

2.不信任原則

這個是最近看騰訊云技術社區發表的文章后總結出來的。深有感觸。
說的很好，游戲編程就像掃雷，你一不小心就會在某一步出錯，游戲直接Over掉。

所以我們的編程應該步步為營，一個功能能再細化操作的就細化出來，比如一個UI管理器，就得處理UI的加載、創建、設置類型、設置層級、顯示、處理邏輯、關閉或刪除等功能。因為當后期做優化或者解決沖突，其中的每一步都可能是一個關鍵問題點。

直接利用引擎實現的部分也需要有一定的封裝，你會看到很多游戲源碼里面部分類都自己有一個Base基類。

即使這樣，以上原則也有部分游戲開發不適應，各位看官還是以自身項目情況出發巧用設計方法。

很多相關框架的答案都用了各種專業的詞匯來形容這個框架是多么的牛逼，多么的厲害。但是一般學了幾年程序的朋友都能摸索出來自己的框架，不會去主動去問常用框架的問題（一般想了解的話自己就去各種搜索了解了，互聯網就是技術人員的后盾嘛）。

而一般問這個問題的基本都是初學者，初學者聽到答案后去各種看框架，看到中間后發現越看越看不懂。學具體寫法不如學理念，這個東西是永遠不會過時的。

對于初學者來說代碼量太少了是一個大問題，自己還沒有做到一定復雜度的系統時是感受不到框架的作用的。就如同房間里面什么東西都沒有，你怎么做物品分類呢？所以先加油去寫功B能U代G碼吧，然后反復的重構你們會創造屬于自己的框架。

我翻開知乎查看游戲架構瀏覽，這問題沒有專門答案，歪歪斜斜的每頁上都寫著"MVC"，“MVVC”,"MVP"，“uFame架構”幾個字。橫豎想了半天，最后在一個倒影年華 博主下發現一個很好的回答：

框架是為了解決一個又一個在Web開發中所遇到的問題而誕生的。不同的框架，都是為了解決不同的問題，但是對于程序員而言，他們只是 jar包而已。框架的優缺點的評論，也完全取決于其對問題解決程度和解決方式的優雅性的評論。所以，千萬不要為了學習框架而學習框架，而是要為了解決問題 而學習框架，這才是一個程序員的正確學習之道。

這段話適用于游戲開發。

游戲題材眾多，要通用的一個架構搞定所有題材幾乎不可能。但是游戲也是軟件，有些常識性的東西可以通用的。個人認為相比于框架，更重要的是設計理念。