More Musings On Iterative Game Design

I've written before, in depth, on my process for iterative game design and why I use it.  That blog post was a year and a half ago, however, when it was just Pablo, Phil, and myself and we hadn't even started working on the first expansion to AI War yet.  I was the only game designer on the staff at that point, and the only programmer, and none of us did this fulltime.  Then our game came out on Steam and Direct2Drive and changed all that.

So!  Seems like it's time for an update about iterative design, especially in light of our major design shift for AVWW last week.  After all, now I've had the pleasure of working with a Lars as lead designer on the Tidalis project (while taking the role of producer), and with Keith as my co-designer on the AVWW project.  And we've put out three expansions for AI War, the second two of which were co-designed with Keith as well.

What's Changed Since The Last Blog Post?
Despite all the changes to the company, to my life, and to what projects we're working on, the process actually hasn't changed one iota.  This is surprising even to me, honestly.  But it's the nature of why we were able to make the shift to side view in AVWW, and why it wasn't as ballsy a move as some people seemed to think it was (though we appreciate the kind words on that score).

Our Process, In Brief
If you want the hugely detailed post, check out Iterative Game Design The Right Way, my original post that I linked to above.  But the short of it is that we decide, at the start of the project, what our "immutable design goals" are, and then start chipping away at the 'ol block of marble.

As the joke goes, you just have to "chip away everything that doesn't look like an elephant" to carve an elephant out of a block of marble.  That's really an apt description of what we do.  We start with a collection of ideas, things that the project absolutely must accomplish in some manner, and then we start brainstorming designs until we have something that seems likely.

Once we have a strong-enough-seeming design, and the time and manpower lined up, we start on the project.  That's when the iteration begins.  The first designs are always flawed and rarely fun, but they are illuminating.  They teach us why other game designers probably did this or that, and what mechanic X or why means to the player.  They help us build a technical prototype, and form both an art style and a musical/sound style.

Nothing is sacred except those immutable design goals, so we wind up having a very free discussion of ideas that actually works best with multiple designers.  Keith and I both freely suggest things that are outlandish and half-thought-out, and just get the others' first reaction to it.  If it seems like something worth pursuing, we do, but it's also perfectly natural to let such trains of thought just fade once they've shown they aren't worth it.

I always like to say that if a design was so obvious that we could have thought of it right from the start of the project, then everybody would be doing it.  You can set a direction for a project at the start, and you can and should set immutable design goals, but if you try to create a massive design document that is set in stone, you're not going to make a very original game.  All the best stuff comes out of the iterative process, and that takes time and iterations.  To me, this is what it means to be an indie: this freedom to experiment.

An Experienced-Focus Way Of Looking At Immutable Design Goals
Another way of looking at immutable design goals is based on the player experience.  In my other post, I said that my immutable design goals for AI War: Fleet Command were:

1. AI War must support co-op play in a way that is fun and painless.
2. AI War games must be long -- 8-12 hours perhaps -- and must continuously evolve as they progress.
3. There must be a huge number of viable options available to the player at any given time, or every game will start to feel the same.
4. The game must be designed in such a way that it does not reward fast-clicking over real thought, or my dad (and players like him) will not really enjoy it.
5. There must never be a "best path" for players to learn, or the game has just died. There must be enough variability and randomness in each game that players must somehow have to make different decisions based on the current situation.

And those are all true.  Those were the parameters of how I wanted to play the game.  But that's also like describing how an elephant is posed, not what an elephant actually looks like (awkwardly returning to the carving-an-elephant analogy from above).  These sort of immutable design goals are important, but there's an even higher order of goal that I pay even more attention to: how does this game make me feel.

Imitative Feel
I think that any indie developer, when setting out to make a game, has an idea of what they want it to feel like to play that game.  Often it's imitative: "I want to recapture that feeling I first got when I played Ocarina of Time."  That's a specific goal, and so long as the actual mechanics of how your game works are sufficiently different, it's not to say that the final game will have much in common with OoT.  We're talking about the impact of OoT, not its literal design.

Of course, that can result in games where designers simply try to imitate the form of the original game in hopes that the feel will follow; it never does, so that's a waste of time.  But that's a whole other discussion that I won't get into here.

Art Imitating Life
Another way to establish the primary-immutable-goal for a game is to think about things outside of gaming.  For instance, people that design golf video games are presumably trying to make something that feels increasingly like the real game of golf , not something that gives them the feel of the Tiger Woods games.  These people presumably like playing golf, and want to capture what that means in the form of a digital game.

In the case of AI War, once the decision was made to set the game in space, I knew exactly what I wanted the game to feel like: I wanted to feel like Ender Wiggin.  I wanted to feel clever and outnumbered and to win against all odds.  It's surprising, perhaps, that the idea of an asymmetrical AI didn't occur to me until halfway through the project, but there you go -- it wasn't something any other multiplayer RTS game had ever done.

Setting Yourself Up For Epiphanies
At some point as I was chipping away at the game of AI War, I realized that a lot of my smaller goals were being met, but that I still didn't feel like Ender for some reason.  And that's when the epiphany hits.  That's the big benefit of iterative design, is that you set yourself a goal that nobody else has ever accomplished, and then you keep working closer and closer to it until you have all the epiphanies you need in order to make it happen.

Another analogy I like to use is that of walking down a long and twisty corridor.  You know where you are, and where you want to end up, but you don't know all the intermediate steps.  You can see around a corner or two as you go, and can make decisions that should take you closer to your goal, but you can't know absolutely for sure.  Since you can only see around so many corners at once, that means you have to put in the time and do the walking to really find the right path; and sometimes that leads to backtracking.

Backtracking, in this sense, isn't a tragedy or even a surprise, it's just part of the process.  I'm not one of those people who thinks that the first idea I have on a subject is the best I'll ever have.  I rather think that the more I know about a subject, and the longer I think about it, the better my ideas about it will become.  That's what the iterative design process takes advantage of.

Conclusion
You might be wondering what the overarching immutable design goal was for AVWW -- after all, it started out as a post-apocalyptic top-down game and is now a purely-fantasy side-view game.  The core idea of that game is and always has been "I want to go adventuring in an exciting, dangerous-feeling, infinite world."

This is an elephant that we're still very much chipping away at, but I think you can probably see via our regular videos and developer journals how this sort of process evolves: we mention most of what we're working on, so you see some features appear and then later disappear.  That's the process of walking down these corridors and finding out which ones really lead us to the end destination we're striving for.

Anyway, it's a process that I very much believe in and that I think others should use.  So far it's worked every time for us!