建站
咨詢
售后
建站咨詢
新聞中心
這篇文章將為大家詳細講解有關(guān)為什么在游戲開發(fā)中不使用MVC，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
成都創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),虞城企業(yè)網(wǎng)站建設(shè),虞城品牌網(wǎng)站建設(shè),網(wǎng)站定制,虞城網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,虞城網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。
首先，我是用MVC的，在畢業(yè)早期開發(fā)應(yīng)用軟件類程序，對不同數(shù)據(jù)的不同展示方式MVC是很好的設(shè)計?；蛘哒f，一個M（數(shù)據(jù)），多種V（展示），是應(yīng)用軟件的常見展示方式，很適用MVC。大家在看Design pattern介紹MVC的時候，常用的例子，就是一個數(shù)據(jù)，即要餅狀圖展示，又要柱狀圖展示。
后來，轉(zhuǎn)行做頁游，覺得當時的項目，完全沒有什么設(shè)計，胡亂堆砌，亂成一團，想起了MVC等設(shè)計模式，并且，還有很多人推薦的PureMVC，Robotleg等類MVC框架，并使用了依賴注入等模式，學(xué)習了demo之后，覺得很好地解決了游戲設(shè)計問題。在跳槽后，在新的項目中，已經(jīng)使用了robotleg，我進去后就很開心，開心地使用。真實地開發(fā)一段時間以后，我開始感覺到MVC或者說這類框架的問題（在和同事的討論中，也得到了牛逼同事很多提點），或者說，是使用者帶來的問題：
1，代碼繁冗，當你閱讀別人的代碼，一個很簡單的邏輯，被封裝了多次，需要在多個代碼文件中索引，閱讀效率極低。代碼文件分散，一些很簡單的邏輯，例如按鈕點擊，都做了多層封裝。
2，不太專業(yè)的某些程序的惰性，導(dǎo)致他們并不是真正理解MVC或者說這些框架的原理，他們的目標只是，把功能搞出來。他們要么繞過框架，穿插了很多調(diào)用，要么整體copy別人的一個功能，去掉邏輯，留下骨架，然后填充自己的邏輯，也不管這個骨架是否適用。這樣的人，大大增加了項目的混亂，leader要做到充分的代碼review，去除這些問題，在開發(fā)進度吃緊，每周都要出版本的情況下，是不可能的。這些快速堆出功能的程序員，反而得到策劃等非技術(shù)人員的贊賞。而認真處理，把每一塊都做好，但是慢一點的程序，反而不受夸獎，這導(dǎo)致了劣幣驅(qū)逐良幣。我相信，除了極少數(shù)精英團隊，很多團隊都有這樣的問題。
3，這些設(shè)計和框架，被濫用。比如MVC也許適用于UI部分的設(shè)計，但是，他是否適用一個戰(zhàn)斗模塊呢？他是否適用一個劇情模塊呢？有些團隊，機械地運用某些框架，并不根據(jù)需求去思考，認為某個東西是好的，就到處使用。
當一個項目規(guī)模增長，人員難以保證精英，積累了大量的需求變更，運營期間，需要快速的迭代。這種繁雜冗余的框架式設(shè)計，會導(dǎo)致代碼難以維護。有時候，并不是某個框架不夠好，更多的是，我們沒有仔細理清它的適用范圍，也難以保證規(guī)范從頭到尾的堅定執(zhí)行。并留下大量過分設(shè)計的繁雜代碼，一個一百行，幾個funtion就能解決的問題，被包裝成了多個class，層層調(diào)用，寫了幾大百行，邏輯處處分散。
那么，到底是某個框架，或者設(shè)計模式不行，還是我們使用得不夠好呢？
我們回到最初，仔細考慮，MVC解決的核心問題是，一個M，多個V，那么，在游戲領(lǐng)域，這樣的需求多嗎？是強需求嗎？我們到底應(yīng)該根據(jù)需求來設(shè)計框架，還是應(yīng)該根據(jù)框架來填充需求？一個框架，一套設(shè)計，適用不同的游戲，不同的邏輯嗎？
我認真地考慮這塊問題，發(fā)現(xiàn)很多教程，文章，他們介紹MVC，MVVM，介紹各種框架，包括uframe，StrangeIoC等，都缺少了思考和提問：
這個框架適用什么需求？解決了什么問題？
在什么情況下我該用，什么情況不該用？他帶來了什么問題？
是否適合我的項目，我的團隊？
我是應(yīng)該項目整體使用，還是某些局部的需求使用呢？
等等問題，才是我們該問的關(guān)鍵。
我們游戲領(lǐng)域的技術(shù)，特別是游戲的框架，受到了太多應(yīng)用軟件，web開發(fā)，app開發(fā)的影響，但是，這些模式并不適用我們?。≌揭驗閣eb，app這些領(lǐng)域的通用性，需求的固定性（相對游戲開發(fā)而言），他們才會誕生出如此多的框架，模式，并且在技術(shù)領(lǐng)域，發(fā)出了更多的聲音。出現(xiàn)了看似高級的設(shè)計方式。并且，web，app的項目周期，以及后續(xù)的維護周期是很長的，少則三兩年，多則十幾年，確實必須要謹慎設(shè)計。但是，我們游戲，特別是現(xiàn)在手游的生命周期又有多長呢？當需求不同，考慮問題的方式，解決問題的方式，應(yīng)該做些改變。
游戲開發(fā)，和web，app開發(fā)，能歸為同一個隱喻嗎？ 那么我們問問自己：
TDD適用我們游戲前端開發(fā)嗎？
WinForm的數(shù)據(jù)綁定，是適合我們游戲開發(fā)的嗎？
幾十個設(shè)計模式，有幾個能適用我們游戲開發(fā)的呢？分別對應(yīng)什么應(yīng)用場景呢？
用Design pattern的目的，到底是design，還是去解決具體的問題？
當我們?nèi)プ分鸶碌脑O(shè)計，更酷的框架，我們有了解他們解決的問題嗎？我們有自己了解過他的原理嗎？到底在我們自己的項目中，他能解決什么問題？我們有仔細思考過他在我們游戲開發(fā)的整個生命周期，會給我們帶來什么嗎？
最近，因為守望先鋒的一個分享，ECS開始火了起來。有個群里看到說，我們下個項目要上ECS了，問是什么類型，答不知道，但是ECS這種先進框架，肯定要用。我只能說汗~~~
靜下心來，我也追求過最新的技術(shù)，最新的框架。但是，當我們真心開始做一個項目，去解決一些問題的時候，我們需要審慎。
最終，我們要回到需求和問題，ECS，核心是為了解決網(wǎng)絡(luò)同步中預(yù)測和預(yù)測失效的狀態(tài)回滾問題。如果你不是需要解決這類問題，你確定需要上ECS？一個回合制游戲，確定需要ECS？UI寫法從MVC改ECS？
關(guān)于為什么在游戲開發(fā)中不使用MVC就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
網(wǎng)站欄目：為什么在游戲開發(fā)中不使用MVC
當前URL：http://www.dlmjj.cn/article/ihojej.html
