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

阐述用白板设计替代游戏设计文件的方法

发布时间:2012-03-02 15:48:52 Tags:,,

作者:Andy Moore

我讨厌设计文件。我在编撰设计文件时碰到的最大问题是,最终可能会花费许多时间来编辑设计文件。

在我看来,游戏核心机制应当在1天的时间内构建完成。原型的润色只能耗费1周时间。如果你将整个周末的时间花费在编写设计文件上,而我将整个周末的时间花在制作机制上,谁的成果更好呢?你获得的是几张写满有趣理论的纸,而我拥有的是真正的趣味内容。

假设,我拥有个小团队,我将大量的内容存在自己的脑中。我用一些工具将数据记录下来,比如白板和制定待办事项列表。有人可能会辩解称,我所做的这种数据收集便是一得特殊的“设计文件”。或许,这种想法是对的。

有时候,你必须编写设计文件,因为其他人(游戏邦注:比如发行商或投资者)需要它。有时候,你需要用设计文件来换取政府扶助金。如果是这样,我很遗憾你需要将大把时间耗在编写文件上。有时,你拥有庞大的团队,所以你必须通过设计文件确保所有人达成共识。我认为这正是大型工作室开发游戏更耗时间的原因之一,因为大团队成员之间的交流效率较低。

我有时会使用白板,这种方法最接近于我心目中的“设计文件”。

图片说明

以我的文字游戏为例,它刚刚设计完成,内容还留在我的白板上。我从1月22日开始进行这款游戏的制作。

白板位于我桌子的左边,面对着我。在我开启代码IDE前,我拿起笔开始勾勒游戏主体架构。在大约10分钟的时间里,经过为数不多的修改,我得到了以下内容:

whiteboard(from andymoore)

whiteboard(from andymoore)

在游戏开发过程中,我或许修改过写在左下角的部分细节内容,但这块白板从游戏设计之日起从未更换过。

以下是对我们现在所看到的这幅图片的注解:

1、可以将其视为游戏想法的思维地图,我尝试将游戏的关键元素从脑中剥离,记录在白板上。我发现这样做确实很有好处,因为有时我会遗忘曾经想到过的某些关键元素。这也是我总是在随身带本笔记本的原因。

2、白板左半部分是游戏屏幕草图。这款游戏的目标很简单,你可以看到我在白板右边对游戏暂停等内容提出质疑。我发现,快速构建UI能够帮助我在脑中组件数据结构,帮助我正确地组织想法。如果我可以在白板上将“游戏玩法”划归为单个功能,我知道自己已经获得了易于构建的系统。

3、我草拟了游戏的基本玩法机制,就是右下方的文字内容。当我在脑中思考游戏玩法时,它绝不只是张图片。分解游戏玩法以得出这些组成部分是件麻烦事,相当于将机制分解成赤裸裸的元素。

4、白板右上方红色文字是我认为必须回答的关键问题,这样我才能获得可运行的原型,比如“格子应当设计成多大?”和“如果你的剩余字母无法发挥作用会怎样?”

我的方法与编撰标准设计文件的方法有如下不同之处:

1、制作这些内容最多只耗费30分钟时间。

2、我可以将白板放在桌旁,面对着我,在制作游戏过程中可以随时查看。

3、我从未更换白板,即便游戏玩法发生显著的改变。

更改核心机制

游戏玩法类似于《超级拼字》,但仍有所不同。你的角色将在格子上移动,而且你只能从角色当前站立点开始拼字。

看下我的最后两条游戏玩法元素,就是上图中右下角的绿色文字部分,你会注意到这两条描述了这种游戏玩法中的危险元素:

1、无有效移动 生命-1

2、移动到某些格子 生命+1

也就是说,假如你移动到角落而且无法找到新的拼写路径,那么你就会失去1个生命值。游戏将使用标准的模型,你总共有3个生命值,看看能够坚持多长时间。这样的机制看起来很不错,不是吗?

事实情况表明,即便设计了较小的棋盘,玩家也几乎不会遇到拼词障碍。玩家在游戏中总是可以找到合适的词汇。再加上偶尔会走到生命+1的格子,每个人最终都能够获得99个生命值,游戏永远无法结束。

事实证明,英语词汇是相当灵活的,我的游戏机制根本行不通。于是,我不得不转向使用基于计时的系统,移除生命值元素,添加计时器。最终,这种措施导致我在游戏中设置的许多机制和平衡机制发生改变。

这就是为何原型如此重要的原因所在,从设计文件上你看不出机制是否有效。你必须将其制作出来,而且必须尽快制作出来。

我本来可能会再花一周的时间来细化设计所有能够让玩家生命值+1的不同方法,并规划死亡动画,从音乐师处预定死亡音乐。但如果这样的话,投入的这些精力将完全浪费。

我将原始想法留在白板上,可以时刻提醒我游戏的核心简单性,提醒我游戏最原始的想法,提醒我游戏可以多么直观。如果我开始更改白板上的内容,很快就会陷入功能蔓延的困境。此外,将错误留在身边还能不断鞭策自己提升游戏设计技能。如果我将这些内容擦除,下次或许还会犯下同样的错误。

保持视觉风格稳定性

我在设计界面时,不只是绘制些许占位符逻辑盒。我在界面中花上了小企鹅,将部分UI元素添加到我认为合适的位置上,并设计富有特色的地图。以下便是游戏最终的界面:

Game UI(from andymoore)

Game UI(from andymoore)

看看这个界面,格子布局、企鹅主题甚至暂停键和计时器几乎与原先的规划相同。

保持风格一致性对我制作的游戏相当重要,有助于保持开发的一致性,使设计的背景显得更有意义。

我觉得编撰设计文件并非适合我使用的方法,以上便是我所用的替代方法。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Design Docs: Barf

Andy Moore

I hate design docs.

I’ve been co-hosting a radio show recently on GameDevRadio.net, where we talk about game develoment topics on a weekly basis. A few weeks back we discussed design docs, and I think I did a good job of denoting when a design doc is good or useful, and when it is bad and just a detriment to your team. Go take a listen! I’ll sit here and wait patiently, but you don’t have to listen if you don’t want to. After all, I have it.

Summarized:

My biggest problem with design docs is that you can end up spending more time editing the design doc than anything else.

In my little world of game development, a core mechanic should be built in a day. A polished prototype should take you a weekend. If you spent all weekend working on a design doc, and I spent all weekend actually making mechanics, who’s in a better spot? You have a bunch of papers with theories on what is fun, and I have hard evidence.

That said, I have a small team (of one, usually!), and I hold a lot of things in my head. I use a few tools to hold data externally, like white boards and to-do lists, and one could argue that the collection of those things is a strange type of “design doc” I am referring to as I work. Fair enough! You might be right there.

Sometimes you have to make a design doc, because some suit somewhere (publisher maybe? investors?) demand it. Sometimes you need one for government grants. If that is the path game dev is taking you, I am sorry for your lots. But sometimes you just have a large team, and you have to make sure everyone is on the same page. Cool! I get it, and I also think that right there (the inability to effectively communicate across your large team) is one of the reasons why bigger studios take so long to make games in the first place. But I digress.

I mentioned I sometimes use a whiteboard. It’s the closest I come to “design doc” in my mind, and I wanted to share it with you!

Again, with pictures!

So let’s take a look at my word game as an example; it’s fresh and still sitting on my whiteboard. :) Back on the Sunday that was January 22nd, I started working on the game. I got up relatively early that morning, and while my head was still mostly in the clouds, I went to my desk.

Just to the left of my desk, facing me, is a whiteboard. Before I opened the code IDE, I picked up a marker and started sketching. In about ten minutes, with only minor amounts of erasing, this is what I came up with:

I might have tweaked some of the written details in the bottom left corner throughout the day, but this whiteboard has not changed since day one of my game design journey.

Here’s my notes on the image as I am seeing it now:

This is mostly a mind-map of ideas, trying to get the key elements of the game out of my head and down on a hardcopy somewhere. I find it really helps to do this, as often some keystone element I once thought of is lost to the mists of my memory. This is also why I always carry around a moleskine everywhere I go. :)

The left half of the board is a simple flow chart of the game screens. One of the goals of this game was to be very, very simple and uncomplex; you can see me questioning things like the pause screen (“need this?”) right on the document. I find doodling the UI really quickly definitely helps me form data structures in my head, and helps me properly organize my thoughts. If I can compartmentalize “gameplay” to a single function on the whiteboard, I know I have a system that’s easy to build.

I sketched out what I thought the basic gameplay mechanic was going to be, in text on the bottom right. When I thought of the gameplay in my head, it was more of an image; breaking it down into these component pieces was an exercise in trying to boil the mechanic down to its bare elements.

The top right I sketched – in red – the key questions I’d have to answer before I could have a working prototype. Questions like “how big should the grid be?” and “what if your leftover letters suck?” Identifying where your problem areas might be early keeps your mind constantly checking for these cropping up (and searching for solutions). Sometimes it’s good to put a problem on a slow boil in the back of your mind.

Here’s where this might deviate from a standard design doc:

I spent a maximum of 30 minutes creating this.

I always kept it next to my desk, staring me in the face, every time I worked on the game.

I never altered it, even when gameplay significantly shifted.

Alteration of the Core Mechanic

The entire premise of the gameplay was that you were playing Boggle, but sort of in a first-person fashion. Your character would move around on the tiles, and you could only start spelling from where you were currently standing.

If you take a look at my last two gameplay elements – in green in the bottom right of the above image – you’ll notice two entries that describe the danger element of this gameplay:

No valid move -1 life

Certain tiles give +1 life

That is to say, if you walk into a corner and can’t spell your way out, you lose a life – and the game would use a standard “three lives, how long can you last” model. Sounds good on paper, right?

Well, it turns out that – even with tiny board sizes – the player almost never got stuck. There was always some obscure word to spell. With the occasional 1up laying around, everyone could eventual get 99 lives an the game would never end.

It turns out that English is entirely too flexible and my game mechanic broke. Very early on I had to switch to a timer based system – remove the lives, add a countdown clock, have it work that way. This in turn shifted many of the mechanics and balance mechanisms I had in the game.

And this is why prototyping is so important: you can’t know from a document what will work, and what won’t. You have to make it. And you have to make it as soon as possible.

I could have spent another week detailing all the different ways you could get 1ups, and sketching out death animations, and ordering death-music-samples from musicians – and wasted all of that effort on something that could never work.

I left the original idea on the board though – to remind me of the core simplicity of the game. To remind me what it was at first, to remind me how straightforward the game could be. If I start altering my whiteboard, I quickly get into feature-creep territory. Besides, keeping my errors up there, constantly glaring at me – keeps my game design skills humbled. :) If I just erase it, will I learn the lesson for next time?

Visual style remained solid

When I doodled out the interfaces, it wasn’t just drawing some placeholder logic boxes. I drew little penguin doodles in there, placed some UI elements in positions I thought would be good, and had a distinctive “style map” in place. Here’s how the game ended up looking:

Check it out. Same tile layout, same penguin theme, even the pause button and timers still in their original positions. About the only thing that changed here is the level of talent doing the doodling (Thanks, Sven!)

Having a consistent driving style is important to the games I make. It helps focus development down the same path, and sometimes things just “make sense” in the context given.

I didn’t have to beg Sven to keep penguins as part of the game. He looked at my initial sketches and just ran with it.

Anyway,

I think design docs suck for my purposes. This is how I do it instead. How do you keep yourself organized? (Source: andymoore.ca)


上一篇:

下一篇: