為什么在游戲開(kāi)發(fā)中不使用MVC

這篇文章將為大家詳細(xì)講解有關(guān)為什么在游戲開(kāi)發(fā)中不使用MVC，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

首先，我是用MVC的，在畢業(yè)早期開(kāi)發(fā)應(yīng)用軟件類程序，對(duì)不同數(shù)據(jù)的不同展示方式MVC是很好的設(shè)計(jì)。或者說(shuō)，一個(gè)M（數(shù)據(jù)），多種V（展示），是應(yīng)用軟件的常見(jiàn)展示方式，很適用MVC。大家在看Design pattern介紹MVC的時(shí)候，常用的例子，就是一個(gè)數(shù)據(jù)，即要餅狀圖展示，又要柱狀圖展示。

后來(lái)，轉(zhuǎn)行做頁(yè)游，覺(jué)得當(dāng)時(shí)的項(xiàng)目，完全沒(méi)有什么設(shè)計(jì)，胡亂堆砌，亂成一團(tuán)，想起了MVC等設(shè)計(jì)模式，并且，還有很多人推薦的PureMVC，Robotleg等類MVC框架，并使用了依賴注入等模式，學(xué)習(xí)了demo之后，覺(jué)得很好地解決了游戲設(shè)計(jì)問(wèn)題。在跳槽后，在新的項(xiàng)目中，已經(jīng)使用了robotleg，我進(jìn)去后就很開(kāi)心，開(kāi)心地使用。真實(shí)地開(kāi)發(fā)一段時(shí)間以后，我開(kāi)始感覺(jué)到MVC或者說(shuō)這類框架的問(wèn)題（在和同事的討論中，也得到了牛逼同事很多提點(diǎn)），或者說(shuō)，是使用者帶來(lái)的問(wèn)題：

1，代碼繁冗，當(dāng)你閱讀別人的代碼，一個(gè)很簡(jiǎn)單的邏輯，被封裝了多次，需要在多個(gè)代碼文件中索引，閱讀效率極低。代碼文件分散，一些很簡(jiǎn)單的邏輯，例如按鈕點(diǎn)擊，都做了多層封裝。

2，不太專業(yè)的某些程序的惰性，導(dǎo)致他們并不是真正理解MVC或者說(shuō)這些框架的原理，他們的目標(biāo)只是，把功能搞出來(lái)。他們要么繞過(guò)框架，穿插了很多調(diào)用，要么整體copy別人的一個(gè)功能，去掉邏輯，留下骨架，然后填充自己的邏輯，也不管這個(gè)骨架是否適用。這樣的人，大大增加了項(xiàng)目的混亂，leader要做到充分的代碼review，去除這些問(wèn)題，在開(kāi)發(fā)進(jìn)度吃緊，每周都要出版本的情況下，是不可能的。這些快速堆出功能的程序員，反而得到策劃等非技術(shù)人員的贊賞。而認(rèn)真處理，把每一塊都做好，但是慢一點(diǎn)的程序，反而不受夸獎(jiǎng)，這導(dǎo)致了劣幣驅(qū)逐良幣。我相信，除了極少數(shù)精英團(tuán)隊(duì)，很多團(tuán)隊(duì)都有這樣的問(wèn)題。

3，這些設(shè)計(jì)和框架，被濫用。比如MVC也許適用于UI部分的設(shè)計(jì)，但是，他是否適用一個(gè)戰(zhàn)斗模塊呢？他是否適用一個(gè)劇情模塊呢？有些團(tuán)隊(duì)，機(jī)械地運(yùn)用某些框架，并不根據(jù)需求去思考，認(rèn)為某個(gè)東西是好的，就到處使用。

當(dāng)一個(gè)項(xiàng)目規(guī)模增長(zhǎng)，人員難以保證精英，積累了大量的需求變更，運(yùn)營(yíng)期間，需要快速的迭代。這種繁雜冗余的框架式設(shè)計(jì)，會(huì)導(dǎo)致代碼難以維護(hù)。有時(shí)候，并不是某個(gè)框架不夠好，更多的是，我們沒(méi)有仔細(xì)理清它的適用范圍，也難以保證規(guī)范從頭到尾的堅(jiān)定執(zhí)行。并留下大量過(guò)分設(shè)計(jì)的繁雜代碼，一個(gè)一百行，幾個(gè)funtion就能解決的問(wèn)題，被包裝成了多個(gè)class，層層調(diào)用，寫(xiě)了幾大百行，邏輯處處分散。

那么，到底是某個(gè)框架，或者設(shè)計(jì)模式不行，還是我們使用得不夠好呢？

我們回到最初，仔細(xì)考慮，MVC解決的核心問(wèn)題是，一個(gè)M，多個(gè)V，那么，在游戲領(lǐng)域，這樣的需求多嗎？是強(qiáng)需求嗎？我們到底應(yīng)該根據(jù)需求來(lái)設(shè)計(jì)框架，還是應(yīng)該根據(jù)框架來(lái)填充需求？一個(gè)框架，一套設(shè)計(jì)，適用不同的游戲，不同的邏輯嗎？

我認(rèn)真地考慮這塊問(wèn)題，發(fā)現(xiàn)很多教程，文章，他們介紹MVC，MVVM，介紹各種框架，包括uframe，StrangeIoC等，都缺少了思考和提問(wèn)：

• 這個(gè)框架適用什么需求？解決了什么問(wèn)題？

• 在什么情況下我該用，什么情況不該用？他帶來(lái)了什么問(wèn)題？

• 是否適合我的項(xiàng)目，我的團(tuán)隊(duì)？

• 我是應(yīng)該項(xiàng)目整體使用，還是某些局部的需求使用呢？

等等問(wèn)題，才是我們?cè)搯?wèn)的關(guān)鍵。

我們游戲領(lǐng)域的技術(shù)，特別是游戲的框架，受到了太多應(yīng)用軟件，web開(kāi)發(fā)，app開(kāi)發(fā)的影響，但是，這些模式并不適用我們啊！正式因?yàn)閣eb，app這些領(lǐng)域的通用性，需求的固定性（相對(duì)游戲開(kāi)發(fā)而言），他們才會(huì)誕生出如此多的框架，模式，并且在技術(shù)領(lǐng)域，發(fā)出了更多的聲音。出現(xiàn)了看似高級(jí)的設(shè)計(jì)方式。并且，web，app的項(xiàng)目周期，以及后續(xù)的維護(hù)周期是很長(zhǎng)的，少則三兩年，多則十幾年，確實(shí)必須要謹(jǐn)慎設(shè)計(jì)。但是，我們游戲，特別是現(xiàn)在手游的生命周期又有多長(zhǎng)呢？當(dāng)需求不同，考慮問(wèn)題的方式，解決問(wèn)題的方式，應(yīng)該做些改變。

游戲開(kāi)發(fā)，和web，app開(kāi)發(fā)，能歸為同一個(gè)隱喻嗎？ 那么我們問(wèn)問(wèn)自己：

• TDD適用我們游戲前端開(kāi)發(fā)嗎？

• WinForm的數(shù)據(jù)綁定，是適合我們游戲開(kāi)發(fā)的嗎？

• 幾十個(gè)設(shè)計(jì)模式，有幾個(gè)能適用我們游戲開(kāi)發(fā)的呢？分別對(duì)應(yīng)什么應(yīng)用場(chǎng)景呢？

• 用Design pattern的目的，到底是design，還是去解決具體的問(wèn)題？

當(dāng)我們?nèi)プ分鸶碌脑O(shè)計(jì)，更酷的框架，我們有了解他們解決的問(wèn)題嗎？我們有自己了解過(guò)他的原理嗎？到底在我們自己的項(xiàng)目中，他能解決什么問(wèn)題？我們有仔細(xì)思考過(guò)他在我們游戲開(kāi)發(fā)的整個(gè)生命周期，會(huì)給我們帶來(lái)什么嗎？

最近，因?yàn)槭赝蠕h的一個(gè)分享，ECS開(kāi)始火了起來(lái)。有個(gè)群里看到說(shuō)，我們下個(gè)項(xiàng)目要上ECS了，問(wèn)是什么類型，答不知道，但是ECS這種先進(jìn)框架，肯定要用。我只能說(shuō)汗~~~

靜下心來(lái)，我也追求過(guò)最新的技術(shù)，最新的框架。但是，當(dāng)我們真心開(kāi)始做一個(gè)項(xiàng)目，去解決一些問(wèn)題的時(shí)候，我們需要審慎。

最終，我們要回到需求和問(wèn)題，ECS，核心是為了解決網(wǎng)絡(luò)同步中預(yù)測(cè)和預(yù)測(cè)失效的狀態(tài)回滾問(wèn)題。如果你不是需要解決這類問(wèn)題，你確定需要上ECS？一個(gè)回合制游戲，確定需要ECS？UI寫(xiě)法從MVC改ECS？

關(guān)于為什么在游戲開(kāi)發(fā)中不使用MVC就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。