Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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 a great 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)?

share|improve this question

closed as primarily opinion-based by Josh Petrie Nov 17 at 23:04

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

8  
If the article you've linked to is discussing protyping, isn't it a straw man to assume it applies to production code as well? I don't think the authour would use that approach for production code. –  tenpn Sep 1 '10 at 7:40
19  
In game development, it is very common that (prototype code + bugfixes + optimization) = production code –  bluescrn Sep 1 '10 at 9:09
3  
So surely the question should be "how do we stop people putting prototype code into production?" –  tenpn Sep 1 '10 at 10:07
2  
In another comment, you say "Enterprise practices are recommended because they are proven to produce better products, faster." Could you present a source for this claim, including support for why you think MVC and TDD are included, and what they are compared against? In particular, TDD is very new in terms of gaining popularity and I'd be surprised if many enterprises used this method. –  Kylotan Sep 1 '10 at 14:37
4  
@Nate Bross - automated testing is old (and good) but the idea of writing your tests first and then writing code to fit it is pretty new. I am very sceptical of it being "proven" to produce anything better and faster. –  Kylotan Sep 2 '10 at 9:33

8 Answers 8

up vote 107 down vote accepted

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 :-P ) 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:

share|improve this answer
4  
Good points! Enterprise practices are recommended because they are proven to produce better products, faster. Millions are invested in researching this stuff and I'm wondering why this research doesn't seem to apply to game development. I don't think the games industry has any more rigorous tight schedules than other software dev industries, does it? Everyone needs to make a dollar, and I've had my fair share of long hours and rushed jobs on non-game projects. –  timoxley Sep 1 '10 at 1:28
    
Thanks for the great links! –  timoxley Sep 1 '10 at 3:23
2  
@secoif agreed. The only technical difference between games programming and enterprise programming is a minimum framerate requirement (not that enterprise programming can be dog slow). I think the problem stems from promoting devs to senior production positions. They're not interested in process or scheduling; they just want to make the creative decisions. We should have professional standards for production managers and producers, so they have a minimum understanding of what managing a software team entails. –  tenpn Sep 1 '10 at 7:48
    
I want to be able to make answers favorite now. –  egarcia Jan 10 '11 at 23:20
    
I just wanted to point out that the article is not at all saying you shouldn't build a system for your production game, his comment was specifically about prototypes. Prototypes are throwaway code, not something you are going to build on top of, and Noel (the author) doesn't want you to confuse the task of testing out your idea with the task of architecting game code. –  Nate C-K Apr 2 '13 at 17:09

Game systems are slowly moving over to better practices. Frameworks like XNA provide an insight into making code more generalized/clean without adding too much overhead in design or execution time. But in general I would say that game systems are all about optimizing complexity vs execution speed, all while staying on a tight development schedule and staying motivated. Applying software engineering concepts and system design is just not priority #1 in such an environment.

In my personal game projects, I try to comment code or at least make it readable, and I throw together systems that will allow a bit more flex later on (ie generality) as much as possible, but at the end of the day, if you haven't moved your game forward it just doesn't feel very good.

Also typically by the time you've finished your game, you've got at least 1000 ideas on how to improve the underlying mechanics, the core systems, etc, in such a way that very little of that "re-usable" code will really be usable. By day I work a regular SE job, and while the systems we work on may be massive, in all honestly I think they pale in comparison to the complexity in games.

share|improve this answer

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.

share|improve this answer
10  
The "games are fun and there's no tests for fun" argument really gets me. My A* implementation doesn't have to be fun. The save game system doesn't have to be fun. The events queue doesn't have to be fun. Break the game down and you can write unit tests (before or after) for every bit. It's how you put them together (which isn't the remit of unit tests, but rather functional tests) that makes the fun. –  tenpn Sep 2 '10 at 7:39
3  
If you write the tests after, that's not TDD, and no one is arguing some automated tests are impossible/bad. There's no strong evidence that time spent writing extensive unit tests is better than time spent writing more of the game and traditional debugging. Also, your functional tests effectively test an awful lot of the things you would end up writing unit tests for. And finally, the number of bugs that occur in e.g. the A* code or event system for a game is dwarfed by the number of bugs in the much harder to test things, e.g. an artist put a tree in the path by mistake. –  user744 Sep 2 '10 at 10:05
2  
Joe is correct, most bugs in a video game are not algorithmic bugs; they are asset, or gameplay related bugs that you can only really test for with excessive Q&A and playtesting. Nobody (except for the graphics programmer) is going to be particularly bothered by the pixelated shadow edges, but people are going to be frustrated when the evil monster at the end of level 3 is unbeatable because it's not vulnerable to the magic spell you collected two levels earlier and there isn't another way to defeat it. –  Jasper Bekkers Sep 2 '10 at 10:27
3  
Another consideration: Your A* implementation doesn't have to be fun, but your pathfinding implementation does. Players may complain if the AI takes "too optimal" paths, because it looks unnatural (e.g. jump over a banister rather than walk two more feet and turn to walk up the stairs). Every system in the engine at some point has to serve the goal of making a good game. –  user744 Sep 2 '10 at 11:15
4  
My issue is with the part of the answer that states "there's hardly any point writing tests up-front." The argunment seems to be that because unit tests can't capture some possible problems ("fun", art bugs), it's pointless. But of course it can capture other problems, some that may directly affect that mythical untestable fun factor. For instance, of course you can use TDD to extend your A* code so it returns "realistic" paths. That's not fun, though, it's a tool to create fun. –  tenpn Sep 2 '10 at 13:28

As Kylotan notes, "In games you can't treat the presentation aspect as a detachable and replaceable concept like HTML and CSS is for web apps". Having built a couple of games using a simple MVC pattern (not a huge framework) I've found the major problem is that your model needs to know about your view. It is very likely that you will need to use either sprite bitmap data, hitbox data or 3D geometry data from your art assets to help work out collision detection (or another similar task). This means each model needs a reference to its view, which breaks the classic MVC pattern - for example you can no longer create a new view to an existing model etc.

The component model you see in e.g. Unity3D is the best way to organise game code.

share|improve this answer
3  
Yes, this touches on an interesting point, that in games you can't treat the presentation aspect as a detachable and replaceable concept like HTML and CSS is for web apps. Often it's the artists who are dictating some of the 'rules' you have to work with, so the logic must take the properties of the view into account. –  Kylotan Sep 1 '10 at 14:28
    
yes that's exactly what I was trying to say (I think you said it better) –  Iain Sep 1 '10 at 14:54
3  
This sounds like a case where the MVVM pattern might apply. –  Alex Schearer Sep 1 '10 at 16:03
    
The model needs a reference to a view, but doesn't need to depend on it. You can make an interface "HitBoxSupplier", depended on by the model and implemented by the view. –  Bart van Heukelom Sep 2 '10 at 15:00
    
Bart - that would still break the classic MVC pattern –  Iain Sep 2 '10 at 15:56

MVC, at some levels, is already used in game development. It's forced on it by the OS, which has different interfaces for input and graphics. Most games also have a few more instances of MVC in them, e.g. separating the physics and rendering and input threads. This works fine. The modern idea of MVC appears to be that it should be repeated, fractally, until no one can understand the code anymore. Games don't do that, thankfully.

TDD is not used because it's rarely known a game is "supposed to do" before you iterate on a prototype many times. Practices from TDD, like continuous testing or integration testing, are often used in game development.

share|improve this answer
1  
Re: TDD. See the comments to this answer (gamedev.stackexchange.com/questions/1905/…) for why I think TDD can absolutely be applied to game development and prototyping. Although it seems controversial. –  tenpn Sep 1 '10 at 10:09

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.

share|improve this answer
1  
re: tdd point 1, I think your point is more applicable when trying to force unit tests on existant code. When writing new code, TDD will produce code with low coupling and less shared state that is easy to test. Also, testing the "main simulation" is IMO more the area of functional tests, not TDD and unit tests. –  tenpn Sep 1 '10 at 14:59
    
"TDD will produce code with low coupling and less shared state that is easy to test." Compared to what? These are the vaunted benefits but there's a dearth of any proof that this is a better approach than just following best practices for interface design from the start. –  Kylotan Sep 1 '10 at 15:27
2  
Compared to the code that most game programmers write that is highly coupled to the entire rest of the codebase. TDD "fixes" this by making it very hard to write in the first place. –  dash-tom-bang Sep 1 '10 at 22:59
1  
You're missing the point. Even if the TDD method does force you to write good code (which I don't agree with - it's often good black box code but can be poor white box code), there's no indication that you couldn't or wouldn't write code equally good if you approached it a different way - for example, using the time you would spend writing these tests and mock objects and fixtures on more adequate design, or even just on a "test last" approach that requires less refactoring. –  Kylotan Sep 2 '10 at 9:29
3  
I'd still like to see evidence that using TDD inherently produces decoupled code. As I said below, if you write decoupled tests, you get decoupled code. But you need someone skilled enough to write decoupled tests. And that person can probably write decoupled code without tests, as well. –  user744 Sep 2 '10 at 13:42

I have no particular opinion of MVC outside of the fact that the view is often separated from the logic by the simple fact that the render loop is packaging a bunch of stuff up for some hardware to process and that's not the place where you want "game logic" happening concurrently. The "controller" is also separated by hardware, but unfortunately many if not most game developers do "interesting" work in the controller handler. (IMO the controller handler should be reading the buttons and sticks and building a "presentation" for the game to view, but my soapbox isn't that strong.)

TDD on the other hand is something that I have very strong opinions about. It just changes development in a way to yield software that is easier to build upon. It is harder to do, no doubt about it. Of course, since it's harder to do, it's not done. Some folks whine about TDD (or more generally unit testing) having no value because "the game is the test," but the fact is that in TDD, the testing is almost irrelevant. The point of TDD is the software design and architecture that comes out of the process.

Embracing TDD really changes one's approach to programming. I had some feelings about what was right and what was wrong before I started down the TDD path, but once I jumped in with both feet I really came to understand a lot more about how the things I was doing was either helping or hindering future development. Indeed, this is sort of the point behind the coderoom post, TDD without the t.

Back to why it's not used more in games, beyond being hard, it makes people realize that the way they've always done it in the past needlessly made their own jobs harder, and for programmers especially that's a bitter pill to even look at, much less swallow.

I am convinced that people who refuse to accept TDD simply don't want to be better programmers. They already think that they're "excellent" at programming or design or architecture, when in fact their code says something completely different.

share|improve this answer
1  
TDD guarantees that your program passes your tests. If you're lucky, those tests guarantee that you meet some kind of minimum functional specification. Nothing about it guarantees good design or architecture. Bad architects will make bad choices of tests. Good architects will make good choices without tests. –  user744 Sep 2 '10 at 11:11
1  
Of course, dash-tom-bang's "excellent link" is how about that rigid working cycle kills joy and productivity. At best, it supports that TDD can, over time, turn bad designers into acceptable ones. And the sign of that success is (ironically) that they do not need TDD anymore. –  user744 Sep 2 '10 at 13:54
1  
Anecdotally, I have seen bad programmers continue with horrible designs using TDD, despite the tests being incredibly laborsome to write. Sometimes they are even happy about it, because writing the bad tests (thereby delaying real failure) doesn't make you feel nearly as bad as writing bad production code. –  user744 Sep 2 '10 at 13:58
1  
@Joe- taken to an extreme even seeing the running game doesn't mean it's going to keep working tomorrow. Looking for a "proof" that any program is correct is foolish. It is true that TDD isn't a guarantee that someone will become a better programmer, but if one desires to become a better programmer, TDD will help. You can't force the horse to drink and stories are numerous describing people who embrace TDD as a team finding the quality of their code going up. On the flip side: so TDD "guarantees" that the code passes the tests. Without tests you don't even have that. Which is preferable? –  dash-tom-bang Sep 2 '10 at 17:03
1  
Further- too many programmers are apt to gold plate their code. Just because something is written and appears to work today should not automatically make it untouchable. Folks have to embrace the idea that software should be easy to change. Of course, making changes is much riskier without tests... –  dash-tom-bang Sep 2 '10 at 17:05

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.

share|improve this answer
1  
-1 This may hold true for, say, casual mobile games. I agree that model and view are closer in games than in other applications. Still in anything of more complex appearance there may be a great divide between the elaborate representation, and an often straightforward model behind it. See this video for a corner case example. Yet most of the time I consider this actually a helpful separation. –  fbmd May 28 '13 at 7:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.