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.
