8
为什么在游戏架构中不更多地使用MVC和TDD?[关闭]
首先,我不会看大量的游戏资源,也不会以游戏的方式构建游戏。 但是,由于试图在Web应用程序中采用“企业”编码实践,查看游戏源代码严重伤害了我的头脑:“这种视图逻辑与业务逻辑的关系是什么?这需要重构……重构,重构,重构也是如此吗? ” 这让我很担心,因为我将要开始一个游戏项目,而且我不确定尝试对mvc / tdd的开发过程是否会阻碍我们或为我们提供帮助,因为我看不到很多使用此功能的游戏示例或在社区中推动更好的建筑实践。 以下是一篇有关原型游戏的精彩文章的摘录,尽管对我而言,这似乎正是许多游戏开发人员在编写正式游戏代码时似乎使用的态度: 错误四:构建系统而不是游戏 ...如果您发现自己从事的工作无法直接推动自己前进,请就此停下来。作为程序员,我们倾向于尝试将代码泛化,使其变得优雅并能够处理各种情况。我们发现痒痒非常难,不会刮伤,但是我们需要学习如何做。我花了很多年才意识到,这与代码无关,而与最终发布的游戏有关。 不要编写精美的游戏组件系统,不要完全跳过编辑器,而将状态硬编码到代码中,避免数据驱动,自解析,XML疯狂,而只需编写该死的东西。 ...尽可能快地在屏幕上获取内容。 而且永远不要使用参数“如果我们花一些额外的时间并以正确的方式进行操作,我们可以在游戏中重用它”。永远 是因为游戏(大多)是面向视觉的,所以有意义的是代码将在视图中占很大的比重,因此将内容移到模型/控制器中所获得的任何好处都非常少,所以为什么要打扰? 我听到过这样的论点,即MVC引入了性能开销,但是在我看来这是过早的优化,在担心MVC开销(例如渲染管道,AI算法,数据结构)之前,还有更多重要的性能问题需要解决遍历等)。 关于TDD也是一样。我很少看到游戏使用测试用例,但这可能是由于上述设计问题(混合视图/业务)以及难以测试视觉组件或依赖概率结果的组件(例如,在物理模拟中运行)造成的。 )。 也许我只是看错了源代码,但是为什么我们看不到游戏设计中采用的更多“企业”实践呢?游戏的需求真的有如此大的不同吗?还是人/文化问题(例如,游戏开发者来自不同的背景,因此具有不同的编码习惯)?