on iterative design
Most paper-based game designers follow an iterative design process, but most digital game designers do not. Typically, a commerical computer game is copiously designed in advance, with extensive storyboards and design documents often hundreds of pages long, completed before any any actual game production begins. These documents invariable become obsolete as soon as production development starts. Why? Because the the play of a game will always surprise its creators, particularly if the game design is unusual or experimental.
I've just received a copy of Rules of Play: Game Design Fundamentals from the library and whew this is a great book. I have a lot of thoughts whirring through my head as I'm reading -- like ideas for game design projects of my own -- but one of the most analytically important is about the relationship between iteration and design. The authors Katie Salen and Eric Zimmerman argue quite clearly, "Learning how to design iteratively is the single most important skill that a game design student can learn" (15). Since I've started working as another kind of designer -- an instructional or learning designer -- I've felt a lot of discomfort with the level of pre-planning that is assumed in this field, from learning objectives to storyboards to highly detailed rubrics. In and of themselves, these design and evaluation tools all have their place, but I've found that some folks in this field expect that these tools deliver precision, stasis, and measurable results (grades -- another tool that I can't get behind, but that's for a later post).
The allure of learning design for me is not in planning precision but in designing a well-supported space for collaboration, exploration, and engagement. While we can know what we want to ask people to do, read, watch, or consider, we can't (fully) determine what they will learn until we run the activity or teach the course. Figuring out what students will learn comes from trial and error, and even then, we can't determine the connections they will make or what their experience of learning will be.
Creating storyboards, activities, or course planning documents that cannot change once production (or teaching) starts is no way to approach design. Salen and Zimmerman insist that a good game designer must test and iterate often as the act of playing a game (or trying a learning experience) is crucial to good design. They write:
"We have a straightforward rule of thumb regarding prototyping and playtesting games: a game prototype should be created and playtested, at the absolute latest, 20 percent of the way into a project schedule. If a game is a two-week assignment, the students should be playing a version of the game two days after it is assigned. If it is a commercial computer game with a 15-month concept-to-gold schedule, a prototype should be up and running three months into development--at the absolute latest" (12).
Maybe this book is just confirming my preferences for working on projects, but I do believe that it takes greater skill, intuition, and wisdom to work in this way: knowing that you can rely on others to test an experience, changing your thinking when you hit a roadblock, and believing that you can iterate your way out of any problem if you have the right people asking questions and taking risks.
Comments
What do you think?