游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

以《人工智能战争》为例解析迭代设计的重要性

发布时间:2011-12-28 16:47:55 Tags:,,,

作者:Christopher M. Park

游戏设计常用的行业标准一般是首先制作出一份完整的“设计文档”来指导如何开发游戏。这种方法在比较大型的游戏开发公司是很有意义的,同时在发行商和投资商那里也能获得较好的评价,所以诸多现实问题导致了“设计为先”的游戏开发理论。

一些设计团队通过原型设计而避开这一方法,这种方法可以在设计文档产生的时候就产生一个产品的原型。原型设计过程中的修正,调整与新的功能添加会整合到最终的设计文件中,这通常会帮助开发出一款更加优秀的游戏。

对于拥有大团队的大公司,和那些需要迎合投资者、发行商、管理者来获得更多支持的公司来说,这(设计为先)或许是个不得已的好方法,但是作为一个独立开发者来说,这种模式(设计为先)肯定不是我喜欢的。

迭代设计的起点:目标

你不能漫无目的地着手进行一款游戏或者软件的迭代设计时。你必须明确一些固定的设计目标,并且包含一些最初设计理念,以此引导你的早期游戏原型设计。

AI War(from direct2drive.com)

AI War(from direct2drive.com)

例如在《AI WAR》(《人工智能战争:舰队指挥》)中,我在游戏原型设计工作开始前的好几个月就已经确定了固定的设计目标:

1.游戏必须支持一种轻松有趣的协作模式。

2.游戏时间必须够长——可能8-12个小时,并且必须随着玩家的前进而不断演变。

3.确保不管何时游戏都能够提供给玩家多种可行的选择,不至于玩家感觉游戏一承不变。

4.游戏不能鼓励那些快速点击鼠标而非进行深度思考的操作行为,否则就可能让动作不够利索的玩家受挫。

5.游戏中不可存在帮助玩家快速学习的“最佳方法”,在每个关卡中都需具有足够的可变性和随机性,而玩家可以基于自己所面临的现状做出不同决定。

除此之外,我还有一些可选择的设计目标:

1.理想情况下,游戏必须体现出即时战略游戏(RTS)的感觉。因为在即时模式下玩家不需要像《文明4》中那样陷入各种等待。

2.游戏可以采用回合制形式,强调象棋游戏中的视线(Line of Sight ,简称LOS),游戏整体能够体现出一些具有深度的战术和策略。

3.玩家的角色转换应该和进行的操作保持一致,以保证整个情节的向前发展。

4.游戏将发生在不同星球上,所以玩家可以在每个星球之间来回穿梭。

5.游戏将尽可能地突出1万个实时单位,并尝试与一些个体单位结合在一起创造出大规模的原始单位。

如果你玩过AI War,你将会发现游戏中保留了第1点和第4点的内容(尽管游戏中取消了无限空间的设置,并再次应用于后来的改进版本中),并且因为不适合游戏早期阶段的发展,而最终排除了第2、3点的内容。虽然经过证明第5点内容是可行的,但是后来的单位数量却比我原先估计的增长了3至6倍,如此导致原始单位也不再那么必要了(而我也因此多出了许多宝贵的开发时间)。

在长达7个月的游戏开发过程中也许还会出现无数可选择的设计目标,但是你必须清楚,这只是迭代设计过程中的一部分。

执行“固定”目标的两个案例

我总是难以取舍所有的固定设计目标。它们是游戏的核心设计原理,并且比起方法论更能够体现出游戏体验的感觉和类型。也许《AI WAR》的玩家看到这些设计目标会认为这都是我最初设定好的,但是事实却不是如此。以下我将列举出涉及固定目标的重要迭代设计过程的相关案例:

例子1:改变游戏的合作模式

问题:对于第1点,一个重要的次目标是尽可能让合作模式下的玩家不会在游戏初期“轻易被淘汰”,因为这会让玩家厌倦游戏内容,或者所有玩家一起放弃游戏而转战其它新游戏。通力合作的RTS战斗已经是一种老旧的游戏模式,而我真心希望能够改变这一模式。

背景:早期版本的《AI WAR》的核心单位是“旗舰”,是指一艘拥有强劲火力与防御功能的星际飞船(游戏邦注:后来被称为主力舰),但是如果它遭到破坏,你就会立即输掉游戏。而你也必须为了保护它而不断创造更多船舰。这与《AI WAR》中的“Supreme Commander”单位的功能类似。

AI War(from neogaf.com)

AI War(from neogaf.com)

初始设计方案:当旗舰遭到破坏时,它便会变成“旗舰核心”,即一艘较为疲软的舰船,并只能够制造出4至5艘不同类型的“核心”舰船。虽然这些舰船的数量有限,但是它们的破坏性却远远大于普通的舰船。如此,那些被淘汰的玩家便能够带着少数的核心舰船漫步在银河中,向任何一个方向的敌人发射攻击。

存在的问题:这个方案存在很多问题,如拥有一个超级强大的飞船单位会让游戏整体失去平衡,就像《AI WAR》那样。然而,最大的问题是,连接着其它舰船的“旗舰核心”并不能长时间带给玩家乐趣。这点便违反了固定规则中的第3点内容,即游戏中必须总是能够提供给玩家许多可行的选择。

最终解决方法:最后,游戏中的许多相关机制都发生了变化,并且“旗舰核心”机制也未得到落实。我们最终决定,只要玩家所在的团队还幸存,他就可以以正常标准继续玩游戏。

如果玩家失去了指挥站,他们便会遭受到经济上的惩罚(因为指挥站能够为他们创造大量资源)。但是即使在此,那些已死去的玩家的选择范围也不会相应减少。如果他们能够重新振作起来,并占领更多星球,他们便能够尽可能地弥补之前的损失。每一个团队的成功或失败都是以整体为单位,并且这种设置能够让玩家真正感受到相互协作的好处。

例子2:改变许多选择

初始设计问题:在《AI WAR》的初级阶段,玩家可以随时创造任何舰船。他们必须尽可能地获得每艘舰船的最高级别,并且在这里也未限制任何可能的舰船类型,所以玩家在任何时候都可以从30种不同类型的军舰中做出选择,还有各种类型的炮塔,防御战舰等。

而这种做法将会导致那些数量游戏的初期测试者出现“分析疲软”状态。因为游戏中不管在什么时候都存在着太多具有不同因素的选择。所以面对这种情况的玩家便会更加倾向于较少的舰船类型,或者构建一些随机的舰船组合。而不管出现哪种情况,都会破坏游戏中舰船构造的游戏机制。

最终解决方法:事实上,是我的父亲建议我限制游戏一开始时的舰船数量。虽然我一开始极力抵触他的建议,认为这么做违背了我的固定目标第3点内容,但是在经过漫长的设计讨论后,我意识到了这个建议的绝妙之处,然后我便着手进行相关调整,即在每个地图上都设定起始点(并且每个位置上都连接着相应的“奖励船舰类型”)和先进研究站。

这便是针对于整体游戏所作出的一个基本改变,并且让游戏更加接近于我们现在所看到的最终成品。我总是希望能够创造出一款对玩家毫无约束的游戏,以便玩家能够按照自己的想法构造自己的游戏世界,但是我却未能做到这一点,因为我在游戏中为玩家提供了许多绝佳方法(而这违背了固定目标的第5点),可以说,在该解决方法出现之前我一直在从其它角度去解决这一严重的问题。

所有内容相互关联

在第二个例子中,我们发现一个解决方法能够同时解决一大堆问题,包括一些毫不相关的问题。而第一个例子中揭露的一些行动步骤更是我难以从设计文件中获得的宝贵经验。

从根本上来说,这就是迭代设计的巧妙所在:你以一个良好的初始动机以及合适的基本规则开始设计游戏,但是一开始你可能只是创造出一些有瑕疵的内容。随后你很快就有一个可行的原型,这就是产品,虽然不是个有趣的产品。但是你却可以开始尝试它,并找出它的优劣处。通过测试,你也可以发现那些可行和不可行的元素。

但是最重要的还是,你可以在这个过程中看到各种相互作用的理念。《AI WAR》是一款非常复杂的游戏,基于许多不同但却相互关联的复杂系统。虽然我自认为是个聪明之人,但是我却难以提前想象到游戏中的各种发展。并且我也难以从其它类型或者其它模式中找到这种复杂关系的根源。很多答案我们只能够通过测试获得,但是也难以立刻获得答案。

创造一款复杂且具有创造性的成功游戏必须基于不断的修改与完善。如果你想要创造一些新内容,你就必须谨慎第处理那些隐藏的问题和陷阱。如果你从未犯过错,或者你能够完美地实践所有观点,那么只有两种情况,要么你是个非常幸运的人,要么你缺少足够的创造性。实际上,创造性也需要有针对地做出不同改变,而这种改变更不只是一两次的尝试。

在迭代设计过程中,你必须反复地修改与完善,直到所有的内容都能够融洽地联系在一起,不断修改每一个问题,直到它们都能够合理地组合成一个整体。在这个不断迭代的过程中,你可能会挖掘出一些全新的特征。

难以预料的情况

我认为,AAA级游戏应该拥有可靠的游戏模式,以及某些变化模式,并且不需要完全基于最初的设计文件内容。因为不管是个人还是团队,我们都难以预测任何测试反馈。

我想通过两个比喻论述预先设计这一难题。第一个是关于一条无止尽的曲折长廊,你永远只能够看到第一个拐弯点,而看不到其它的。所以你根本不可能预先计划自己的路线,因为你只有到达每个拐弯处,你才知道前面的路是什么样的(就像迭代设计)。

另外一个比喻是象棋。假设你在玩一款纸牌版本的象棋游戏,而你可以通过部分猜测对方的行为并进行移动。象棋游戏的设计非常复杂,其中包含了无数次的“移动”。在游戏的初始阶段,你可以信心满满地规划自己的移动,但是随着游戏的进行,你便越难以掌握整个棋盘局面了。因为游戏中将会出现越来越多变量,特别是当你开始问自己“如果我走X而不是Y会怎样?”,你会发现,游戏中的一切元素都在变化。

象棋这个例子很明显,因为我们都知道玩象棋需要一定的技术水平。而预测一款具有创造性且高难度的游戏发展也需要非常强大的计算机能力,而我认为很少有人能够做到这一点。人们能够做到的只是在一些不断变化的领域中做出改变,而某些改变也是基于游戏测试和游戏发展而来。当然了,有些具有创造性的游戏并不会太复杂,玩家完全可以预测到游戏的发展。但是,对于我本身以及一些机敏的设计师/程序员来说,我们都受不了预先谋划所带来的那种精神压力。

即使是象棋高手最多也只能够预见12步至14步的移动。世界上最厉害的游戏玩家最多也只能够预料到对手对于他们每一步前进的反应。而这也没什么不好,如此我们才能够更进一步探索那些未知的世界。

结语

预先规划的确能够帮助设计师获得许多创新元素,虽然我主张迭代设计,但是我也不否定那些采取预先设计方法的设计师,游戏设计的方式不止一种,而我所提倡的迭代设计也并非唯一有效的方法。

但我认为,游戏设计师可以拥有一些初始目标,并通过适当的迭代设计过程接收更多的数据反馈,从而获得更多具有创造性的理念。设计师如果能够在设计初期获得更多有效数据,便能够创造出更加优秀的设计。

游戏邦注:原文发表于2009年10月5日,所涉事件和数据均以当时为准。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Iterative Game Design The Right Way

Christopher M. Park

The industry standard way of designing games is to do so in advance, crafting a hefty “design document” that is basically the bible of how the game will be created. I can see the value of this when working with a huge team of staff, and certainly I can see the value of this when trying to get funding from a publisher. Many times the various realities of the industry simply dictate the designed-in-advance methodology.

Some design teams try to circumvent this a bit by prototyping — basically, while the design document is being crafted, a prototype is also being developed. Revisions and alterations and discoveries during this prototyping phase are then integrated into the final design document, and this almost invariably is going to result in a better end product.

For a large company with a large team, or for a company that must take their design ideas to investors, or a publisher, or management, in order to secure funding for a new IP, I can’t think of a better way to handle this. But, boy oh boy, does this make me happy to be an indie.

What Iterative Design Isn’t — And What I Mean By “The Right Way”

On the surface, it must seem pretty arrogant of me to proclaim that my way of iterative design is the “right” way, against all comers. To be fair, I don’t think this is the only valid approach, but the benefits are many and I’m basically just cross-applying some concepts from the larger pool of software development thought. It’s very much similar to Rapid Prototyping, or Agile Software methods, or to a certain extent Extreme Programming, etc. My background is in business programming, and these sorts of methods are much more common there — I’ve been using and refining my own shade of agile programming in a professional environment for about seven years now, and all I’ve done is carry it over to game design.

So what’s this “right way” business, then? Well, I think that iterative design has, in certain circles, become shorthand for “lazy” or “unprofessional.” As in, the designer just sits down without a plan, and cranks out whatever comes to mind. The end result of such an endeavor is rarely good, and/or generally isn’t very cohesive or original. It’s like sitting down to create a chair out of a bunch of wood, and just starting on the first leg without any plans or advance thought, then moving on to each other leg and the rest of the chair as you come to it. The end result is unlikely to sit particularly level, and for that matter the style of the later legs is likely to be subtly or majorly different from the first leg.

If that’s what you think iterative design is, no wonder you’d look down your nose at it. I have similar disdain for such a method as unprofessional and unlikely to work in a real production environment. Sure, there might be outlier successes using such a method, but that’s more luck than anything else. Fortunately, what I just described isn’t iterative design.

A Starting Point For Iterative Design: Goals

When you set out to iteratively design a game, or any other piece of software for that matter, the most important thing is that you don’t start with a completely blank slate. You must have some sort of immutable design goals, and these are ideally paired with some initial design concepts that will guide early prototypes.

In the case of AI War, for example, here were my immutable design goals, which I set several months before starting on the AI War prototype:

1. The game must support co-op play in a way that is fun and painless.

2. The 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.

Additionally, here were my soft design goals (amongst a few dozen other lesser ones):

1. Ideally, it should have the feel and general controls of RTS. Also the realtime nature, i.e. no waiting for other players to do something as often happens in CivIV.

2. The game will be turn-based, with an emphasis on Line of Sight (LOS) as in Chess, to provide extra depth to tactics, and more strategy to the game overall.

3. The turns for players will be simultaneous, with “action points” being granted over some interval, to keep things moving.

4. The game will take place across multiple planets, with infinite effective play space around each planet.

5. The game will feature around 10,000 units in realtime, if possible, most likely with individual units combined into larger ur-units (“strike groups?” that are moved around as a single entity).

As AI War players will note, numbers 1 and 4 were kept (although the infinite playspace was removed and then reimplemented in a revised manner post-release), while 2 and 3 were completely discarded as nonviable rather early in alpha. #5 turned out to be vastly more feasible than I had anticipated, and the unit counts grew to 3x to 6x my original max estimation, making the ur-units completely unneeded (and thus saving me some valuable development time in being able to skip their implementation).

There were hundreds, perhaps a thousand or more, other soft design goals that rose and fell during the 7 month development cycle of the game, but this was just part of the iterative design process.

Implementing The “Immutable” Goals, Two Examples

In looking at my immutable design goals, not one did I have to deviate from. These were the core design tenets for the game, and spoke more to the feel and style of the experience than a particular methodology, after all. Experienced AI War players might look at that list and think of the specific end implementation that I arrived at and think that the end implementation is what I had in mind from the start — but that’s not true at all. Some examples out of the hundreds, nay thousands, of important iterative design processes relating to these immutable goals:

Example 1: Co-Op Play Shifts

Problem: For #1, an important sub-goal was that co-op players would never be “out of the game” early, because that would lead either to boredom on the part of that player, or, more likely, to all the players giving up and starting a new game. Having played other RTS skirmishes cooperatively for years, this was the age-old pattern that I really wanted to break.

Background: Early versions of the AI War alpha had the central unit of the game as the Flagship, a mobile starship (then called a capital ship) that had high firepower and defenses, but which was also what caused you to lose the game if destroyed. It was also what let you build most other ships (it was basically replaced by the Home Orbital Command Station, if you are familiar with the release versions of AI War). This also functioned kind of like the Supreme Commander unit in the title by the same name.

Initial Design Solution: When a flagship is destroyed, it turns into a “flagship core,” a weak ship that can nevertheless produce a limited number of four or five different kinds of “core” ships for the player, which are devastatingly powerful compared to normal ships but fewer in number. The players-who-are-out thus get to roam the galaxy with their small core of ships, wreaking havoc and causing problems for the opposing players wherever possible (note to AI War players: all of this was before the AI was asymmetrical, and thus before “core” ships took on Mark V status).

Problems With The Initial Design: The problems with this were many, and were interrelated with a whole host of other problems such as the fact that having a powerful, mobile “king” type unit was strategically unbalancing and too similar to Supreme Commander. However, the biggest problem was that playing as the “Flagship Core” with its associated ships was not very fun for very long. This violated immutable rule #3, of always having lots of options open to the player at all times.

Eventual Solution: In the end, many of the related game mechanics shifted, and the concept of the Flagship core disappeared entirely. I did not relish the thought of having to create an entire duplicate tech tree just for deceased players to use (to keep to immutable rule #3), so the decision was to let deceased players keep playing completely as normal so long as their team is surviving.

There is an economic penalty to losing your home command station (since it produces a high number of resources), but the options available to the deceased players are otherwise not diminished. If they are able to fight their way back up and claim some more planets, they can replenish their lost income and more. Each team wins or loses as an entire unit, which makes perfect sense for co-op and was one of those “it’s so obvious why didn’t I think of that before” moments when it later occurred to me.

Example 2: Number of Options Shifts

Initial Design Problem: For most of the alpha phase of AI War, any player could build any ship class at any time. They had to unlock more advanced versions of each ship type as they went, as now, but the available ship types were not constrained and so there were 30 distinct classes of mobile military ship available to the players at any given time, along with all of the classes of turrets, defensive ships, etc.

This, as you may expect, caused “analysis paralysis” in even the alpha testers, who were very experienced with the game. There were far too many options with too many factors to weigh at any given time. So players tended to gravitate to a few ship types they preferred, building only them, or they tended to just flail about building a random mix of ships. In either case, the strategy was all but killed for ship-building.

Eventual Solution: It was actually my dad who suggested limiting the number of ships available at the start. I was vehemently opposed to the idea at first, believing that it conflicted with my immutable rule #3, but over the course of a wide-ranging design discussion that lasted several hours one Sunday in late March or early April, I came to see the wisdom of what he was suggesting and added several twists of my own — the per-ship-type-and-level caps, the method of having start positions per map seed (with “bonus ship types” tied to each location), and the Advanced Research Stations.

This was a fundamental shift to the entire game, and really brought it into focus and made it very close to the final product that is now available. I had been so focused on creating a game without constraints on the player before that point, so that players could build their own civilization as they saw fit, that I failed to see that this very lack of constraints also fed into creating best paths for players (in violation of immutable goal #5), a severe problem that I was wrestling with through other angles until this solution was suggested.

A Point When Everything Comes Together

In the second example in particular, you can see how one solution solves a whole host of problems at once, including some problems that seemed unrelated to the issue at hand. In the first example, you can see some examples of how playtesting revealed an “obvious” course of action that never would have occurred to me just staring at design documents.

Basically, here’s how iterative design works: you start with good intentions, and some good basic rules, but you create something that is (at first) horribly flawed. Of course, it is horribly flawed, it was only designed in the loosest sense. However, you very quickly have a prototype that works, that is a product, if not a very fun one. But you can start playing it, and you can see what is fun and what is not. With playtesting, you can sometimes even see why certain things work and others do not.

But most importantly, you can see how all of the various ideas interact. AI War is an exceedingly complex game, built upon many different complex interrelating systems. I’m a smart guy, but there’s no way I could ever have conceived of all of that in advance. There are simply no other models in the genre to point to for a lot of this stuff, and the interrelationships are all too complex.

There are too many nth order effects that only come up through playtesting, and which don’t always even come up immediately then.

Building a successful game that is highly complex and innovative is an exercise in constant revision. There are too many hidden problems and “gotchas” if you are trying to push the envelope and do something new. If you never stumble, if you never hit upon an idea that does not work, then you are either very lucky or not really innovating all that much. Because, the fact is, if you innovate in one area, that pretty much requires changes in other areas. And those secondary changes require tertiary changes, etc.

With iterative design, you can work and work and work until the point where everything comes together, twisting and turning each puzzle piece until the ones that fit together have created a beautiful mosaic. Not quite the mosaic you set out to create, but within certain bounds, and with a lot of never-before-seen qualities to it.

You Can’t See Around Corners

My theory is that AAA games stick to tried-and-true gameplay models with slight variations largely out of a need to manage these nth order effects in those original design documents that are so prized. It’s just too much complexity for any individual or even team to manage in advance of any actual playtesting feedback.

There are two main metaphors I like to use for this conundrum for up-front designs. The first is the image of a twisty hallway that stretches off into the future. You can see to the first bend, but no further. Planning your route in advance is nearly impossible, because you can only see around each corner as you come to the corner that precedes it (as in iterative design).

The other metaphor that I like is that of Chess. Let’s say that you are playing a sort of solitaire version of Chess, where each move you make has some sort of semi-predictable opposing reaction.

You make a move, and the opponent makes a predictable corresponding move. A game of Chess, like the design of a game of any significant complexity, is going to comprise hundreds of “moves.” You can plan the first few with confidence. But as you get further and further into the future, it becomes harder and harder to keep the board state in your mind. There are simply too many variables, especially if you start wondering “what if I did X instead of Y” 5 turns back? That changes everything.

The Chess example is easy to grasp because we all know the supercomputing power required to play Chess at an expert level. Planning the whole of a highly original, complex game in advance requires a similar magnitude of computing power, and I posit that no human can do it. The best anyone can manage is some evolutionary steps in a variety of areas, possibly with some unexpected twists thrown in as data is gathered through playtesting and development. Granted, some highly original games have a lower base complexity, and can be planned out completely in advance. But, for myself at least, as well as many other agile designers/programmers, the idea of all the mental stress and strife involved in such an exercise in advance planning is just too much to bear.

A Chess Grandmaster can look 12 to 14 moves ahead, but that’s all. Asking even the best in the world to plan the entire game in advance, even if they knew how their opponent would definitely react to every move, is just too much. This isn’t slackness, it’s expediency and a desire to explore the unknown.

In Conclusion

Advance planning can indeed allow for the designer to come up with a number of innovations — even major ones. It happens all the time. My point is not to insult other designers who plan in advance (indeed, I’m in awe of the mental fortitude it takes to balance that many variables with little or no feedback). There is more than one way to design games, for that matter, and I don’t begin to suppose that my method of iterative design is the only valid way.

But rather, I posit this: given the same designer with the same initial goals, that designer will produce more innovation via a properly-managed iterative design process with continual feedback than they would trying to design in advance with nothing but self and peer conjecture for feedback. I contend that better data to the designer, earlier in the design process, will lead to better designs. Iterative design probably isn’t the only way to arm the designer with that sort of data (extensive past experience is certainly another valid route), but it’s a simple and effective method, and one that I think is erroneously scoffed at. AI War wouldn’t exist as you know it without iterative design, and that’s no joke.(source:christophermpark


上一篇:

下一篇: