问：

I will preface this by saying I haven't looked a huge amount of game source,nor built much in the way of games.

But coming from trying to employ 'enterprise' coding practices in web apps,looking at game source code serIoUsly hurts my head: "What is this view logic doing in with business logic? this needs refactoring... so does this,refactor,refactorrr"

This worries me as I'm about to start a game project,and I'm not sure whether trying to mvc/tdd the dev process is going to hinder us or help us,as I don't see many game examples that use this or much push for better architectural practices it in the community.

The following is an extract from agreat article on prototyping games,though to me it seemed exactly the attitude many game devs seem to use when writing production game code:

Mistake #4: Building a system,not a game

...if you ever find yourself working on something that isn’t directly moving your forward,stop right there. As programmers,we have a tendency to try to generalize our code,and make it elegant and be able to handle every situation. We find that an itch terribly hard not scratch,but we need to learn how. It took me many years to realize that it’s not about the code,it’s about the game you ship in the end.

Don’t write an elegant game component system,skip the editor completely and hardwire the state in code,avoid the data-driven,self-parsing,XML craziness,and just code the damned thing.

... Just get stuff on the screen as quickly as you can.

And don’t ever,ever,use the argument “if we take some extra time and do this the right way,we can reuse it in the game”. EVER.

is it because games are (mostly) visually oriented so it makes sense that the code will be weighted heavily in the view,thus any benefits from moving stuff out to models/controllers,is fairly minimal,so why bother?

I've heard the argument that MVC introduces a performance overhead,but this seems to me to be a premature optimisation,and that there'd more important performance issues to tackle before you worry about MVC overheads (eg render pipeline,AI algorithms,datastructure traversal,etc).

Same thing regarding TDD. It's not often I see games employing test cases,but perhaps this is due to the design issues above (mixed view/business) and the fact that it's difficult to test visual components,or components that rely on probablistic results (eg operate within physics simulations).

Perhaps I'm just looking at the wrong source code,but why do we not see more of these 'enterprise' practices employed in game design? Are games really so different in their requirements,or is a people/culture issue (ie game devs come from a different background and thus have different coding habits)?

回答1:

@H_403_43@

Why are MVC & TDD not employed more in game architecture?

Warning: opinion ahead.

MVC isn't used (much) because:

1. MVC is a relatively new approach and games are typically built on old code. Most people making MVC apps are building them from nothing each time. (I know MVC itself is actually decades-old; what is new is the widespread interest in it,which essentially came from web apps like RoR). In the business software I worked on that was based on legacy code,there was no use for MVC there either. It is a culture thing,but it's not game-specific.
2. MVC is essentially a GUI pattern for event-driven programs. Games are neither GUI-dominated nor event-driven,hence the applicability is not as great as it is for web apps or other form-based applications. MVC is typically the Observer pattern with some well-known roles,and games often don't have the luxury of waiting to observe something interesting - they have to update everything every frame (or some variation on that) whether or not anybody has clicked anything.

That's not to say games can't learn a lot from MVC. I always try and separate the model from the view in games I make. The traditional idea of the view and controller being 2 parts of the same (widget) object doesn't really work though,so you have to be a bit more abstract about it. I agree with you that performance is unlikely to be a real problem here. If anything performance can benefit from keeping visual stuff and logic stuff separate as that is more amenable to cache coherency,parallelism,etc.

TDD isn't used (much) because:

1. It's really awkward to use in games. Again,it's fine for event-driven software where inputs come in and outputs come out and you can compare what you saw against what you expected and tick it off as correct. For simulations with large amounts of shared state it's significantly more awkward.
2. There's no indisputable evidence that it helps anything at all. Just a lot of claims,and some figures often based on self-reporting and appeals to authority. Perhaps it helps poor programmers become mediocre but holds back good programmers. Perhaps the time spent writing tests could be better spent learning SOLID principles,or designing the correct interface in the first place. Perhaps it gives a false sense of security to have tests that pass without any real proof that you have enough tests to ensure your object does the right thing.

Again,as a caveat,I think unit tests are great,but I don't think "test first" is either beneficial or sensible. I also don't think it's practical to test the main simulation when there is so much shared state changing many times per second. I limit my tests to my low level and library code,generally.

However,as you can probably guess,I am largely biased against "'enterprise' coding practices" as enterprises are well-known for overrunning timescales and budgets."So do games developers!"I hear you say - well,yes. I don't think anybody really knows the best way to develop software right now and I'm not convinced that adopting regimented practices in mainstream software is at all a step up from the freer practices in entertainment software. In fact I suspect it's primarily of benefit to those who rely on commodity Java programmers where these approaches are not a ladder to climb to greater heights but a safety net to stop them falling too low.

回答2：

Here's my original answer toa similar questionon SO from a while back,at least concerning the MVC part of your question:

It's rarely used in games. It took me a while to figure out why,but here's my thoughts:

MVC exists to make a distinction between two representations. The Model is the abstract representation of your data. It's how the machine views the state of your application. The View (and Controllers) represent a more concrete visible instantiation of that system in a way that's meaningful to humans.

In most business apps,these two worlds are pretty different. For example,a spreadsheet's model is simply a 2D grid of values. It doesn't have to think about how wide the cells are in pixels,where the scrollbars are,etc. At the same time,the spreadsheet view doesn't know how cell values are calculated or stored.

In a game,those two worlds are much closer to each other. The game world (model) is typically a set of entities positioned in some virtual space. The game view is also a set of entities positioned in some virtual space. Bounding volumes,animation,position,etc.,all things you would consider part of the "view" are also directly used by the "model": animation can affect physics and AI,etc.

The end result is that the line between model and view in a game would be arbitrary and not helpful: you'd end up duplicating a lot of state between them.

Instead,games tend to decouple things along domain boundaries: AI,physics,audio,rendering,etc. will be kept as separate as possible.

回答3：

Because MVC doesn't fit in the architecture of a game. The dataflow for a game is entirely different than that of a enterprice application,because it's not as event driven and there is often a (very) tight millisecond budget in which to perform these operations. There are a lot of things that need to happen in 16.6 milliseconds so it's more beneficial to have a 'fixed' and rigid data pipeline that processes the data you need on screen in exactly that time.

Also,the separation is there; most of the time it's just not wired the same way as the MVC pattern. There is a rendering engine (View),user input handling (Controller) and the rest such as gameplay logic,ai,and physics (Model). Think about it; if you're fetching user input,running the ai and rendering the image 60 times per second,then why would you need an Observer between the model and the view to tell you what has changed? Don't interpret this as me saying that you don't need the Observer pattern in games,you do,but in this case you really don't. You're doing all that work,every frame,anyway.

Although TDD is hardly ever used in development studios,we do use Agile practices towards software development and SCRUM seems to be the popular choice at least here in Europe. The reason is simple,the changes come from everywhere. The artists might want more texture budget,larger worlds,more trees while the designers want a richer story (more content on disk),a streaming world and the publishers want you to finish on time,and on budget and so does the marketing department. And apart from that,the "state of the art" keeps changing rapidly.

That doesn't mean that we don't do testing either,most studios have large Q&A departments,run loads of regression tests and do unit tests on a regular basis. However,there's hardly any point doing unit tests upfront because a large part of the bugs are art/graphics related (holes in collision meshes,wrong textures whatever,glitch in the depth of field shader) that unit tests can't cover. And besides working code,the most important factor ofanygame is that it's fun,and there's no unit testing that.

Also remember that in the console world this is even different still,because you're programming more for the hardware then for anything else. This generally (PS2/PS3) means that the flow of the data is way more important then the flow of the code in nearly every case; due to performance considerations. Which nullifies the use of TDD as an architectural tool in most cases. Good OOP code generally has bad dataflow,making it hard to vectorize and parallelize.

回答4：