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

分析游戏系统的“GRIP”设计流程

发布时间:2013-11-16 11:01:34 Tags:,,,

作者:Mike Birkhead

设计不是一个线性过程。游戏不像精致的拼图那样是由一块块独立的拼图片拼成的,这让我们的管理者非常苦恼。尽管在拼图的心理意象中存在一些吸引人的东西,但追求好设计不是追求你认为可能合适的那一个拼图片,除非你找得够努力。心理意象和现实之间的缺口让我们这些从事游戏设计的人非常失落,但最让我们苦恼的还是制定计划和进度。

你可以把设计过程分成详细的部分,但如果你认为过程就是线性步骤,那你就错了。设计不是线性的,而是由四个周期组成的循环流程。是循环,不是步骤,你要在周期内循环,加快速度,当在这个周期内完成的工作通过检验,你才能进入下一个周期;与前一个周期一样,你要继续完善你的工作。如果在这个周期内,你失败了,那么你就要回到前一个周期——或者退出整个循环,这意味着你的想法不合格。

无论是关卡设计还是系统设计,总是要经过四个周期组成的循环流程:目标(Goals)、研究(Research)、执行(Implement)和修饰(Polish)。这就是我所谓的“GRIP设计流程”。

GRIP(from flarkminator.com)

GRIP(from flarkminator.com)

确定目标

“当被迫在严格的框架内工作时,想象会发挥到极致。而在完全自由的环境下,想象却会漫无边际。”——T.S. 艾略特

在做任何事以前,你都必须先确定你想要什么。设计的海洋是广阔的、危险的,你的旅途中埋伏着许多暗礁和旋涡,所以你要保证你的航向是正确的。任何系统的最终目标都是保证玩家的需求层级被一一满足,我认为也就是逐级完成玩家满足感的五个层次。第一层的执行和第二层的感觉是很容易满足的,但至于剩下的层次——精通、目的和有意义的选择,我们现在就可以开始计划。最终目标是有趣的体验,要达到这个目标就要保证玩家的需求层次被满足。

但是,目标只是这个等式的一半;约束条件同样重要,毕竟所有游戏都需要约束条件。让思想在绝对自由的天空中飞翔,并不像你所想像的那样将产生无穷的创意,只有经过约束的想象才能产生真正的创意。我也爱幻想。有多少次你在笔记本上写道:“侠盗猎车手+上古卷轴+太空”,后面跟着若干潦草地写到一半的系统;然而,我敢说,如果你真的尝试实现那个设想,结果将是臃肿的、没有方向的和乏味的游戏。这是一个永恒的悖论:你想设计出最好的东西,往往设计出最差的东西。

关键是,你必须研究和理解你的约束条件。约束条件可以有很多种表现形式:

题材:你做的游戏是未来派的还是中世纪的;现实的还是幻想的?

员工:如果你以为只做过射击游戏的人可以马上去开发动作游戏,那你就太天真了。这种员工就限制了你的设计选择。

时间:我们都希望时间充裕,但事实上,我们能用的时间只有这么多。

控制方式:在你的控制中,机制比按键多是一个非常现实的问题,游戏的制作方式受到很多限制。

机制:有些机制尽管有趣,但与其他东西相结合以后就无法运作了。

核心:你必须定义你的游戏的核心;因此,你又受到这些选项的限制。永远不要让你的体验变得太臃肿,总是问你自己你是否确实需要某个机制。

约束条件不是敌人,因为它们正是设计过程的一部分,最终,如果你觉得那些约束条件限制了你的创意,那么我可以肯定地说,是你自己本身缺少创意的头脑。

研究

“原创存在于对真实的追求中,而不是搞怪。”——Robert McKee(电影编剧大师)

既然我们已经明确了目标和约束条件,接下来就可以开始创作了,对吧?不是的!优秀的设计师知道真正的关键是执行而非创新,但似乎有太多设计师跳过这个过程中的关键一步:研究。我曾经写过关于创意和抄袭的文章。不过这不是我要说的重点,从现在的游戏可以看出,大部分设计师都很害怕抄袭。

研究是关键。我共事过的优秀设计师都掌握了大量关于游戏、电影、书籍和电视的知识。他们知道自己的弱项,你也应该如此。我,收集游戏攻略,更是熟知这些知识。我挣钱不多,我知道,但那当然不会阻止我想成为世界上最优秀的游戏设计师之一的梦想,所以我喜欢收集游戏攻略。有些很好,有些很差,比如《生化危机5》的攻略,但偶尔你会得到一些对游戏系统进行深入分析的材料,还配上清楚、容易理解的地图。你应该喜欢那些东西,如果你是一个游戏设计师却不研究游戏攻略,那么就好比音乐专业的学生却不学习乐谱。即使你再有才华,你也必须靠研究来磨练你的技术。

但研究不是让别人为你做工作,差得远了。是的,部分研究是寻找灵感,但研究的更重要方面的是语境。在你把其他游戏的系列搬到你自己的游戏中以前,你必须首先理解该游戏系统的语境;如果你把某个机制放到你的游戏中只是为了让它出在你的游戏盒子背面的描述上,那么你就误解游戏设计了。那样的设计师我叫他们行业的蛀虫,是没有立足之地的。在游戏中,最重要的是让各个机制都像使机器得以顺利运转的齿轮。所以,你的研究目标不只是研究为什么某机制管用,还要知道它如何在整个游戏中发挥作用;以及更重要的,其他什么系统与它有紧密关系。

假设你正在制作一款MMO,你想复制《魔兽世界》中的闪避机制。为什么要有闪避机制?不是因为闪避机制是你想放进你的游戏中的东西,你就是要找出真正的“为什么”。闪避机制存在是因为游戏中有盗贼职业,这是无法通过升级装甲来减小伤害的近战职业。如果你移除盗贼职业,那么你就不需需要闪避机制了。你真的要深入地思考,因为如果你的游戏语境和你正在研究的游戏的语境并不相同,那么你就应该考虑你是否真的需要这种机制;这就让我们不得不思考一下循环与步骤的区别。

步骤要求前进,返回是糟糕的。循环讲究速度,但如果你无法保持这个速度,你就要退回上一个循环,那就是研究阶段为你做的事。如果研究机制没有让你像原子中心的电子一样兴奋起来,那就说明你还没有足够的能量脱离原子核的控制。你要回到你的明确目标和约束条件阶段,因为你可能做错了什么事。

然而,也许一切都会逐渐被理解。当你获得足够的速度,你就可以跳到下一个循环中了。

执行

“所有东西的初稿都是垃圾。”——海明威

Implementation(from piperreport.com)

Implementation(from piperreport.com)

真相:你第一次执行的任何东西都将成为垃圾废物。这就是为什么要以尽可能快的速度把好想法做成可以玩的东西。但是,你必须理解,这个阶段不是你所想象或希望的“把东西贴在墙上让程序员去实现它”的阶段。请务必不要那样想。

我肯定存在一种方法允许你用你所拥有的工具快速地做出最接近你想要的东西。当然,它不会完美,可能看起来就像是垃圾;如果你把它给随便什么人看,他们都会用一种“你懂的”的表情回应你。

关键是“最接近”。不必十全十美,但越早让它开始通过你的检查表,越好。什么是检查表?当然是玩家满足感的5个层次。正是在这个执行阶段,你要交叉检查你的想法是否满足玩家的需求层级,特别是感觉,然后保证满足这些需求。感觉好不好?精通曲线是否合适?某武器的存在是否有明确的目标?是否提供有意义的选择?

你已经在初始目标阶段计划好这些了,但现在我们必须再确认假设。计划往往赶不上变化,因为这是一个循环,意味着我们仍然在圈里转,除非我们做出成果。如果出了错,我们就会回到上一个循环;如果我们的成果确实不错,那么我们就进入最后一个也是最困难的阶段。

最后的修饰

“在理论上,理论和现实是没有区别的,但在现实中,理论和现实是有很大的区别的。”——Al Roth(经济学家)

我们终于到最后阶段了——修饰成果。当然需要付出大量努力,正如一句老话所说的:最后10%的修饰需要50%的努力。当你还没真正开始做,你可能不觉比例得有这么夸张。这句话是很夸张,但说的就是事实。

如果对修饰阶段我还有什么话可说的话,那将是一堆话。但我想说的关键只有:敢做敢当。最让我生气的是人们在发生混乱时所表现出来的态度。也就是,当问题出现时,有些人居然会耸耸肩说:“那不是我的问题。”

不,那其实就是你的问题。我们所有人都有责任,因为我们都在努力做一款重要的游戏,对吧?我不是我自己就完全不会产生这种态度,但那并不意味着当我有那种感觉时,我就藏得住。我提醒自己为什么我会落到这个地步:为了做一款重要的游戏。我完全希望和感激,如果我曾经说过那种不负责的话,请知情人骂我。如果你不再乎你正在做的东西,那么你为什么要做?

总结

明确目标、做研究、执行和修改以及最后的修饰,直到你的游戏大放光彩。我做任何系统都要经过这四个周期,我认识的其他设计师也是一样的;尽管他们可能不会这样描述自己的过程。本文的重要启示,除了给你的过程提供强大的方法论,还让你理解设计不是一个按步骤展开的过程。我们都认为从左到右一步接着一步是好的,第一步,第二步,第三步,完成——如果你返回前一步,那么你就是错的或甚至愚蠢的。在这里,我告诉你,会那么想的人才是错的。设计师必须从左到右,但如果你不能不断地重新评估你自己的工作,那么你才是做错了。

牢牢抓住(GRIP)你的系统,否则它们可能从你的指间溜走。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Get A GRIP On Your Systems

by Kaz

Design is not a linear process. A game is not assembled piece by finished piece like some elaborate puzzle, much to the chagrin of our managers. There is something compelling, though, in that mental image of an elaborate puzzle, but the quest for good design is not the quest for that single piece that you think might fit, and if only you searched hard enough you will find it. This gap between mental image and reality is hurting us dearly in the realm of game design, but it hurts, most of all, when it comes to planning and scheduling.

You can break out your process into as fine a detail you like, but if you think of it as linear steps, then you are doing it wrong. Design is not linear, my friends, because it flows in four cycles. They are cycles, not steps, because you spin around inside them, picking up speed, excitement, and eventually, if it passes the test, you fling yourself out of that cycle to the next; where, like before, the process of building up speed continues and, most importantly, if you fail to maintain your speed, you fall back to a previous cycle — possibly out of the loop completely, which means, guess what, that idea didn’t make the cut.

Wether level or system design matters not, nor do the specifics of the system itself matter, as it always flows through the same four cycles: Goals, Research, Implement, Polish.

Defining Your Goals

“When forced to work within a strict framework the imagination is taxed to its upmost — and will produce its richest ideas. Given total freedom the work is likely to sprawl.” – T.S. Eliot

You must, before anything else, define what you want. The sea of design is vast, dangerous, and has many a pirate cove waiting to waylay you on your journey, so make sure you got your sails pointing in the right direction. The ultimate goal for any system is to ensure that the player’s hierarchy of needs are being met, which,for me, means running through my checklist of the 5 Layers of Player Satisfaction. We will cover the first layer, implementation, in a second, and the second cycle, feel, will come into play in the cycle after that, but for the remaining layers — mastery, purpose, and meaningful choice — we can begin to plan for them now. The ultimate goal is a fun experience, and a fun experience is crafted through ensuring the player’s hierarchy of needs are being met.

Goals are only half of the equation, though; constraints are just as important, as every game has need of constraints. Living in the pie in the sky is not as creative and freeing as you think, because it is only through constraints that true creativity is born. I’m not immune to dreaming big. How many times have you scribbled in your notebook, “omg gta + elder scrolls + space”, which was followed by several fervent scribbles of half-thought systems; I am sure, however, that if you actually tried to realize that vision it would result in a bloated, directionless, and ultimately bland game. It’s the “best thing ever” paradox. Trying to design the best thing ever usually results in the most boring thing ever, but that’s another post.

The point is that you must study and understand your constraints, and they come in many types.

IP – are you making futuristic or medieval; realistic or fantasy

Staff – if you think that a staff of people that have made primarily shooters can just shift focus to an action game, then you are horribly, dangerously naive. The kind of staff you have constrains the kind of design choices you make.

Time – as much as we all wish we were blizzard the fact remains that we only have so much time available to us.

Control – having more mechanics than buttons on your control is a very real problem, and we are very realistically constrained by the type of control method you have for your game.

Mechanic – some mechanics, while fun, simply do not work well in conjunction with others.

Core – you must define the core of your game; and, consequently, you are then constrained by those choices. Never bloat your experience, and always ask yourself if you REALLY need a mechanic.

Constraints are not the enemy, my friend, as they are a very real part of the process; and, ultimately, if you feel that constraints limit your creativity, then I can safely say, with full confidence, that you lack a single creative bone in your body. Deal with it.

Do Your Research

“Originality lies in the struggle for authenticity, not eccentricity.” – Robert McKee

So we know our goals and constraints, and now we start building, right? Nope (chuck testa)! Pull back on those reigns buddy. Good designers know that it is execution and not innovation that really and truly keeps people engaged, but it seems like way too many designers skip this crucial step in the process: doing your damn research. I have written before about my feelings on ideas and stealing them. It is simply not a concern of mine, and, if current games are any indication, most designers live in fear of stealing.

Research is key. All the best designers I’ve worked with have an encyclopedic knowledge of games, movies, books, and television. They just know their shit, and you should too. Me, I collect strategy guides. I have tons of them. My memory isn’t so great, and I knew that, but that was certainly not going to stop me from being the best god damn game designer I could be, so I took to collecting strategy guides. Some are good, some are bad, but every once in a while — I’m looking at you, Resident Evil 5 guide — you get one that has some truly meaningful analysis of their own systems, with clear, clean, easily readable maps. Cherish those, and if you are an inspiring game designer and you don’t study strategy guides, then you are basically the music major that doesn’t study sheet music. Talent only gets you so far, so you must hone your craft through research.

Research is not about letting someone do your work for you, though — far from it. Yes, part of research is looking for ideas, but the more important aspect of research is context. You must first understand the context of a game’s systems before you use it in your own game, and if you are putting mechanics into your game for the simple pleasure of adding them to the checklist on the back of your box, then you are everything that is wrong with game design. Back of the box designers, as I like to call them, are a cancer, and they have no place. In games that matter, it is a given that every mechanic fits like a cog in the great machine, and part of doing your research is to study not only why it works, but also how it fits; and, more importantly, what other systems are tied into it.

Let’s say you are making an MMO, and you are interested in copying the dodge mechanic from vanilla World of Warcraft. Why did they have a dodge mechanic? Well, it’s not because dodging is something you put into your game, just because. No, they have a dodge mechanic because they also have a rogue class, and they require damage mitigation that works for a melee character that isn’t controlled through armor rating. If you remove the rogue class, then you no longer require the dodge mechanic. Really drink that in, because if the context of your game and the context of the game you are researching do not line up, then you should really start considering wether you really need this mechanic; which, my friends, brings us to the ultimate cross roads in the difference between cycles and steps.

Steps move forward, and going backwards is bad. Cycles pick up speed, but if you fail to maintain that speed you fall back, and that’s just what the research phase does for you. If doing research for your mechanic doesn’t get you excited then, just like an electron, you lack the charge to escape! FALL BACK. It’s time to return to your goals and constraints, because chances are you had something wrong. And this is ok!

Maybe, however, everything is falling into place. You are picking up speed, so it is time to jump out to the next cycle.

Starting Implementation

“The first draft of anything is shit” – Ernest Hemmingway

Fact: the first time you implement anything it’s going to be shit. Which is why it is such a great idea to get things up and playable as soon as possible. It is critical you understand, however, that this phase is not, as much as you would like to to be, the “throw it over the wall and let the programmers take care of it” phase. Please don’t be one of those people. Please.

I guarantee there exists, in some fucked up fashion, a means to build a quick approximation of what you want with the tools you have. It won’t be perfect, of course; it will look like shit, undoubtedly; and if you show it to anyone they will give you that look, you know the one. None of that matters.

The key here is approximation. It doesn’t need to be perfect, but the sooner you can start running it through your checklist the better. What checklist is that, you ask? Why the 5 Layers of Player Satisfaction, of course. It is in this phase, implementation, where you will be doing the most cross checking against the player’s hierarchy of needs, especially feel, and ensuring that they are being met. Does it feel good, is the mastery curve just right, does the weapon have a good purpose, and is it providing meaningful choice.

You have already planned for these back in the initial goal phase, I hope, but now we must reaffirm out hypothesis. Things almost never turn out the way we planned, which, because this is a cycle, means that we will spin around in here until the kinks get worked out. If things go wrong, then we fall back to the previous cycle and do some more research, or, eventually, once you are feeling super pumped and things look good, you fire off to the final and most difficult phase.

Final Polish

“In theory, there is no difference between theory and practice, but in practice there is a great deal of difference.” – Al Roth

We’re finally here. The polish cycle. It really is a massive amount of effort, and as the old saying goes, the last 10% of the polish takes 50% of the effort. It’s just not a statistic you really, truly believe until you have to see it first hand. It’s crazy talk, but it’s true.

If I had anything to say about polish, of which one could say lots, I would say that the key to polish is ownership. The one thing that peeves me off more than anything is the attitude some acquire in times of great turmoil, which is, when problems arise, to shrug their shoulders and say, “well that’s not my problem.”

No, see, actually it IS your problem. It is ALL of our problems, buddy, because we are ALL trying to make a game that matters, right? I’m not saying I’m immune to this attitude, my friends, but that does not mean I revel in the feeling when it passes through me. No I shake it off and remind myself why the hell I am here: to make games that matter.  And I would fully expect, and appreciate, that if I ever said something like that, then someone would call me on my bullshit. If you don’t give a shit about what you are making, then why are you even here?

Get a G.R.I.P.

Define your goals, do your research, implement and approximate, and finally, polish until it shines. I go through the same four cycles in every system I work on, as does every other designer I know; though they may not think of it in those terms. The key lesson here, besides the strong methodology this ascribes to your process, is to understand that design does not flow in steps. We are taught that going from Left to Right is good — Step 1, Step 2, Step 3, DONE — and if you ever go backwards you are wrong, or worse, stupid. I’m here to tell you THEY are wrong. A designer MUST go from Right to Left, and if you aren’t constantly reevaluating your own work then you ARE doing it wrong.

Get a grip on your systems, or they might just slip through your fingers.

Categories: Know the game

2 Responses to Get A GRIP On Your Systems

Kaz says:
November 23, 2011 at 12:04 pm
Thanks for the article, it was a good read.

Interesting to hear about someone else who also collects and studies strategy guides in their media studies. It’s something I’ve been doing for quite a while. In fact, it was the main reason I learned to read Japanese, as they have these amazing design bibles that they release in Japan for most of the popular games (really, really massive, 300+ page tomes that breakdown and explain every system, mechanic, character, etc.).

I’ve learned some awesome stuff from reading them over the years.(source:flarkminator)


上一篇:

下一篇: