There are a wide variety of “development methods” out there, and a lot of them have their very useful purposes in a large team or corporate environment. Odds are that if you’re reading this blog, you’re not a large team or corporate developer – or at least you aren’t for the sake of learning to write games. We’ll talk about the two main categories of approaching a game’s design today, and see if you can figure out which one I give my stamp of approval to. After all, following SOME sort of process is the only way to get from “crazy idea” to “working, implemented crazy idea”.
All of the major flavors of “development method” out there today fall into one of two categories – procedural development and incremental development. To better explain and illustrate the differences between the two, we’ll use Grant Wood’s American Gothic:
Lovely couple, aren’t they?
Procedural Development:
Both methods of development start with a rough outline of what you’re trying to do. Procedural development involves taking individual tasks, one by one, writing them through to do exactly what they’re supposed to, and building your program like that – one finished component at a time. It’s something like painting a picture based on a rough sketch, and painting one perfect section at a time before moving on to the next section:
At any point in development, the things that are DONE all (in theory) work perfectly, but the whole thing isn’t DONE until all parts of it are. That is, you can test each of the sections you have done, individually, but the whole program doesn’t “do anything” until it’s all done. (This is a gross oversimplification, but I see it happen all too often to ignore.) The downside to this is it becomes difficult to spot flaws in your design until you come closer to the end, when everything is working together.
Incremental Development:
The premise behind incremental development is that you build your project such that, at any time, it runs and does the things you’ve written so far. It’s akin to painting large blotches to show where things are going to be, and going back as you go along and refining the individual details until the whole painting is finished and clear:
His face is blotchy, while hers has quite a bit more detail – but most importantly, his is THERE. Just not refined. This is the model I tend to use, and it’s what works best with the setup we’re using now. In fact, without even noticing any difference, it’s the model we’ve been using if you’re playing along at home – we generated a project that doesn’t do much aside from check for a reason to quit, and quit – but it RUNS right now, and does everything we’ve written it to so far.
Ideally, at any point in the project where you decide to stop, it should COMPILE, BUILD, and RUN. Whether or not it does everything we have planned for it, it should do (without any problems) everything we’ve already written it to do. That can be a slight disadvantage, if you force yourself to keep working until it’s back at a state where it “works”, but it can also be a huge boost, in that any time you walk away from your project, you know it still works. Also, specific to game development, this method elicits far more “oohs” and “aahs”, since you have a “working game” at all times, even if not a very pretty or fun one. Finally, in terms of flexibility, this method has the upper hand – you refine one piece a little, and touch all the pieces that connect to it, but you don’t have to polish one specific chunk of code to a mirror shine and ignore everything that it reflects.
So to sum things up, as we work on our game, let’s agree on one thing: Every time we get up and walk away from our code, it should work. Whether it works correctly or not is negotioable, since it will be in a state of flux right up until the end, but at all times, when we stop, we should be able to call out to someone “Hey! Look at what I’ve made!” and have something worth showing them.