我翻開知乎檢視遊戲架構瀏覽，這問題沒有專門答案，歪歪斜斜的每頁上都寫著"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包而已。框架的優缺點的評論，也完全取決於其對問題解決程度和解決方式的優雅性的評論。所以，千萬不要為了學習框架而學習框架，而是要為了解決問題 而學習框架，這才是一個程式設計師的正確學習之道。

這段話適用於遊戲開發。

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