作者：Christopher M. Park

迭代游戏设计过程

关于之前所述内容，简要内容是我们在项目一开始就确定我们的“固定设计目标”，然后逐步进行雕琢。这非常贴切地形容出我们设计游戏的做法。我们起初先收集系列概念，及项目需要完成的内容，然后开始集体讨论设计过程，直到确定某些可行的内容。

只要我们握有看似稳固的设计方案，时间和人手足够，我们就会开始着手项目。这就是迭代设计的开始。首个设计通常存在瑕疵，鲜有趣味性，但它们非常有启发性。这些内容能够让我们知晓为什么其他设计师会这样或那样做，X机制是什么，或者为什么这对玩家来说很重要。这些设计帮我们创建技术模型，塑造美术和音乐风格。

除固定设计目标外，其他元素都可以调整，所以我们就会自由谈论各构思，这最适合有多位设计师的情况。我和Keith都会直接指出略显古怪或缺乏深思熟虑的内容，只是想看其他人的第一反应。若这是值得追求的内容，我们就会这么做，但若是没有价值，不妨让这一连串想法随风而逝。

我常常这么说，若设计方案显而易见，我们能够在项目一开始就想到，那么人人都可以进行设计。你可以先设定项目的方向，然后设定固定设计目标，但若你试图创建一成不变的厚重设计文稿，那么你制作的将是非常原始的游戏。所有优质内容都来自迭代过程，这需要时间及反复操作。对我来说，这就是独立开发者的意义所在：能够自由试验。

基于体验视角查看固定设计目标

AI War Fleet Command from diehardgamefan.com

另一查看固定设计目标的方式是基于玩家体验。我曾在其他帖子中说过，《AI War: Fleet Command》的固定设计目标是：

1. 《AI War》需以有趣且不费力的方式支持合作体验。

2. 《AI War》需具有持久性（游戏邦注：也许维持8-12小时），需要在前进中不断发展。

3. 游戏需在特定时间向玩家呈现众多可行选择，否则各游戏内容就会开始呈现相同感觉。

4. 游戏应奖励那些基于真正思考而非快速点击的操作，否则有些动作不利索的玩家就玩法享受其中。

5. 游戏不应存在“最佳路线”，否则就会逐步消亡。游戏需在各游戏内容中融入一定变化性和随机性，玩家需基于当前情境做出不同决策。

这些都是正确想法，都是描述我预期游戏体验的参数。这些固定设计目标非常重要，但这里还有更高层次的目标，我在此投以更多关注：游戏带给我的感觉是什么。

模仿感觉

我觉得任何独立开发者，在着手制作游戏前，都大致知道自己想要呈现什么体验感觉。通常这都具有模仿性：“我想要重现我首次体验《Ocarina of Time》时的感觉。”这是明确目标，所以只要游戏运作的真正机制有所不同，就不能说最终作品与《Ocarina of Time》存在许多共同之处。我们谈论的是《Ocarina of Time》的影响，而非纯设计理念。

当然这可能会带来这样的作品：设计师只是想要模仿原生作品的形式，希望感觉能够随之显现（游戏邦注：但这完全不可能，所以根本就是浪费时间）。

模拟现实生活

另一创建游戏主要固定目标的方式是考虑游戏以外的元素。例如，设计高尔夫电子游戏的设计师定试着制作出具有真正高尔夫比赛感觉的内容，而非类似于Tiger Woods比赛的感觉。这些人肯定喜欢打高尔夫，想要感受数字游戏中的比赛会是什么样子。

就《AI War》来说，只要确定游戏在空间中的样式，我就知道游戏想要呈现什么感觉：我希望自己能像Ender Wiggin。我希望自己表现的很聪明，具有绝对人数优势，能够在任何情况下都取得胜利。也许有些令人惊讶的是，我在项目进展到一半时才想到运用非对称AI，但其他多人RTS游戏也没有采用此元素。

准备进行经验积累

在我雕琢《AI War》的时候，我发现游戏顺利实现很多小目标，但依然由于某种原因我没有从中感受到Ender的感觉。此时就出现经验积累桥段。迭代设计的一大优点是设定他人无法实现的目标，然后你持续朝此靠近，直到你掌握所有必备经历，让此实现。

另一类似例子就是漫步于曲折的长廊。你知道自己身处何方，会在何处结束行走，但你不知道中间的前进步骤。你会在前进中看到1-2个路口，此时你应做出能让自己离目标更近的决策，但你不是百分百确定。由于你需要同时查看众多路口，这意味着你需要投入时间，通过行走找到真正的正确路线，有时这会让你原路返回。

这里的原路返回不是什么悲剧或意外，这只是过程中的一部分。我并不觉得第一想法会是最佳方案。在我看来，对某内容知道得越多，想得越久，所想出的构思就越好。这就是迭代设计过程所采用的方法。

总结

你定很好奇《AVWW》的首要固定设计目标是什么。这款游戏的核心理念是：“我想在令人兴奋的危险而广阔空间中进行探索。”（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

More Musings On Iterative Game Design

by Christopher M. Park

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!（Source：christophermpark）