I’ve been struggling for a while between two seemingly contradictory approaches to games development I believe strongly in:
- You should know what game you’re building at the start of the project, otherwise your game will lack focus and will take forever to build.
- You should be very agile by iterating a lot and adapting your game as it’s built to take it in the best direction, which you discover as you build the game.
The two method are opposed in that the first tells you that you should know what you’re doing ahead of time and the second tells you that you can’t know what you should be doing until you have something running. By following the first approach, you risk painting yourself in a corner when you discover, too late, that a feature that sounded great on paper isn’t so great in reality. By following the second approach, you risk running around in circles for a long time as you don’t really know where you’re going and you keep adding and removing stuff.
I now believe that the best approach is a balance between the two methods: for each decision, you iterate using a method that’s appropriate the level of the decision and avoid changing the decision you find is best unless it really proves wrong.
What do I mean by the level of a decision?
A high level decision is an issue that concerns the game as a whole: what’s the high concept, the environments the game takes place in, the story, etc. Iterating in software at this level of decision would be really difficult, so you’re better iterating on paper by brainstorming, drawing concept art or writing ideas and seeking feedback on them.
A medium level decision is something that affects a sizable chunk of the game: enemy types, control and interface decisions, overall level layouts and so on. Testing these elements directly in the game might be difficult because of the interactions with the rest of the game, but you can build a separate prototype to test them out independently. Iterating in a separate prototype lets you see these ideas closer to what they will be in the game without risking to break the game to test them out.
A low level decision is fine-grained element of the game that need to be decided: the specific stats of an enemy, the placement of those enemies within a level, the details of the working of an interface, etc. These decisions are small enough that building them and testing them directly within the game is the best approach — more abstract methods would just take too long. Iterating directly within the game is fast and lets you see the decision’s impact to the game immediately.
Let’s say you’re building a first-person shooter. A high-level decision might be to decide that a quarter of the game will take place in a secret Nazi laboratory in the Amazonian rainforest (you’re not making a very creative FPS). You decided this after carefully considering a lot of other potential settings. A medium level decision might be the general layout of the Nazi base, which you quickly modeled in 3D using SketchUp to quickly communicate with artists what you have in mind. Using SketchUp, you can quickly modify the layout without concerns for small details. Low level decisions in this case are all the details of the map: where to place enemies, what each part of the level should look like and so on. You can quickly put those in the game and tweak them by playing the level directly.
So that’s where I stand right now in the “design upfront” versus “iterate, iterate, iterate” debate. My approach is to take decisions and stick to them until proven wrong, but iterate to find the best decision. It’s not perfect, but I find it’s a good balance between flexibility and decisiveness.