作者：Ernest Adams

别人经常问我的一个问题是：“设计游戏要从哪里入手？” 我坚信玩家玩游戏（尤其是大型游戏）——是为了体验在现实世界中不能体验到的生活。

所以，设计游戏的第一步是，想象超脱现实的本质体验。当你对这种体验了然于心后，你就可以开始设定游戏玩法了。别人经常问我的另一个问题是：“记录游戏设计要从哪开始？”这个问题将在本文中得到部分解答。

大多数电子游戏的核心理念就是游戏玩法模式的概念。这个概念显而易见，但我从来没有见过哪篇文章或哪本书对此进行直接的描述。那么现在就由我来开头吧。

玩家玩游戏时，直接体验到的有如下三种东西：

1、观察游戏世界的方法。我说“观察”，是因为游戏世界通常是由2D或3D镜头从某个视角来拍摄的。

2、影响游戏世界的方法和把自己的意志融入游戏世界的方法。我称之为交互模式。这种模型有很多种，但最普遍的不外乎“角色”模式和“无角色”模式。大多数动作游戏采用的是“角色”模式，而后者多见于桌面或战争游戏。

3、游戏玩法本身——玩家面临的挑战以及应对挑战所采取的动作。Sid Meier曾提出“有趣的决策”：如果某种交互娱乐形式不具挑战性，那就算不上一款游戏。我个人的主张比他的还要严格一些，即游戏玩法是由挑战和动作组成的。当然这个定义不是在所有情况下都成立的。

以上三种元素——观察、交互模式和游戏玩法共同构成了游戏玩法模式，即玩游戏的特定方法。如果在游戏的过程中，三者中的任何一个发生显著改变，玩家就进入新的玩法模式。

以上描述大约有点抽象，但通过下面的例子，大家应该就明白了。假如，在赛车游戏中，玩家的大部分时间是用在开车上。玩家观察到的视野通常是在小车的挡风玻璃之外；这种模式把小车当作一种机器型角色来看待，从而实现玩家与游戏的交互活动；该游戏玩法包含某种挑战（安全驾驶、加油换胎和完成比赛）和应对挑战的动作（驾驶、加速和刹车）。驾驶车辆就是游戏玩法模式，并且在大多数情况下，这就是主要模式。

许多严肃的赛车模拟游戏采用的另一种模式，即玩家可以调整自己的车，从而提升车的性能。在这种模式下，玩家观察到的通常是车的原理图——玩家完全没有看到游戏的场景。这里的交互模式既不是“角色”模式也不是“无角色”模式，而更像是一位机械工程师在用计算机辅助设计汽车。当然，这里的挑战和动作是找到能够发挥车的特性的最佳配置。真正专注的玩家可能会耗费50%甚至以上的游戏时间，用来根据当前的赛道和天气状况调整车子。

gran turismo(from gamasutra)

在游戏《GT赛车》系列中，赛车改装画面就是比赛场景。玩家查看并或购买不同的升级装备。玩家还可以改装现有的部件。

有些游戏，如《俄罗斯方块》或者大多数冒险游戏，只有一种游戏玩法模式。其中有个把游戏拥有两种玩法模式的，玩家在二者中所花的时间大抵相当。例如，有些战争游戏，战斗前你得组织军队，然后才能开战。《九子棋》的玩法也分成两个阶段——先放棋子再移动棋子。

复杂的游戏甚至包含更多玩法模式。在美式足球游戏中，选择和执行一个回合一般来说包含六个模式：挑选编队、选择游戏、呼叫信号和对齐、后退、选择接球员和抛球；操作球下的接球员来接住球；一边往前场跑一边避开挡球员。每一个回合，观察视图可能没有改变，但球员和玩家所面临的挑战和应对动作都改变了。这虽然是“角色”模式，但游戏进行到一半时，这个角色从四分卫转移到接球员！

游戏玩法模式之间的限界并没有严格定义。但，从赛车驾驶视角转换到飞行模拟游戏的视角确实不能称之为模式改变。另外，《吃豆人》这款游戏虽然看似只有一种玩法模式，但我认为其实有两个：你弱就躲鬼；鬼弱被你追。在这两种模式下，你面临的挑战（躲鬼和抓鬼）都是非常不同的，即使观察视角、交互模式和动作都是一样的，但这两种挑战组成了不同的模式。我不会坚持这个观点，但从编写游戏文案的角度出发，我认为区别看待更好。

在《吃豆人》中，玩家追鬼其实是另一种玩法模式(from gamasutra)

除了主动玩法模式，大多数游戏还包括非交互型模式，如影像、积分榜、任务简介等等。从我们的目地来看，这些都是玩法模式，但有些完全没有挑战或动作可言，纯粹是显示信息。甚至一个暂停菜单也算是玩法模式的一种。

所以，这个问题“记录游戏设计要从哪开始？”的答案不过是：不要在游戏开头的部分开始。游戏的开头只是一闪而过的画面，或者可能是介绍影像。两者都不是非常重要，因为都不涉及交互活动，持续时间也短。应该从主要的游戏玩法模式开始，即占据玩家大部分时间（游戏邦注：60%至80%甚至以上）的部分。这是玩家体验的中心，是游戏的本质。首先定义游戏玩法模式，然后添加其他必要部分。

从一种玩法模式转换到另一种，取决于游戏的进展情况。这些过渡可以由玩家的动作引起（游戏邦注：如在运动类游戏中，玩家主动喊停，把新队员换上场）或者作为游戏进程的自发环节（当关卡结束，大多数游戏会自动转换到总结画面，让玩家得知自己的表现。）所有这些模式之间的关系就是游戏的结构。

记录游戏结构的最佳方式就是流程板。流程板是由流程图加故事板构成的。与分镜头表类似，流程板包含大量图片；但与电影故事板不同，流程板不是线性串联起来的。当然，各幅图片都是草图或某个玩法模式中的模型画面。在图片下面是模式的名称和对视角、交互模式及挑战/动作的简要描述。图片用箭头相连，以显示模式的转换方式，还要带上表明转换的原因及时间的文本注释。

图中表现的是老式投币游戏的简化流程板，图片用方框表示(from gamasutra)

在这个流程板中，没有获胜条件——游戏假定玩家最终会失败，这是一种经典的街机样式。另外，也没有让玩家投币继续游戏的功能，因为最早的街机游戏也没有。

注意，这个流程板其实并没有记录关卡本身。其意图是描述游戏的功能，而非内容。假设所有关卡在功能上都是相同的（老式街机游戏就是这样），那么流程板的要点就是向程序师和UI设计师传达他们需要制作的画面和模块。如果你把各个关卡当成独立的玩法模式，那么你的流程板就会非常庞大，多余的材料充斥其中。与此类似，在线性剧情类的大型PC游戏或掌机游戏中，你不必在流程板上记录剧情本身，除非游戏的视角、交互模式或玩法会随着剧情发生极大的变化。你要做的是，在另一个文件中记录线性剧情。

另外，如果你有分支剧情，但玩法的功能不会因为剧情转换而发生改变，那么你应该在另一个流程板上记录剧情，当然，剧情流程板是叙述性的，而不是功能性的。（游戏邦注：《银河飞将》就是一个典例：飞行任务中的战机的玩法都是相同的，但剧情如何发展取决于任务的结果。）程序师也必须过目叙述流程板，这样才能知道下个阶段的剧情分支；但是，如果你的剧情分支与功能分支混杂在一起，就只会增加代码编写过程（和流程板本身）的难度。

当剧情进展时，如果分支剧情的玩法不会发生重大改变，那么情况就复杂了。你必须把所有东西统一记录在一个庞大的流程板上。不过这样的情况我还没遇到过。一方面，制作这样的流程板太困难了，也太费时了——有那么多闲功夫，一款只有一两种玩法模式的游戏都做出来了。另一方面，大多数玩家偏好单一的游戏类型，而游戏类型是由玩法决定的。如果你的剧情需要游戏在数个相当不同的玩法之间切换，那么大多数玩家会弃之而去。

游戏玩法模式和流程板是我的游戏设计工作的中心，实际上也是我设计游戏的整体思路。回想当时我还在p.f. Magic公司工作时，我们曾给一个模式画了单独的图纸，并张贴到墙上，然后添加各个图片之间的箭头。这样，我们就给画面模型和符号腾出大量空间，而且所有团队成员都可以对整体流程板一目了然。如果我们需要重新组织什么东西，把图表移走也非常容易，省去了再次编辑打印大图的麻烦。

各位不妨试试吧！（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

Designer’s Notebook: Designing with Gameplay Modes and Flowboards

by Ernest Adams

Before I start this column, I have two announcements. First, it’s about time for another edition of my “Bad Game Designer, No Twinkie!” columns. (See my previous installments for game misfeatures, design errors, and personal annoyances covered in the past.) If you’ve got a game design gripe you’d like to get off your chest, send some E-mail to notwinkie@designersnotebook.com. Please be sure to mention a game that the Twinkie Denial Condition appears in. I can’t guarantee that I’ll use it, but I would definitely like to hear about it.

Second: if you are the chunky, dark-haired fellow with a maroon shirt and an Armenian last name who chatted with me on the mezzanine of the San Jose Convention Center at the Game Developers Conference, and accidentally left behind a signed copy of Richard Rouse’s book Game Design: Theory and Practice, I have it for you — drop me a line.

One of the questions I get asked a lot is, “How do you start designing a game?” It’s my belief that players play games — large games, anyway — to have an experience that they cannot have in the real world. The thing to do first, then, is imagine the nature of that experience. Once you have the experience in mind, you can move on to defining and documenting the gameplay. And, not coincidentally, another of the questions I get asked a lot is, “When you’re documenting a game design, where do you start?” This column is part of the answer.

A central idea at the heart of most videogames is the concept of the gameplay mode. This notion is intuitively obvious, but I’ve never seen an article or book that describes it directly, so here goes.

When a player plays a videogame, he experiences three things directly:

1) A means of perceiving the game world, which I call the perspective because it’s usually defined by a camera looking at 2D or 3D space from a particular point of view.

2) A means of influencing the game world, of projecting his will into it, which I call the interaction model. There are many of these, but two of the most common are the “avatar-based” and the “omnipresent” model, the former found in most action games, the latter in most board and war games.

3) The gameplay itself — the challenges he faces and the actions he may take to overcome those challenges. I prefer a somewhat more rigorous definition than Sid Meier’s “interesting decisions” — if a piece of interactive entertainment does not offer challenges, it’s not really a game. To me, challenges and actions make up gameplay, even though the definition is not perfect for all cases.

The conjunction of these three elements — perspective, interaction model, and gameplay — constitutes a gameplay mode, a particular way of playing the game. If any one of the elements changes significantly in the course of playing the game, then the player has moved into a new gameplay mode.

This description may seem a bit abstract, but a simple example will make it immediately recognizable. In a car racing game, the player spends much of his time driving the car. The perspective is usually out the windshield of the car; the interaction model is through treating the car as a mechanical avatar; and the gameplay consists of certain challenges (driving it safely, conserving fuel and tires, and of course finishing first) and actions (steering, accelerating, and braking) that address these challenges. The business of driving the car is a gameplay mode, and in most cases it is the primary mode.

In the Gran Turismo series, car modifications are made outside the racing environment. The player examines different types of equipment upgrades and can purchase them, a la a garage mechanic. The player can also tune and tweak existing parts.

Many serious racing sims include another gameplay mode, however, in which the player can make adjustments to the car to try to improve its performance. The perspective in this mode is usually a schematic diagram of the car — the player isn’t looking at the game’s setting at all. The interaction model is neither avatar-based nor omnipresent, but more that of a mechanical engineer working at a computer-aided design station. And of course the challenges and actions involve finding the optimum configuration of all the car’s various characteristics for maximum performance. Really dedicated players may spend 50% of their time, or even more, tuning the car and adjusting it for the current track and weather conditions.

Some games, such as Tetris or most adventure games, have only one gameplay mode. A few have two in which the player spends near-equal amounts of time. For example, in some war games you have to organize your troops for battle first, then actually fight the battle in a second phase. Nine Men’s Morris also includes two phases, one for placing the stones and a second one for moving them.

Complicated games can easily have a couple of dozen, or even more, gameplay modes. In an American football game, choosing and executing a single pass play typically involves six modes all by itself: selecting a formation; selecting a play; calling signals and the snap; backpedaling, choosing a receiver, and throwing the ball; maneuvering the receiver under the ball and catching it; and running downfield avoiding tacklers. In each of these, the perspective may not change, but the challenges facing the player and the user interface that implements the actions both do. The modes are avatar-based, but right in the middle of the play, the avatar switches from the quarterback to the receiver!

The boundaries of a gameplay mode are not sharply defined. Switching the camera from cockpit view to chase plane view in a flight simulator isn’t really significant enough to call it a mode change. On the other hand, it might seem that Pac-Man has only one gameplay mode, but actually I think there are two: running away from the ghosts when you are vulnerable, and chasing the ghosts when they are vulnerable. Your challenges are sufficiently different in each (catching versus avoiding being caught), that even though the perspective, interaction model, and available actions are the same in both, they constitute different modes. I don’t insist upon it, but from the standpoint of documenting the game, I think it helps to make the distinction.

The brief moments where the player begins chasing ghosts constitutes a different gameplay mode in Pac-Man.

In addition to the active gameplay modes, most games also include non-interactive modes as well-movies, high-score tables, mission briefings, and so on. For our purposes they’re all gameplay modes, but some of them have no challenges or actions; they’re only included to present information. Even a pause menu is a gameplay mode of a sort.

So the answer to the question, “where do you begin documenting a game design?” is simple: don’t begin at the beginning of a game. The beginning of the game is the splash screen, or maybe the intro movie. Neither is very important, because they’re non-interactive and they don’t last long. The place to begin is at the primary gameplay mode, the place that the user will spend most of his time — typically 60%-80% or more. This is the heart of the player’s experience, the part of the game that it is most essential to get right. Define the primary gameplay mode first of all, then add others as necessary.

As a game progresses, it frequently moves from one gameplay mode to another, depending on what’s going on in the game. These transitions can either occur as a result of player actions — the player calls time out in a sports game to send new athletes onto the field, for example — or automatically as part of the natural flow of the game. (When a level is complete, most games automatically move on to a summary screen to let you know how you did.) The relationship among all these modes is the game’s structure.

The best way to document the game’s structure is with a flowboard. The word is a combination of “flowchart” and “storyboard.” Like a storyboard, it consists of a number of pictures, but unlike a film storyboard, it’s not a linear series. Rather, each picture is a sketch, or mockup, of the screen in one particular gameplay mode. Under the picture is the mode’s name and a brief description of its perspective, interaction model, challenges, and actions. Connecting the pictures together are arrows showing how the modes switch from one to the next, with a text notation to indicate when and why the transition takes place.

Figure 1 shows a simplified version for an old-fashioned coin-op game, using boxes without the pictures.

Figure 1. Flowboard example.

There’s no victory condition in this flowboard–the game assumes that the player will eventually lose sometime, in classic arcade fashion. It also lacks a feature allowing the player to insert a coin to continue play, because the earliest arcade games didn’t have that.

Notice that this flowboard doesn’t actually document the levels themselves. It’s intended to describe the game’s functionality, not its content. The point of the flowboard is to convey to the programmers and user interface designers the key screens and modules that they will need to create, on the assumption that every level is functionally identical to every other level (as the old arcade games were). You could include each level as a separate gameplay mode, but then you’d have a very large flowboard with a lot of redundant material in it that the programmers don’t need. It’s better just to document the key modes (including the other housekeeping or non-interactive screens), and define the levels in a separate document.

Similarly, in a large PC or console game with a linear storyline, you don’t need to document the story itself in the flowboard unless the game’s perspective, interaction model, or gameplay change significantly as the story progresses. Instead, just write the linear story down in a separate document.

On the other hand, if you have a branching storyline but the functionality of the gameplay doesn’t change much from one episode to another, you should document the story in a separate flowboard — a narrative, as opposed to a functional, flowboard. (Wing Commander was a good example of this: the gameplay was the same for each mission-flying a starfighter — but the storyline branched based on the outcome of the mission.) The programmers will need to see the narrative flowboard too, to know which branch of the story to present next, but it will only complicate the coding process (and the flowboard itself) if you have narrative branches intermingled among the functional branches.

The most complicated situation of all occurs when you have a branching storyline whose gameplay does change significantly as the story goes along. Then you have no choice but to document them together as a single, gigantic flowboard. I don’t think I’ve ever seen such a game. For one thing, it would be difficult and time-consuming to program; it already takes long enough to build a game with only one or two kinds of gameplay in it. For another, most players like their game to stick to a single genre, and genres are defined by gameplay. If your story requires the game to switch between several kinds of radically different gameplay, most players are going to be put off.

Gameplay modes and flowboards are at the heart of my game design workshops, and indeed my whole approach to designing games. Back when I was working for p.f. Magic, we used to draw each mode on a single sheet of paper and stick them up on the wall, then add more sheets to show the arrows running between them. This gave us lots of room for drawing the screen mockups and penciling in notations, and the whole team could see the flowboard at once. If we needed to rearrange something, it was easier to pull down the sheets and move them than it would have been to edit a big drawing and print it all out again.

Give it a try! （source:gamasutra）