Arcen Forums

Other => Game Development => Topic started by: x4000 on June 25, 2011, 09:22:42 AM

Title: More Musings On Iterative Game Design
Post by: x4000 on June 25, 2011, 09:22:42 AM

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.

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!
Title: Re: More Musings On Iterative Game Design
Post by: Nalgas on June 25, 2011, 03:23:17 PM
It's interesting to see how the core principles can stay exactly the same while the form they take can shift subtly or dramatically over time, and how the process for making that all happen has managed to stay exactly the same throughout all of that.  I've used aspects of that myself, but I don't know if I've really sat down and thought of it as formally as that, which I probably should more often.  Heh.

Speaking of heavy iteration to refine ideas and figure out what actually works and what doesn't, have you seen anything about Jamestown, like this article (  They seem to be big fans of that approach, too.
Title: Re: More Musings On Iterative Game Design
Post by: Nalgas on June 25, 2011, 06:08:07 PM
My mind wandered in the shower (it takes a while to wash my hair), and I thought of a couple more things.

One is that it'll be interesting to see a similar comparison of what the "set in stone" design goals for AVWW are and what the lesser ones are that have survived and/or didn't make it after there's a public version of it and they don't have to be kept A SECRET TO EVERYBODY so they don't ruin the surprise.

The other is about that style of design in general.  I know it gets a lot of crap, and I actually think it deserves it a good deal of the time.  It's unfortunate, because there are a lot of good things about it, but there was that period of time where it was really trendy and got really hyped, and a lot of managers tried to force it on people whether they understood how to apply it or not or whether it was useful in their situation or not or whether their employees worked well that way or not, and it generated a lot of backlash.  When used properly (e.g. actually having a solid starting point and goals set out instead of wandering off aimlessly) on a project that can actually benefit from it, I'm a big fan of the kind of refinement of good ideas and weeding out of bad ones it can generate, but I totally get why a lot of people are wary of it.
Title: Re: More Musings On Iterative Game Design
Post by: x4000 on June 27, 2011, 09:23:11 AM
Neat on Jamestown -- had not seen much about it before, thanks for the link!

I think that waterfall/agile/rapid development techniques in general get a lot of crap in the business realm because they are applied to completely inappropriate problems.  If you need a hammer, you need a hammer, but if you really need a chainsaw telling someone to use a hammer is not going to go over well.  And I think that's the big problem with most of these fad management ideas -- not that they are bad, but that they get over-applied.

Our immutable design goals for AVWW are broadly summarized as:

1. AVWW must feature infinite worlds that are interesting, full of danger, and fun to explore.
2. AVWW must support co-op play in a way that is fun and painless.
3. The game world must really feel alive and evolving in as many ways as possible.
4. The past actions of players should really matter, and should carry forward into affecting the future of the game world.
5. The actual adventuring aspects need to feel tight and fun, and should have as much tactical depth to them as possible (never button-mashing).
6. The overall world activities should have something of a strategic flair to them, with long-term decisions mattering as in AI War.

And that's basically it.  Things like crafting, the deeds system, and even permadeath aren't really goals in themselves, they are just a means to the above ends.  If we thought there was a better way to have a meaningful evolving world without permadeath, then we'd axe permadeath.  But at this stage there's just no chance of that happening, because it works so well.  Same thing for things like crafting: that's not a goal in and of itself, but it is a very nice mechanic that enables all sorts of things and that conforms to our central goals.  I don't think there's any possible way that is better to do it, or at least not that I or anybody else has thought of so far in gaming.

So really, the barest blueprints of the immutable design goals are not particularly spoiler-ful because that are by very definition quite broad.  What's the best way to make the world feel alive?  We try the first best idea that we have, and then let that evolve and/or build on new ideas on top of that.  And so on.
Title: Re: More Musings On Iterative Game Design
Post by: Nalgas on June 27, 2011, 12:19:47 PM
So really, the barest blueprints of the immutable design goals are not particularly spoiler-ful because that are by very definition quite broad.  What's the best way to make the world feel alive?  We try the first best idea that we have, and then let that evolve and/or build on new ideas on top of that.  And so on.

Yeah.  I guess I was kind of also wondering what the things are that have stayed the same and what have changed radically, like the soft design goals section for AI War in the original article, but those might be a little less nondescript.  It's kind of funny looking back at those now after even longer to get used to it in its current state, though.
Title: Re: More Musings On Iterative Game Design
Post by: x4000 on June 27, 2011, 12:22:46 PM
Yeah, we'll have to write up stuff about what's changed in the soft design goals stage, but probably not until post-1.0.  The obvious things being the setting, the focus on traps that used to be there, the inclusion of melee weapons and such, the general perspective, etc.  But there's an incredibly long list of such things, really.