Friday, June 8, 2012

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.