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

分解游戏设计过程各个环节的主要内容

发布时间:2012-11-04 08:57:51 Tags:,,,,,

作者:Lewis Pulsipher

(本文摘自Lewis Pulsipher所著的《Game Design: How to Create Video and Tabletop Games, Start to Finish》一书的内容,详细分解了传统游戏设计的过程。)

制作游戏是一项工程,它同任何工程一样需要遵循一个规划周期。以下就是开发游戏的计划-执行-监控-控制-重新计划循环(详见下图)。

如果你根本不做任何计划,你可能就需要不断补缺补漏,而如果你一开始就做对了,可能就不需要浪费这么多精力来善后。如果你已经做好计划,但却没有检查事实情况(执行)是否符合计划(监控),那么最终结果迟早会与计划脱节。此外,即便你知道计划赶不上变化,假如你不采取补救措施(控制),那也迟早会失败。假设你控制了这种局面,那么你就需要重新制定计划,换句话也就是:

*如果你不知道会发生什么情况,那你怎么知道要做什么?

*如果你不知道正在发生什么情况,你又如何让事情朝正确的方向发展?

*如果你不能让事情朝正确的方向发展,你又怎么实现自己的目标?

*如果你的计划与实际情况脱节,你又怎么知道下一步该怎么走?

game design process(from gamecareerguide)

game design process(from gamecareerguide)

从上图可以看出,制作一款好游戏的主要流程与管理流程很相似。当你达到可玩模型这一阶段时,你需要试玩游戏,分析结果,调整模型,再次试玩,一直到你“完成”为止,或者就此放弃。

“系统”是组成一个复杂或统一整体的事物/部分的集合。一般来说,系统分析就是找出系统工作原理,或者说它的运行方式,其部分组件可能具有自动化特点。在此我们关注的是它如何运行,这样我们就可以运用一些设计方面的知识。

data flow diagram(from gamecareerguide)

data flow diagram(from gamecareerguide)

上图是套用系统分析所绘制的数据流图表,它显示了数据存储位置、数据/信息或对象的流向,以及与系统产生交集的外部实体。

*圆圈代表流程,即事件发生位置

*圆角矩形是数据存储位置

*箭头号是指数据/信息或对象的流向

*矩形代表设计师之外的外部实体

绘制这个图表的目的并非显示各个事件发生的时间顺序,而是注明一切可能发生的事件。在系统运行过程中,可能会同时发生多个流程。在设计过程中的同一时间萌生新创意,在脑中边玩游戏边构思游戏框架,这已是一种常见现象。你通常可以在同一时间创造和调整原型文字标记、规则或软件,以及测试原型。

我们所绘制的系统图表只是游戏设计过程。发行商和测试者并不在这个系统中,因为他们并未参与游戏设计。

在此我们将“完成”一词标上引号是因为,发行商通常会提出修改游戏的要求,有时候是改善建议,有时候是因为游戏出现问题,有时候是偶然性,有时候是必然性。研究和解决大量的制作问题并不在这个系统考虑范围之列,因为这是制作者需处理的事情。

这个图表适用于任何游戏(包括电子和非电子游戏)的设计过程。这个图表假设的情况是单个设计师参与游戏设计,而非由多人参与设计AAA电子游戏,因为AAA游戏设计流程有更复杂的要求。

设计合作者也不在这个系统范围中,但有些情况下,两名合作者若紧密联手,使其执行效果就像是出自单人设计师一样,那么也可归入这一系统范围中。

过程

在这个图表显示的7个过程中,每个过程都可以再分解为另一个图表的子过程,直到无可分解为止。但这并不在本文讨论范围之内,对于初学者来说,掌握最顶级的过程就已经足够了。

要记住这7个过程(活动)也许会同时发生,不会按照特定的顺序进行。这些过程包括:

*构思和调整想法。游戏起源于想法。我已经多次讨论过拥有大量想法的重要性,以及你该如何产生创意。

无论你想为创建哪种游戏理念的模型,都需要事先进行调查研究。例如,如果你要设计一款与农场有关的游戏,就需要了解如何耕作,这就需要进行一定的调查。如果你要设计一款与二战中的库尔斯克战争有关的游戏,那就得研究这场战役以及苏联、德军双方当时的军事实力和作战动机。如果你要开发一款反映现实的模拟游戏,那就极需要调查研究以便提高游戏模拟的准确度。无论如何,在项目开工前一定要进行足够的调查研究,然后投入游戏设计中,要防止被卡在无限的“调查研究”工作中。

在想象中玩游戏。你将逐渐在脑中形成一些游戏运行的概念。你需要在脑中体验游戏或游戏的部分环节,并自问“玩家会如何做,这一内容如何在游戏中呈现?”你可以在任何时刻进行这种想象,例如在开车、排队、阅读设计笔记的时候。富有经验的设计师常在创建原型之前通过这种方法,从脑中的大量想法中筛选游戏理念。电子游戏设计师必须依赖这一过程,因为制作电子游戏的可玩原型相对更困难并且更耗时间。

构思游戏结构和框架。到一定阶段后你就会掌握足够信息,并将游戏运行原理描绘到纸上。做到这一步后你就可以开始制作原型。

创造和调整原型。对于桌游而言,创建原型是一个相对快速的过程,但电子游戏原型而更费功夫。有些电子游戏设计师会首先制作纸质原型以测试游戏的核心理念。

编写说明-规则-软件。某些电子游戏需要开发者编写软件。对桌游来说,你可以在早期直接以设计师的想法试玩游戏,但迟早要落实其游戏规则。因此在早期要写好相关说明,后期再落实规则。

单独测试。设计师需亲自试玩游戏,这样才能在把游戏移交给他人之前解决其中最糟糕的问题。如果团队制作的是电子游戏,全体成员可能都需要独自试玩游戏以发现问题。

他人测试游戏。多许游戏测试是由设计师及制作团队之外的人员来完成。这其中包括桌游测试,设计师在测试过程中可能会在场,并告知玩家如何玩游戏,以及设计师不在场的盲测(玩家需自己掌握游戏玩法)。

在上图中的这两个测试过程虽然彼此相邻,但却各自独立,这是为了强调设计师自己先试玩游戏的重要性(游戏邦注:从技术角度上说,这应该是一个玩法测试的过程)。

设计师可以通过亲自玩游戏来修复许多问题,这样那些外部测试者(假设他们是免费参与测试)就会更愿意参与测试并持续玩游戏。如果他们刚开始试玩时,游戏就含有明显漏洞,他们试玩游戏的热情势必受挫。所以在其他人接触游戏之前,你一定要先解决游戏的重大缺陷。

对桌游来说,调整原型的过程通常就是“开发”过程,并且还有设计师之外的人员参与其中。此时两个主管操刀总胜过一人作战,而开发者此时就像是一个出版编辑,提出优化建议或改进游戏。而对电子游戏来说(许多桌游设计也同样如此),设计师在此时则可能同时是开发者。

注意

制作这一系统的图表并没有唯一合适或正确的途径,毕竟不同设计师有不同工作风格,并且数年前的原版图表也并非现在这种面貌,但仍然包含这7个相同的过程。

这里并没有创意图表,因为创意萌生于各个过程中。多数游戏设计也并非我们所谓的创意过程。

质量也并非系统分析图表的一个环节。理想情况下,各过程中的每个步骤都应该到位,但我们很难保证实现这一点。如果设计师跳过了某些步骤,那么他就很难创造出真正的好游戏。如果设计师遵循这些步骤,也还是有可能制作出很糟糕的游戏。

以其他方式看待游戏设计过程(MDI/MDA):

Adams和Rollings在《Fundamentals of Game Design》一书中将游戏设计列为以下步骤:

*理念

*加工

*调试(即迭代和增加)

这描述了游戏设计的三个连续阶段,与数据流图表并不矛盾,只是以更简化的方式来看待这一过程。从他们的角度来看,理念就是针对游戏的计划。当你开始加工游戏时,你就不可以让计划发生重大变动,否则就可能让游戏偏离正轨,最终变成另一款不同的游戏。

MDI是机制(Mechanics)、动态(Dynamics)和印象(Impressions)三者的简写。这一框架是你创建和调整游戏时的思维方式,它有助于你提出问题并进行修改。

我们应该从相反顺序来讨论这三个组成部分。我们希望给玩家留下什么印象,希望他们对游戏产生什么感觉和想法,这是游戏设计师首先要考虑的事项之一。我们希望给玩家留下什么影响?也就是,我们想让游戏给玩家什么印象?有些设计师喜欢在概念过程中写下他们希望玩家获得的感受和体验。

机制即游戏规则,或者说是通过编程执行的机制,它是告知玩家应如何操作,以及不该如何操作的环节。

动态代表编程或规则如何在游戏中与玩家互动以产生事件和挑战。设计师在脑中试玩游戏时所获知的情况,通常与试玩原型时并不相同。一般情况下,突发性和意外性这两个元素更为重要。

突发性,即出现新的属性,两个或更多机制交互时所产生的一些未预料到的情况,而其结果并不只是各个部分的总和。很可能设计师都没有料到会出现这些新属性。例如火箭跳跃(Rocket-jumping“就是电子游戏中偶然出现,但并非设计师有意而为之的一个属性。许多以规则/机制主导的游戏(不同于故事导向型游戏)也都存在这种突发属性。

Rocket-jumping(from gamecareerguide)

Rocket-jumping(from gamecareerguide)

(火箭跳跃最初出现于《雷神之锤》系列,自此变成《军团要塞2》等游戏热衷采用的机制。)

意外性是一种非故意或者无意中的发现,以及带有偶然性和聪敏性的学习体验。这一词通常用于科学领域的意外发现(游戏邦注:例如青霉素就属于一个意外发现)。在这种情形下是指,有些设计师可能很擅长创造规则,结果催生出了不同于原先预期的意外玩法。

设计师需要创造游戏机制为玩家提供挑战,让他们在游戏中有事可做,并且需要牢牢把握他想让玩家产生的想法和情感,但这些规则的动态通常会产生极为不同的情况。

这一理念的最初版本是由Marc LeBlanc所提出的MDA(机制、动态、美学),在此“美学”(Aesthetics)一词并不能够为多数人所理解,所以我根据自己的喜好将其替换成了MDI。

无论你如何看待这一理念,都要认识到迭代以及增量设计对游戏的成功与否影响重大。

游戏设计阶段——各个阶段平均花费时间

“制作一款完全度为80%的游戏十分容易。市面上有许多游戏仅完工80%。通过多次测试可以让游戏更加完善,而最后的20%则需耗费大量时间,这才是制作游戏的困难所在。”——Reiner Knizia

Knizia是一名桌面、卡牌及电子游戏自由设计师,每年创收超过1亿美元,他认为制作游戏的最后20%内容需花费超过20%以上的时间。

以下是游戏设计各个阶段所需分配时间:

chart(from gamecareerguide)

chart(from gamecareerguide)

需要说明的是,这只是我个人的估算情况,具体时间要视不同游戏项目而定。

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

Excerpt: A Systematic View Of Game Design[09.18.12]

- Lewis Pulsipher

[In this excerpt from Game Design: How to Create Video and Tabletop Games, Start to Finish, game designer Lewis Pulsipher offers a detailed breakdown of the processes involved in traditional game design. Our previous excerpt from Pulsipher's book can be found here.]

Creating a game is a project, and follows the same kind of planning cycle as any project. This is the Plan-Execute-Monitor-Control-Replan cycle, as illustrated in Figure 2:

Figure 2: Project Management and Game Development Cycles

If you don’t plan at all, you’ll be constantly fixing things, often taking action to fix something that would not have needed fixing if you’d done things right. If you plan but don’t check to see if reality (Execution) matches the plan (Monitor), then sooner or later reality won’t match the plan. Further, even if you know the plan and reality doesn’t match, if you do nothing to fix the situation (Control), then you deviate into failure. Assuming you Control the deviations, you then need to redo the plan. In other words:

- If you don’t know what’s supposed to happen, how do you know what to do?

- If you don’t know what is actually happening, how can you make the right thing happen?

- If you can’t make the right thing happen, how can you get where you need to go?

- If your plan doesn’t adjust to reality, how do you know where to go, now?

Further, looking at the second part of Figure 2, we see that the major process in creating a good game is similar to the management process. When you’ve reached the point of a playable prototype, you play the game, analyze the results, modify the prototype, and play again, around and around until you’re “finished”, or you give up, or you’re forced to stop.

Figure 3: Process of Game Design expresses the process a different way, in Data Flow Diagram terms borrowing from Systems Analysis.

A “system” is an assemblage or combination of things or parts forming a complex or unitary whole. Typically, in systems analysis someone figures out how a system works, or ought to work, with the possibility that some of it might be automated. Here we’re interested in how it ought to work so that we can use that knowledge in design.

A data flow diagram shows the processes that occur in a system as well as places where data is stored, flows of data/information or objects from one place to another, and external entities that interact with the system:

- circles are the processes, where things happen

- the oddly shaped rounded rectangles are the data stores,

- the arrows are the flows of data/information or objects,

- and the rectangles are the external entities, outside the designer himself

The purpose here is not to show time sequences but to show all the things that might occur. Hence during the operation of the system at any given time several of the processes might be occurring. It’s not unusual during the design process to be generating ideas, playing the game in your mind’s eye, and even conceiving the game structure and framework all at the same time.

Often you could be creating and refining the prototype writing notes, rules, or software, and playtesting all at the same time.

The system we’re diagraming is game design. The publisher and playtesters are outside the system, as they are not actually designing the game (we hope).

“Complete” is in quotes because publishers usually require changes to a game, sometimes for good, sometimes for ill, sometimes accidentally, sometimes deliberately. Researching and solving mass production issues is outside the system, insofar as the manufacturer does this.

The diagram is meant to show the process for any game, non-video or video. It is a diagram that assumes a single designer, which is not the case for AAA video games, which are effectively designed by groups of people. A AAA video game creation diagram, which we’ll see in Chapter 8, Section A (not included in this excerpt), is dominated by communication and cooperation because so many people are involved. Designers of big video games must cope with both sets of demands represented in two diagrams.

Design collaborators are shown outside the system, as well, but in some cases two collaborators will work so closely that they will collectively be within the process just as a single designer is within the process.

The Processes

Each of the seven processes shown on the main diagram can be divided into another diagram (not considered in this book) with sub-processes, until there is no point in drilling down further.

For learners, the top level is sufficient.

Remember that the seven processes (activities) may be going on at the same time, not in a particular order. These are:

Conceive and refine ideas. The game begins in the mind. I’ve discussed above how important it is to have lots of ideas and how you can generate ideas.

This is also where you’ll research whatever situation you are trying to model — if any. For example, if you’re designing a game about farming, you need to know how farming works, which is likely to require some research. If you’re designing a game about the Battle of Kursk in World War II, you’ll need to research the battle and the capabilities and intentions of the Soviets and Germans. If your game is intended to be a simulation, closely reflecting some reality, then this research will be very important to the accuracy of the simulation. Nonetheless, do just enough research to get you going, and then work on the game; some people get stuck indefinitely in “research.”

ArmA II is just one of many simulation games that rely heavily on research.

Play game in “mind’s eye” thought experiments. Gradually you’ll have some notions about how the game will work. You should play the game or parts of the game in your mind and ask yourself “what is the player going to do and how is this going to be shown in the game.” You can play in your mind=s eye any time. You can be riding in a car, you can be waiting in a queue, you can be reading your notes made so far. Experienced designers do this a lot and sort a lot of the game out in their heads before they ever have a prototype to play. Video game designers must rely very heavily on this process because it’s relatively difficult and time-consuming to produce a playable prototype of a video game.

Conceive game, structure, framework. At some point you’ll have enough information that you’ll lay out on paper how the game is actually going to work. Once you do this then you’ll want to make a prototype so you can try to play.

Create and refine prototype. Creating the prototype is relatively quick for tabletop games but takes far longer for video games. Some video game designers, if it’s practical, will make a paper prototype first to test the concepts that are the essence of the game.

Write notes-rules-software. At some point for video games someone will have to write the software. For tabletop games you can get away with relying on what’s in the designer’s mind for early playing, but sooner or later rules have to be written. So it’s notes at early stages, rules at later stages.

Solo playtest. The designer plays the game himself so that he can work out the worst problems before he inflicts it on anyone else. If a team produces the (video) game, they likely all play the solo version to discover problems.

Playtest with others. Most of the play testing ought to be done by people other than the designer(s) and production team. This will include testing for tabletop games where the designer is present and probably teaches the players how to play, and blind testing where the designer is not present or at least has no part in what happens and the players learn the game as though they had just bought it.

In Figure 3 these two testing processes are adjacent to each other but separate in order to emphasize how important it is for the designer to play the game himself before other people play.

(Technically speaking, there probably ought to be one process, Playtesting.)

It’s also important for the designer to play the game himself before other people play. (Technically speaking, there probably ought to be one process, Playtesting.) The designer can find a fix for many problems simply by playing himself. Then the outside playtesters, assuming they’re not being paid to playtest, will be happier with the playtesting and more likely to continue to play the game. If the game has big faults when they first play, they’re much less likely to play again. You need to work out the really big faults before anyone else plays. (Yes, there are likely to be really big faults.)

In tabletop gaming, the process of refining the prototype is often called “development,” and someone other than the game designer may be in charge. Two heads are better than one, and the developer acts something like a book editor, suggesting or making changes to improve the game. In video games (and many tabletop designs) the designer(s) are also the developers in this sense.

Caveats

There is no single proper or right way to diagram this system, given the variety of ways that designers work, and in fact the original diagram was rather different several years ago although it still contains the same seven processes.

This is not a diagram of creativity; it’s a diagram of what happens. “Creativity,” when it happens, is within the processes. Most of game design is not what we normally think of as creativity.

Quality is not part of the system analysis diagram in and of itself. Ideally, every step in the process will be well done, but there is no assurance of it. If a designer leaves out some of these steps, he’s less likely to create a good game. If a designer follows these steps, he may still end up with a lousy game, though it should not be an unplayable game (if it were, the blind testing would never work).

Further reading: Cooperation and engagement: what board games can tell us

Alternative ways to look at the process (MDI/MDA):

Adams and Rollings in Fundamentals of Game Design list the stages of game design as:

- Conception,

- Elaboration,

- Tuning (which is iterative and incremental)

This describes three successive stages of design, and does not contradict the data flow diagram, but is a simpler way to look at it. In their view, the conception is a plan for a game. Once you begin to elaborate a game you should not make major changes in the plan, or should recognize that you’ve switched to a different game. That’s OK if you have time and if you don’t already have a contract to deliver a game with certain parameters (you often will with video games).

MDI stands for Mechanics, Dynamics, Impressions. It is a way of thinking about the game as you create and modify it, something to help you think of questions and modifications.

The three parts need to be discussed in reverse order. What we want to engender in the minds and hearts of the players, what we want them to feel and think, is one of the first things for a designer to think about for a game. What do we want the end result to be in terms of the effect on the players? That is, what impression do we want to make on the players? Some designers like to write, early in the conception process, a description in general terms of what they want the players to feel and experience.

Mechanics is the rules or the mechanisms enforced by the programming, the parts of the game that in effect tell players what they can do and what they can=t do.

Dynamics involves how the programming or rules interact with the players to produce events and challenges in the game. What a designer intends, what he sees in his mind’s eye as he plays the game in his head, is often not what happens when the prototype is played. Often two qualities, emergence and serendipity, become important.

Emergence, the appearance of new properties, often occurs when two or more mechanics interact to produce something unanticipated, something that is more than the sum of the parts. These new properties may be a surprise even to the designer(s). Rocket-jumping* is apparently something that emerged from the mechanics (rules) of video games, not intended by designers. Many rules/mechanics-dominant games (as opposed to story-dominant) exhibit qualities of emergence.

*Rocket-jumping first emerged in the Quake series, and has since become a popular game mechanic in titles like Team Fortress 2.

Serendipity is an unsought, unintended, and/or unexpected discovery and/or learning experience that happens by accident and sagacity. The word is often used in connection with scientific discoveries that someone Astumbles upon (e.g. penicillin). In this context, some designers may be particularly adept at creating rules, which lead to quite different kinds of gameplay than anticipated.

The designer, then, creates game mechanics to provide challenges for the players, things for the player to do, and has in mind certain thoughts and emotions he wants to engender in the players, but the dynamics of those rules will often lead to quite different situations.

The original version of this idea is MDA (Mechanics, Dynamics, Aesthetics), devised by Marc LeBlanc (also originator of “8 kinds of fun”). The word “Aesthetics” doesn’t convey adequately to most people, so I’ve substituted my own preference.

However you look at it, the important thing is to recognize the iterative and incremental nature of creating a successful game.

Stages of game design — average time spent on each

“Making an 80% game is very easy. A lot of games that are out there are just 80% finished. With more testing the game could be more elegant and the last 20% takes a lot of time. That’s the difficult part.” Reiner Knizia

Knizia, who makes more than a million dollars a year as a freelance designer of board, card, and (recently) video games, is referring to the last 20% of changes in the game, which takes a lot more than 20% of the time.

Time taken for each stage:

This is, of course, my estimate, and can vary greatly from one game to another. (source:gamecareerguide


上一篇:

下一篇: