Deconstructing the Iterative Development Process

This post actually started out as a retrospective for the game I've been working on for my internship/independent study with Riverman Media. At first I was planning to write on everything I've learned during this semester, almost like a postmortem for a project that isn't over yet. But such a post would have probably ended up being a loose collection of small tips, and I prefer to use this blog to explore deeper topics. So I decided to write on the biggest and most confusing problem that's been bothering me all semester: how to properly use the iterative development process.

In the past few years, I've seen at least three memorable explanations of the iterative process, and most of them were too complicated to be practical. It wasn't until I read Jesse Schell's description of the process that I started to believe that I finally understood it, but when I tried to apply it to this project, it just didn't feel like design to me. I have experience designing things in several different media, but for some reason, I felt like I was having trouble migrating my usual design perspective to a long-term game project.

The more I explored this problem, the more I realized how shallow my understanding of this process was. I had learned a lot about the surface details of this process, how to use it, and why it worked. But I didn't really understand why this process was designed in the way that it was or how to fix it when something went wrong with it.

I eventually answered these questions by trying to design a brand new development process that would work for me. I was basically trying to reinvent the wheel, so it was little surprise that I arrived at the iterative development process as my answer. But along the way, I was finally able to wrapped my head around how this process is really meant to work. I decided to turn this exercise into the premise for this post, and the result is a guide that teaches this development process by focusing on its design rather than how it's used. In other words, it's the kind of guide I wish I had read before starting this project.

Introduction to Development Processes

Most discussions about development processes seem to be tailored to a business or scientific perspective, which tends to make them unnecessarily confusing, in my opinion. I'm much more interested in the practical side of this topic, so I'm going to focus mostly on how you can relate this knowledge to your own work.

It can be pretty hard to think about development processes if you don't already know how to observe your own workflow. Once you can see more clearly how you work and how you solve problems, then you can start improving both your efficiency and effectiveness when working. More importantly, you can start learning how to use new workflows, much in the same way that you can learn how to use a new tool.

Here's an example of a workflow or process that you're probably familiar with, since it's usually the "default" process that most would people tend to use when they try to make a game for the first time:

1. Decide what you want to do (Design),
2. Figure out how to do it (Plan),
3. Do it, and then you're finished (Implement).

Part of what goes wrong with many amateur game projects is that people want to feel productive when they work, so they will often breeze through the first two steps in order to get to the implementation phase as soon as possible, probably under the presumption that this is where the "real" work is at. But this common problem is just a red-herring, because you really shouldn't have been using this process in the first place. This particular process is known as the Waterfall model, and it's actually pretty infamous in the world of software engineering.

While it may seem like an intuitive plan to follow, the Waterfall model just doesn't support large projects very well. Large projects require a lot of design and planning, and this process practically discourages real design work from happening. You can only improve a design after it has been implemented, and when you design everything up front, you're forced to make a million assumptions about what works. And once you start making assumptions, you're no longer designing the game—you're fantasizing about it.

Some people try to fix the waterfall model by adding a few extra steps to the end so that there's some time left over to fix the problems that inevitably surface during the implementation phase. But this is like putting tape over a leak, since it doesn't fix any of the structural problems inherent in the design of this process. In order to really fix this problem, let's try to design an entirely new process to work with.

To Design a Process

It's pretty scary how something as invisible as your own workflow can derail a project. And the prospect of designing such a thing can also be a little intimidating. Fortunately, because we're only interested in the practical side of this discussion, I would argue that we shouldn't worry too much about accuracy when describing processes. This is why my description of the Waterfall process may not match what you'd find on Wikipedia, for example.

So if we're going to design a new process, let's begin by figuring out the core traits we'd like this process to have. First, we'd like to fix the biggest flaw of the Waterfall approach and make something that encourages a healthy design perspective. Next, the process must be realistic in terms of the amount of time and resources that it takes to develop a game. Finally, this new process must be able to compete with the intuitiveness and attractiveness of the Waterfall model, or else it would take too much discipline to follow and leaves you feeling lost as you follow it.

The reason why the Waterfall model is so attractive is because the entire process can be abstracted into one simple step:

1. Work on it until it's done.

Even though this description is much more ambiguous than the real thing, it more closely resembles the thoughts that people go through when they choose to use the Waterfall model. You can think of this description as the "theme" with which the rest of the process is designed around, because every part of the process stems intuitively from this basic plan.

The simplicity and elegance of the theme is what makes this process so invisible. The truth is that we want our workflows to be invisible, because otherwise it just becomes part of the work. Like a well-designed user interface, a good development process should be so easy to use that you don't even have to think about it. If you've ever tried to follow a complicated, unintuitive process before, then you know how hard it can be to keep yourself from reverting back to a simpler process during times of stress. This is exactly what happened to me multiple times during my internship, despite the fact that I had complete faith in the process that I was following.

So now we know that we're going to need a simple and intuitive theme with which to design our new process around. Since the theme will probably have something to do with our goal to encourage design perspective, the next section will focus exclusively on understanding the typical designer workflow.

The Iterative Cycle

When you work in any design-oriented profession, whether it's in visual arts, music, film, writing, etc., you'll find that your workflow will usually simplify itself into two simple steps:

1. Implement your idea,
2. Evaluate your idea, and then go back to step #1.

This two-step process is typically referred to as the iterative cycle (not to be confused with the "iterative development process", which relates to software development specifically). For any given project, the designer will loop through this cycle dozens of times before arriving at a final product. Each loop through the cycle is called an iteration, and the more iterations you can complete on a project, the more it will improve.

This is why when you first learn how to write essays in school, you're usually taught to write a couple of drafts before you're allowed to create the final draft. At this stage, you've already learned how to write (step #1), but now you must learn how to find the flaws in your own writing (step #2) and figure out how to fix them (back to step #1).

The iterative process isn't always followed so formally, however. If you're writing an essay, for example, you might read a paragraph that you have just written, only to decide that you need to move a few sentences around. Every time you do this kind of on-the-fly editing, you have just completed another iteration, and it probably happened in less than a minute.

It isn't until you master the second step—the ability to evaluate and critique your own designs objectively—that you really start to think like a designer. Too many aspiring designers seem to be more interested in making all of the creative decisions behind a game, and so their work tends to be careless and filled with assumptions, almost as if they believe that everyone will magically enjoy their game in the end. But a serious designer is much more cautious. Because they are in the habit of looking for the flaws in their own work, designers will spend more time thinking about what might go wrong with the final product, which allows them to consider many design problems before they appear.

It's for this reason that the iterative cycle is sometimes described as a risk-mitigation process. Under this description, the order of the two steps is reversed:

1. Find a potential risk in your design (Evaluate),
2. Try to mitigate that risk, and then go back to step #1 (Implement).

This description is much broader than the first. While the previous description limits itself to what's inside the game, this new definition more explicitly considers the external factors that could affect the game.

For instance, under the first description of the iterative cycle, the designer might ask questions such as: "How does this small change affect the feel of the game?", or "Is this level really as exciting as I hoped it would be?" But with this new description, a designer may now also ask: "Will players find this mechanic too confusing?", "Do we have the technology to make this feature work?", "Do we have enough money to pursue a project of this scope?", or even "Are we sure that our publisher really won't go bankrupt six months from now?" All of these risks will affect the design of the game, because there's no point in designing a game that you can't build properly.

Some people think that this kind of design perspective is pretty depressing, since it means you're always looking at the bad side of things. But in actuality, the main sentiment that this perspective brings is objectivity, not pessimism. Much in the same way that a scientist maintains a healthy amount of skepticism in order to better understand the world, the designer must also keep themselves grounded in reality or else they may never be able to face the all too common truth that their game just isn't fun yet. In other words, it's easier to accept painful information if you're actively looking for it, rather than running away from it.

I personally find both descriptions of the iterative cycle useful. Too many design questions present themselves much more naturally under the first description, and it just seems like it's more work to think of them as risks. Furthermore, not every design question might be easily turned into a risk. Sometimes you just get curious and you want to ask "what if?"

Iterative Game Development

It'd be great if the iterative cycle could be applied seamlessly to game development, but unfortunately, there's a big dilemma that gets in our way. As I mentioned before, you can only evaluate a design once it has been implemented, but it takes so much work to implement a game that it'd be unrealistic to follow the iterative cycle alone. If you're not careful, you could burn through most of your time and resources on just a single iteration—at which point you might as well be following the waterfall model.

Perhaps the only solution would be to become extremely frugal with how one uses the iterative loop. Rather than taking each iteration for granted, the designer must try to minimize the cost of each iteration while also maximizing its value.

This is where the idea of rapid prototyping comes in. If, for example, all you want to know is whether or not a certain system of mechanics is fun, then you should make a crude representation of that system as fast as possible. Programming is often the slowest way to test a design, and so it's common practice for designers to build representations of their systems, which are typically referred to as "paper prototypes."

Readers who are already familiar with how games are usually made may notice that this is starting to look a lot like the iterative development process. Does this mean that we've arrived at our answer for a design-oriented, game development workflow? The way that we've reached this point gives us the perfect theme that we've been looking for, in the form of a single-step process:

1. Follow the usual design process, but don't take iterations for granted.

Is the iterative development process really this simple? While this may not look like such a big discovery on the surface, just having this one idea being at the center of your workflow is the key to making the process become invisible. Rather than consciously thinking about what you have to do in order to follow the process correctly, your thoughts are focused on your work while you follow the process naturally and intuitively.

There are dozens of ways to break down this theme into a more concrete series of steps, and you'll probably find a way that works best for you. But since we're emphasizing the scarcity of iterations, our second description of the iterative cycle seems like a good fit:

1. Find some of the most important risks to mitigate (Evaluate),
2. Figure out the fastest way to mitigate those risks (Plan),
3. Do it, and then go back to step #1 (Implement).

You may have noticed that this is just like the iterative cycle but with an extra step in the middle that essentially tells us to be really careful about wasting time. The first step has also been modified in order to make sure that we're solving design problems in the correct order. For example, you don't want to spend time making a few paper prototypes for a feature just to find out during the next iteration that it's too impractical to implement in code. This is actually a pretty easy mistake to make, especially if you're distracted by a low-priority design problem that's fascinating enough to make you want to solve it.

There's a lot more to learn about how to manage your iterations efficiently, but perhaps the most important thing that you can watch out for is to make sure that each iteration is made for the right reasons. If you ever find yourself making a prototype because you feel like that's what you're "supposed" to be doing, then that iteration is misguided and is more likely to be wasted. All iterations must be inspired by some legitimate form of curiosity, not by the process itself.