I realized I wasn’t done from my previous post. I’m trying to work out whether Ben’s post makes me watch to change my own process. Heavier doses of playtesting is more useful for my process now, but probably does introduce its own turbulence.

agile and iterations and synergizing

My design process is obviously impacted by my experience in software development, which is unsurprisingly heavily “Agile”. This is a process that’s about lots of flexible, repeated iterations of work. Instead of emphasizing an ironclad design up front, you keep producing working prototypes and “iterate” repeatedly, adjusting your direction based on the previous iteration.

I know this provably produces quality software, but there are obvious limits. In terms of game design: sometimes what you create by only building part of a game is too limited to give you real feedback. (Imagine testing Mafia Wars if your iterations has nothing but the ability to buy and collect from real estate. Does this teach you much of use?)

Even when you’re creating agile iterations of a product, I’ve found some useful caveats. Its critical to have a strong vision of what you want (even if you are willing to change that vision); I’m distrustful with iterating in order to uncover a vision.

It’s also a very useful skills to be able to decompose the big, complicated system you invision into multiple steps/layers/tiers. This creates useful checkpoints in your design without requiring you to put it all together at once. You probably dont know what your overall game is like until you have it all in place, but it’s good to say that components A, C and D are basically stable, even if components B and E are in shambles.

real world

As it turns out, I’ve had some freelance software work that involves game design, and some of these discussions – when does playtesting work? how much design up front? – have come to the fore. I expect that my thinking on this will evolve in the next few months.