請問untiy開發遊戲使用什麼架構比較合適？

01-13

初學u3d請問給位大神，u3d做遊戲開發用什麼架構比較合適？之前的遊戲用的ECS，u3d用什麼比較合適呢？

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

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

這段話適用於遊戲開發。

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

0.關注點分離原則

關注點分離是日常生活和生產中廣泛使用的解決複雜問題的一種系統思維方法。大體思路是,先將複雜問題做合理的分解,再分別仔細研究問題的不同側面(關注點),最後綜合各方面的結果,合成整體的解決方案

許多遊戲的對象都可以分為顯示錶現部分，邏輯處理部分，數據存儲部分。

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

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

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

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

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

/*比如王者榮耀一個英雄有很多皮膚，不可能每一個皮膚都要去寫一套邏輯代碼，我們只要將顯示部分替換*/

而邏輯和數據分離的好處是可以代碼復用減少耦合。

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

1.開放封閉原則

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

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

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

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

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

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

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

2.不信任原則

這個是最近看https://zhuanlan.zhihu.com/p/29470110 騰訊雲技術社區發表的文章後總結出來的。深有感觸。

說的很好，遊戲編程就像掃雷，你一不小心就會在某一步出錯，遊戲直接Over掉。

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

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

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

很多相關框架的答案都用了各種專業的辭彙來形容這個框架是多麼的牛逼，多麼的厲害。但是一般學了幾年程序的朋友都能摸索出來自己的框架，不會去主動去問常用框架的問題（一般想了解的話自己就去各種搜索了解了，互聯網就是技術人員的後盾嘛）。而一般問這個問題的基本都是初學者，初學者聽到答案後去各種看框架，看到中間後發現越看越看不懂。學具體寫法不如學理念，這個東西是永遠不會過時的。

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

如果對uFrame感興趣的朋友可以看看

https://zhuanlan.zhihu.com/p/21356344

前段時間也關注了這個，想找個框架學習，結果發現，沒有特別流行的框架。之前了解了一下Entitas，確實不錯，到實際要用的話，感覺還不如自己搭（主要是靈活）。

還有個國產的GameFramework，看著也不錯，但是文檔奇缺，暫時沒時間去研究。

理解unity 基於component的思想，有意識的使用這種思想去寫unity工程，至於MVC么，在unity工程中比較煩，只是我個人體會!

樓主沒有說要開發什麼樣的遊戲，也沒有說開發的規模。

就一般小的項目而言（比如跑酷、貪食蛇、橫版過關這類），U3d本身就是一個功能集成龐大且擴展性好的ECS框架，也就是說，如果一開始就能想好需要什麼樣的業務模塊、邏輯、資源，配合一個單例模式都夠你串起來所有的實現了，你甚至都不用在代碼裡面使用到消息機制。。無非就是弄好prefab、component，tag、layer這些，使用好Unity自身的所有API，基本可以實現所有的事情了（還真沒有實現不了的），除此之外還有大量的有針對性的插件可以拿來直接使用。

所謂的框架無非是為了多人協同開發、易於迭代維護、可重用之類的目的。但有時候殺雞用牛刀反而適得其反，比如一共就2-3個人開發的小遊戲，而且遊戲又不是很複雜很龐大，為了實現一個擊中掉血的效果，與其搞成事件消息，我寧願一個單例直接告訴相關的component該幹嘛就行了，搞不好debug起來還一目了然一些。

mvc，戰鬥部分自己搭可能比較好，策劃的腦洞框架有時候真不太好處理

關注下以後有了自己的心得再來看看

沒有像java一樣那樣多的框架，所有的基本都是自己寫！

初學，你就好好把功能寫了，等你需要真正弄懂了這些框架再說

腦子裡只蹦出三個大字「MVC」。至於到底怎麼做，真不知道。關注下。