Well, back in Part One, I promised my perspective and methods on iteration in Part Two, but I took a detour to write about feedback since it's often overlooked and given a back seat to fidelity. Anyhow, I'm back on track with iteration.
Most of the game dev world agrees that iteration is the correct way to make good games. The more time we have to iterate, the better our games are. There's a dirty secret that designers don't like to admit. Iteration automatically assumes that we are wrong - otherwise, we would have no need to iterate. Most designers, including myself, love to be right. But embracing iteration as a development method means we must assume that we will be wrong multiple times before getting it right.
Iterative design in the hands of an always-right designer can be a bridge-burning overtime-crunching game-killing nightmare! The always-right designer doesn't design a system to handle the possibility that he might be wrong, and specs out all aspects of a system to painstakingly perfect detail. When the programmers, animators, and artists are done, and the game isn't fun, the always-right designer has no proper understanding of why. This is because the system came online in uncontrolled waves based on whatever was done first, or because he believed that everything would be right when all the parts were completed, and he didn't pay attention to the problems until everything came online. The always-right designer also doesn't have a sense of responsibility for why the system is wrong, and has no problem starting over from scratch with a completely new idea while relying on "Iteration" as an excuse for wasting everyone's time.
Iteration is like a number guessing game, where we make our best guess, determine whether we are higher or lower, and then guess again. The best designers understand this, and design systems so they can make new guesses quickly. Technically, this is a binary search pattern. Personally, I learned this strategy in 1990 by playing Teenage Mutant Ninja Turtles: Fall of the Foot Clan for GameBoy. At the end of each level, Master Splinter gives you 9 guesses to guess a number between 1 and 99. With each guess, he lets you know if the number is higher or lower. If you guess the number, you get extra lives. I couldn't beat the game without the Splinter bonus, so after a series of mixed successes by randomly guessing, I quickly learned that if I always guessed half of the value range, I would always guess the number. The only reason I write about this is to get an excuse to put an image on this post:
OK - I am oversimplifying just a tad. Iterative design isn't really like a number guessing game. It's like an array guessing game, and instead of a number, we're trying to find fun. And instead of "higher" or "lower" we often don't get anything at all!
So us designers don't know have to know everything, but what we do need to understand is when to add or remove each part of a system, and when to turn the knobs.
In practice, whenever I begin working with animators, artists, programmers, audio, etc., I always make it a point to let them in on the dirty secret of iteration: That I will be wrong, and I'm only guessing. But also that I value their time, and I my decisions are always based on getting the game to be fun in shortest possible path.
Next post preview: Filtering feedback on the dev side, so you can be as responsive as possible. See what I did there?
I look forward to "part 4" -- maybe you can chat a bit about incorporating user feedback into your iterative process ;)
I've added your blog to my RSS feed.
Cheers,
Schklar
Posted by: Jason Schklar | February 23, 2009 at 01:55 PM