mvc设计模式现在过时了吗_探讨:为什么在游戏开发中不使用MVC?

de52c2a89ad6435a05ce8265b9247119.png

本篇文章我的观点,部分来源于多年的项目实践,部分源自和以前同事的讨论,以及对一些系列文章和问答的阅读。

正文开始前,先做一些声明,因为这种类型的讨论,必然导致很多反对。我只表明我个人的意见,说一点我的思考实践,以及给出一些我看到的能支持我想法的论据。后续内容中,我可能对mvc或者当前的一些框架和设计方式提出一些批评,并不表明我是百分百坚定我的想法,也不表明我认为自己的想法绝对正确,做法最优。为了不在行文中,反复需要表明我的不坚定,导致文章难以阅读,故在此统一声明,希望不要引起无谓的纷争。

以下文章中,MVC泛指MVC,包括MVVM,MVP等MVC衍生的类似设计模式。

首先,我是用MVC的,在毕业早期开发应用软件类程序,对不同数据的不同展示方式MVC是很好的设计。或者说,一个M(数据),多种V(展示),是应用软件的常见展示方式,很适用MVC。大家在看Design pattern介绍MVC的时候,常用的例子,就是一个数据,即要饼状图展示,又要柱状图展示。

后来,转行做页游,觉得当时的项目,完全没有什么设计,胡乱堆砌,乱成一团,想起了MVC等设计模式,并且,还有很多人推荐的PureMVC,Robotleg等类MVC框架,并使用了依赖注入等模式,学习了demo之后,觉得很好地解决了游戏设计问题。在跳槽后,在新的项目中,已经使用了robotleg,我进去后就很开心,开心地使用。真实地开发一段时间以后,我开始感觉到MVC或者说这类框架的问题(在和同事的讨论中,也得到了牛逼同事很多提点),或者说,是使用者带来的问题:

1,代码繁冗,当你阅读别人的代码,一个很简单的逻辑,被封装了多次,需要在多个代码文件中索引,阅读效率极低。代码文件分散,一些很简单的逻辑,例如按钮点击,都做了多层封装。

2,不太专业的某些程序的惰性,导致他们并不是真正理解MVC或者说这些框架的原理,他们的目标只是,把功能搞出来。他们要么绕过框架,穿插了很多调用,要么整体copy别人的一个功能,去掉逻辑,留下骨架,然后填充自己的逻辑,也不管这个骨架是否适用。这样的人,大大增加了项目的混乱,leader要做到充分的代码review,去除这些问题,在开发进度吃紧,每周都要出版本的情况下,是不可能的。这些快速堆出功能的程序员,反而得到策划等非技术人员的赞赏。而认真处理,把每一块都做好,但是慢一点的程序,反而不受夸奖,这导致了劣币驱逐良币。我相信,除了极少数精英团队,很多团队都有这样的问题。

3,这些设计和框架,被滥用。比如MVC也许适用于UI部分的设计,但是,他是否适用一个战斗模块呢?他是否适用一个剧情模块呢?有些团队,机械地运用某些框架,并不根据需求去思考,认为某个东西是好的,就到处使用。

当一个项目规模增长,人员难以保证精英,积累了大量的需求变更,运营期间,需要快速的迭代。这种繁杂冗余的框架式设计,会导致代码难以维护。有时候,并不是某个框架不够好,更多的是,我们没有仔细理清它的适用范围,也难以保证规范从头到尾的坚定执行。并留下大量过分设计的繁杂代码,一个一百行,几个funtion就能解决的问题,被包装成了多个class,层层调用,写了几大百行,逻辑处处分散。

那么,到底是某个框架,或者设计模式不行,还是我们使用得不够好呢?

我们回到最初,仔细考虑,MVC解决的核心问题是,一个M,多个V,那么,在游戏领域,这样的需求多吗?是强需求吗?我们到底应该根据需求来设计框架,还是应该根据框架来填充需求?一个框架,一套设计,适用不同的游戏,不同的逻辑吗?

我认真地考虑这块问题,发现很多教程,文章,他们介绍MVC,MVVM,介绍各种框架,包括uframe,StrangeIoC等,都缺少了思考和提问:

  • 这个框架适用什么需求?解决了什么问题?
  • 在什么情况下我该用,什么情况不该用?他带来了什么问题?
  • 是否适合我的项目,我的团队?
  • 我是应该项目整体使用,还是某些局部的需求使用呢?

等等问题,才是我们该问的关键。

我们游戏领域的技术,特别是游戏的框架,受到了太多应用软件,web开发,app开发的影响,但是,这些模式并不适用我们啊!正式因为web,app这些领域的通用性,需求的固定性(相对游戏开发而言),他们才会诞生出如此多的框架,模式,并且在技术领域,发出了更多的声音。出现了看似高级的设计方式。并且,web,app的项目周期,以及后续的维护周期是很长的,少则三两年,多则十几年,确实必须要谨慎设计。但是,我们游戏,特别是现在手游的生命周期又有多长呢?当需求不同,考虑问题的方式,解决问题的方式,应该做些改变。

想想《代码大全2》开篇说的是什么?隐喻,隐喻的重要性。这是全书的纲领啊,同志们。游戏开发,和web,app开发,能归为同一个隐喻吗? 那么我们问问自己:

  • TDD适用我们游戏前端开发吗?
  • WinForm的数据绑定,是适合我们游戏开发的吗?
  • 几十个设计模式,有几个能适用我们游戏开发的呢?分别对应什么应用场景呢?
  • 用Design pattern的目的,到底是design,还是去解决具体的问题?

当我们去追逐更新的设计,更酷的框架,我们有了解他们解决的问题吗?我们有自己了解过他的原理吗?到底在我们自己的项目中,他能解决什么问题?我们有仔细思考过他在我们游戏开发的整个生命周期,会给我们带来什么吗?

最近,因为守望先锋的一个分享,ECS开始火了起来。有个群里看到说,我们下个项目要上ECS了,问是什么类型,答不知道,但是ECS这种先进框架,肯定要用。我只能说汗~~~

静下心来,我也追求过最新的技术,最新的框架。但是,当我们真心开始做一个项目,去解决一些问题的时候,我们需要审慎。

比如ECS,我觉得云风的说法,是最中肯的:

b9c4eefd66178ce0e2321dc5a45eca83.png
云风博客截图,地址https://blog.codingnow.com/2017/06/overwatch_ecs.html

最终,我们要回到需求和问题,ECS,核心是为了解决网络同步中预测和预测失效的状态回滚问题。如果你不是需要解决这类问题,你确定需要上ECS?一个回合制游戏,确定需要ECS?UI写法从MVC改ECS?

写到这里,说了那么多批评的话,那么,我认为什么是最好的设计方式呢?

我认为,没有最好的,只有根据需求来的,根据团队能力来的,根据项目进度,经费来的,一切都要“具体问题,具体分析”。这句话,说出来轻松,做起来难,也有可能导致什么都做不好,代码更加混乱。那么,只能根据团队能力来选择一个合适的开发方式,没有最佳。

从MVC开始,说了那么多,太多都是务虚的。但是,我认为务虚是很重要的,思考方式,方法论,都是很重要的。甚至,我们程序员学点哲学,也是大大有益。至少,读读笛卡尔的《谈谈方法》吧。

我们需要经验慢慢积累,也需要慢慢对一些技术名词去媚,没有一招吃遍天。以下,我给出一些文章,也是一些我看到的,和我想法类似的东西,大家可以参看:

  • Why are MVC & TDD not employed more in game architecture?
  • Is the MVC design pattern used in commercial computer games

从第一篇能衍生出很多链接,都可以参看思考。

最后,我言辞可能略激烈,原因大家请参考前面的声明。希望这篇务虚的思考和讨论,能带来一些不一样的声音。

-------------------------------------------------------------------------------------------

补充:

看了评论区里的一些评论,我觉得,我必须要说明一下:我写这篇的目的,不是要告诉大家,设计不重要,框架不重要。我想明确的是:我们要仔细思考需求,来选择合适的技术方案,而不是用在一个死板地框架里硬套需求。能够审慎地选择合适的设计方案,不盲从跟风。

但是,有些评论走向了另一个不看重设计的极端,情绪式的发泄,我认为是不妥的,更加有害的。本来,做任何一个设计,都需要试错,根据需求的变更重构和改进,这当然需要时间成本,但是,这是我们的重要的个人成长之路,至少说明一个程序是看重自己的代码的,重视自己的工作的。

大环境的问题,老板的问题,或者leader的问题,进度紧的问题,当然是存在的客观因素。但是这些客观因素,不代表我们不能努力把事情做好,不代表我们不需要为自己的成长负责。如果因为客观原因,混日子,随便堆砌代码,是对自己的不负责任吧。

行业开发进度紧,加班多,是一个非常不好的状态,我对此也很不满(之前加班痛苦时,甚至yy要组织个程序工会,汗~~)。但是我相信没有一个人的工作是绝对长时间维持饱和的。我们总有时间聊聊qq,微信,上上网吧,那代表我们总有时间去思考怎么把事情做得更好,只是个人选择而已。

一个好的程序,会考虑当前需求,会预估一些需求的变化,给自己留些余地,多少也会考虑,如果别人接手,是否能理顺这个逻辑,后续变更大了,还会考虑去重构整理。甚至会站在用户,玩家的角度,给策划一些建议。这当然是知易行难的,所以,人和人,才有了区分,同样的工作经验,有的一两年,就能做到很好,能独当一面,有的5,6年后,混成了老油条。

总而言之,我这篇文章,是希望在认真对待工作和技术的情况下,更明智地思考和分析需求,选择合适的设计或者实现方案。

虚无主义地吐槽,总是容易的。努力,总是伴随着困难。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值