As the quote says, many programmers make the mistake of (trying to) build a system, not a game. Typically that system keeps ballooning out of control until it’s so complex that theoretically it can handle anything, but in practicality all you have is a big bundle of code. Or more often, before you even get to a working stage, you are so tangled up in code that doesn’t run that you lose focus (if you had any to begin with) and motivation (since nothing is truly working).
Prototypes and iteration tend to work much better. In the end, a great design might come out of it, but more often something more simple and refined comes out of it. KISS and YAGNI come to mind.
I personally believe there needs to be a balance. If there’s a core mechanic of your game, work on it. You still need to iterate, but you do need to refine it. Hint: organization of your code is not a core mechanic of your game.
Case in point: Peggle, by PopCap Games. A core mechanic of the game is the ball physics. They perfected it! I’m sure they spent quite a lot of time making sure it was absolutely perfect, because it is what makes the game. But at the same time, I can totally picture an early prototype of their game that maybe just draws sprites to the screen and does some type of more primitive collision detection and bouncing, just to see if the game idea is fun. Then once they found out that shooting a ball and watching it bounce can actually be fun, they refined the bouncing of the ball. (this is all just speculation, of course)
It also depends on your technical requirements, which you should nail down early on (not your game design, just the technical requirements). The platform that your game runs on should not change, or if it should be allowed to change, you need to know exactly the extent that you plan to allow it to change, no more and no less. Design on that. If you’re developing a game for OpenGL, and you don’t care about DirectX, then really, don’t care about it. That means that if it’s more convenient for you to have each entity draw itself and not worry about Factories and other design patterns like that, then do that. It’s okay, because it meets the requirements. You should not have to change it later, despite what you tell yourself. And really, worst case scenario? Refactor later. It takes time later but it lets you focus on the now, getting a working game on one platform even if it means it can’t simultaneously and automatically run on your toaster.
Test driven design, however, is a more opinionated topic. I am of the belief that game developers should do more of it. I also think game developers have some of the most rigorous, tight schedules, and they think they can’t afford to spend time on TDD when they just want to get a game going. Also, again with the motivation, TDD is a lot slower and you get to see a lot less of a functioning game (in the beginning at least). This can have serious negative effects on programmer motivation.
I think it’s also just a general lack of knowledge and practice. I don’t think TDD is prevalent in other areas either, but like agile development, I think it’s spreading. You might say it’s ahead of its time (or maybe not, as the case may be years from now). More important than TDD is “RDD” – Requirements Driven Development. I just made that up. What is your goal? To make a game. Everything else comes second. If you can prove that TDD increases productivity and helps teams reach deadlines, then don’t you think everyone would be using it? And maybe that’s the case. But right now, our industry is more competitive than ever, there are harder and sooner deadlines, and stuff just needs to work. Construction workers don’t build scaffolding first; they lay a foundation, then they raise some walls and floors, and only then do they build selective bits of scaffolding to do specific tasks which scaffolding makes more convenient. I think the same applies to software development.
Sorry for such a long post. I hope you’ve gained some bits of wisdom from it. I am just a student, talking about my observations, with very limited industry experience but a lot of reading from industry experts. So take my words with a grain of salt.
And hey, do what you think will work. You can always change it or scrap it and start over. That’s the cool thing about any form of engineering; if at first you don’t succeed, try something different. (or something like that 😛 ) You’re not pouring concrete; software is malleable.
By the way, I’ve been asking this same type of question and researching these types of design principles for some time. Here are some questions, both here and in Stack Overflow, that you might find relevant:
- “How can you organize the code for a game to fit the MVC pattern?”
- “How to design a game’s software such that it is easy to unit test?”
- “Component based game engine design”
- “Any good tutorials or resources for learning how to design a scalable and “component” based game ‘framework’?”
- “Seperation of game- and rendering logic”
- “Is unit testing viable in game programming?”
- “Is the MVC design pattern used in commercial computer games”
- “Is test driven development a normal approach in game development?”
- “Do any of you use Scrum for game development?”
- “Architecture for Game – To couple or not to couple?”
- “OO game design question”
Here’s my original answer to a similar question on 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.
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 of any game 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.