作者：Ian Schreiber

上一次我的问题是：游戏是什么？而今天，我想探究一个相关的问题，也就是：真正的游戏设计是什么？上一次，我们制作了一款简单的游戏。而这次，我们将观察游戏是如何制作而成。也许只花15分钟去制作一款完整的桌面游戏不成问题，但是如果你是想要制作出像《卡坦岛》或者《魔兽世界》这类型游戏大作的话，你便真的需要多花些时间好好思考。（请点击此处阅读本系列第1、第3、第4、第5、第6、第7、第8、第9、第10、第11、第12、第13、第14、第15、第16、第17、第18课程内容）

游戏设计

“设计”这个单词将会频繁出现在这篇文章中，但是很不幸的是，在各类型文章中，这个词的使用实在太过于泛滥，所以我想在此详细解释我所说的“设计”到底指什么。就像在《Challenges》中，游戏设计便是单纯指代游戏规则和内容的创造。其中并不包含编程，艺术，动画，市场营销或者其它游戏制作所要求的任务。所有的这些任务集中在一起被称为“游戏开发”，而游戏设计只是游戏开发中的一个部分。

各种类型的游戏设计

就像我们所提到的《Challenges》，它的游戏设计便体现了各种任务，包括系统设计，关卡设计，内容设计，用户界面设计，建造世界以及故事编写等。你可以花10周的时间去学习这些任务的相关课程，但我们的这系列课程将不会囊括游戏设计中的所有范围。我们将会略提到用户界面，故事编写以及相关内容，但本课程的主要焦点还是系统设计（有时候我们也称之为“核心系统设计”）。

系统设计是关于定义游戏的基本规则。游戏的每个部件分别是什么？你要如何控制它们？你在每一步过程中会采取何种措施？你的每次行动会有何结果并且这些结果将如何影响游戏？总的来说，系统设计可以概况为三大创造：

设置的规则。游戏是如何开始？

游戏进程的规则。一旦游戏开始后，玩家能够做什么，并且他们的行动会产生何种结果？

结果的规则。是什么导致游戏的结束？如果游戏产生了结果（如胜利或失败），那么这一结果能够决定什么？

如果你玩过《Three-to-Fifteen》这款游戏，你将会发现游戏中的所有部分都包含了非常简单的规则。正是系统设计创造了这些规则，而我们将花一整个夏天的时间对其进行研究。

游戏设计师的定义

你也许注意到了，游戏设计是一个非常广阔的领域。尽管是作为专业游戏设计师的我们，也很难解释我们所从事的工作对于家人和朋友有何影响。一部分原因可能是因为我们需要接触的事物实在太多了。以下是我所接触到的用于形容游戏设计者的一些类比：

游戏设计师是艺术家。“艺术”这个词很难用于定义“游戏”，但是如果游戏算是一种艺术形式（游戏邦注：就像资深的游戏设计师Costikyan所定义的那样），那么游戏设计者也就自然等同于艺术家了。

游戏设计师是建筑师。建筑师的工作并不是建造实质的建筑物，而是创造建筑蓝图。视频游戏设计者同样也是在创造“蓝图”，也就是我们所说的“设计文档”。桌面游戏设计者同样也在创造蓝图，即游戏原型，并最终交由发行商进行大量生产。

游戏设计师是派对主持人。作为设计者，我们会邀请玩家进入我们所创造的游戏世界，并努力为他们营造一个美好的时刻。

游戏设计师是做研究的科学家。我将在后面提到，创造游戏的方式其实类似于创造科学观点。

游戏设计师是上帝。我们创造了世界，也创造了能够支配这个世界的物理定律。

游戏设计师是律师。我们创造了一系列规则，并引导多数人按照这一规则行事。

游戏设计师是教育者。在阅读了《Theory of Fun》之后，我们会发现娱乐和教育是紧密联系着的，游戏之所以有趣是因为其中蕴含了一些新的学习技巧。

如果游戏设计包含了这些所有内容，那么就高校课程来说，它应该属于哪一门学科呢？它可以被归类到教育学院，艺术学院，建筑学院，神学研究院，娱乐管理院，法学院，工程学院，应用科学院等等。

但是否游戏设计师的定位就只有这些？或者什么都不是？这是一个值得讨论的话题，但是我认为，游戏设计者虽然拥有各个领域的多种因素，但是却仍然伫立在一个属于自己的领域中。而且这也是一个非常广阔的领域。当游戏设计领域进一步发展，我们也许在将来的某一天能够看到，那些专攻于“游戏设计”的设计者们将被会被细分到更多更加专业的领域，就像“科学”领域的学生也有自己的专攻学科（游戏邦注：如化学，生物，物理等）。

游戏设计的科学

如何进行游戏设计？方法众多。

从历史上来看，第一种游戏设计方法也就是我们所说的“瀑布模式”：先在纸上设计出整款游戏的轮廓，随后去执行这个设计（游戏邦注：可使用电子游戏编程或者创造出非数据游戏的模版和组建），然后测试它以确保所有规则的合理性，并添加一些图像让游戏整体看起来更加好看，最后发行游戏。

瀑布模式

瀑布模式之所以如此命名是因为整个流程就像是倾泻而下的水流，你只能朝着一个方向前进。在这个模式下，如果你在最后几个步骤中遇到一些需要改变的规则，那么就糟糕了，因为在这里，方法论规定你不能回到之前的设计步骤中。

有时候，有些人认为如果能够选择回到之前的步骤去修正一些内容是个不错的主意，而这也是我们后来所说的迭代式方法。而如果是瀑布模式，我们便只能沿着设计游戏，执行设计，并确保设计可行这一直线路而行动了。但是你也可以在后来添加一个额外的步骤去评估你的游戏。玩游戏并判断它是否有趣或者哪里需要做出调整。随后做出决定：你是否完成了任务，还是你应该回到之前的设计步骤进行一些完善？如果你认为游戏足够优秀了，那么你便完成了所有工作。但是如果你认为游戏尚待调整，那么你就需要回到之前的设计步骤，找到问题所在，并针对性地进行修改，然后再次评估游戏。反复进行这一过程直到游戏真正得以完善。

如果你认为这种方法很耳熟，那是因为它其实等同于科学理论：

1.观察。（“我在玩游戏或者制作游戏中的体验都证实了一些游戏机制的趣味性。”）

2.假设。（“我认为我所编写的这系列特别规则将能够制作出一款有趣的游戏。”）

3.创造一个试验去证实或反驳这一假设。（“组织游戏测试并观察游戏是否具有趣味性。”）

4.执行试验。（“让我们玩游戏。”）

5.阐述试验结果，并组成一系列新观察。重新回到第一个步骤。

即使是非数字游戏（如卡片或者桌面游戏），这个过程也同样适用，因为它们能够更快速地得以实行。而即使是电子游戏在执行这一过程的时候也会出现一个问题：执行的成本（如编程和试调）过高，并且很耗时。如果你只有2年的游戏开发时间，而单单编程就消耗了你18个月，那么你将没有多余的时间去进行游戏测试和完善。

但是一般来说，迭代次数越多，你最后成品的游戏也会越优秀。

因此，任何游戏的设计过程必须包含尽可能多的迭代过程（也就是必须包含设计，执行与评估这整个循环过程），而如果你能够越快执行这些过程，那么你将能够创造出更棒的游戏。所以，电子游戏设计师经常会先在纸上画出游戏原型，并在他们肯定了游戏的核心原则之后交由编程员进行游戏编程。我们将这一过程称之为“快速原型”。

迭代和风险

游戏总是避不开风险。包括设计风险，即游戏可能不够有趣，玩家不喜欢游戏；执行风险，尽管规则很明确，但是开发团队却没有能力完成所有的开发任务；市场风险，尽管游戏很有趣，但是却没人愿意购买等等。

迭代的目的是降低设计风险。游戏的迭代次数越多，游戏规则的有效性便越有保障。

这些都可以归结成重要的一点：如果你的游戏存在越多设计风险（也就是你未曾测试或完善游戏规则），你就需要越频繁地进行迭代。但是如果一款游戏的机制是借鉴于其它成功游戏，那么迭代方式便不适用于这款游戏；也就是说对于那些受欢迎游戏的续集作品，往往更加适合采用瀑布模式。

但是绝大多数游戏设计师都希望能够制造出富有创造性的新游戏。

为何本课程主要关注非数字游戏…

也许有些人喜欢制造桌面游戏，所以并不关心电子游戏的制作。但是对于那些热爱电子游戏制作的人来说，便会好奇为何我们在这个课程里花了这么多时间都在阐述如何制作桌面游戏和纸牌游戏。而现在你们应该知道答案了吧：因为对于纸牌游戏和桌面游戏来说，迭代的方法更加快速且便宜。就像我们曾在之前的课程提到的：你可以花15分钟制作一款桌面游戏。游戏编程需要很长时间。所以你需要尽可能地先在纸上绘出游戏原型，因为15分钟的纸上原型绘制以及1个小时的游戏测试，都可能帮助你节省数个月的编程工作。

我们将在后面的课程中讨论纸上模型的相关细节问题，即包括传统桌面游戏和其它类型的电子游戏。

这也是我们的课程为何侧重于非数字游戏，特别是桌面游戏和纸牌游戏的另一大原因。这是一个关于系统设计的课程，也就是关于创造游戏规则的课程。桌面游戏的规则总是很直白。虽然其中也包含了一些实质性元素，但是说实在的，玩家的游戏体验几乎完全依靠于游戏规则和玩家交互性。如果游戏规则没有说服力，那么游戏也就不会有趣，所以我们在制作游戏的过程中应该更加关注于游戏规则和玩家体验间的联系。

但是在电子游戏中却不是这样。许多电子游戏中都带有一些让人印象深刻的技巧（如现实般的物理引擎），图像和音效，以此掩盖它们陈旧的游戏设置。而且电子游戏的制作过程都很漫长（归因于编程和艺术/音频的制作），所以只花十周的课程根本不可能制作出一款电子游戏。

在角色扮演游戏中，游戏规则和玩家体验也是个让人苦恼的组合。你们中有许多人也许对角色扮演游戏设计感兴趣，所以你们可能会对游戏规则和玩家体验感到陌生。但是不管怎样，你都需要牢记，角色扮演游戏是故事的集合体（并且由一大规则系统去限制游戏界限）。同样地，再优秀的系统也会因为玩家拙劣的讲故事能力和游戏技巧而黯然失色，而再糟糕的系统也可以因为玩家的高超技术而生辉。如此，我们选择，或者只是在最初阶段，避开这些游戏类型。

尝试

如果你还未玩过之前那款只花了你15分钟而完成的游戏，那么就去尝试看看。当你在玩的时候，问自己：比起你曾经发布过的最受欢迎的游戏，这款游戏是更加有趣还是相对无聊？为什么？你是否能够改变并完善它？你无需坚持到游戏最后，只要找到感觉，知道如何做才能更好地改进这款游戏，你便可以停止尝试。

在你退出游戏后，至少针对游戏做出一个改变。你可以改变游戏运转规则，或者为玩家添加一个新的互动方式。你还可以改变纸牌的移动空间等等。不论你是出于何种原因做了何种改变，你都必须在改变后再次尝试游戏。记下变化。关于你所做的改变是否对游戏有帮助。你是否可以根据这次的改变而设想下一次的改变？如果游戏因为改变而变得更加糟糕，你是否会将规则恢复到之前的样子，还是按照其它方式再次进行调整？

我们将在后面的课程中进一步阐述游戏测试过程中的细节问题。而现在，我只是希望所有人都能够克服一种恐惧，即“如果我尝试自己制造的游戏结果会怎样？会不会很失望？”我猜测你根据课程一所设计游戏失败几率非常高（我们怎么可能只花15分钟而制造出一款类似于《战争机器》的游戏？）。但这并不表明你就是一个“糟糕的设计师”，只能说明如果你能够投入更多时间，并反复进行迭代，那么你一定能够制造出一款非常优秀的游戏。

经验教训

从今天开始你应该明白一个道理，游戏迭代次数越多，它就会变得越优秀。实际上，优秀的设计者并不擅于制造好游戏。相反地，他们更擅于将一款糟糕的游戏进过反复迭代，而让其变成真正优秀的游戏。

以下是两大必然结果：

你希望能够尽早想出一个可游戏的游戏原型。越快测试你的观点，你便拥有更多的时间去完善游戏。

从时间来看，短而简单的游戏比起长而复杂的游戏，能够提供更棒的游戏体验。也就是如果一款游戏需要你花费10个小时的时间，那么你将没有多余时间去进行游戏迭代，而你将更加倾向于另外一款只需要5分钟便能完成的游戏。特别是在后面即将开始的设计项目课程中，你更需要牢记这一点。

家庭作业

我将在下一个讨论游戏形式因素的课程中涉及：

《Challenges for Game Designers》第二章节（Atoms）。这部分内容可以作为下周我们将分析的“游戏”概念的过渡点。

Doug Church的《Formal Abstract Design Tools》。这篇文章是基于Costikyan的《I Have No Words》，而提供一些有用的道具帮助我们分析并设计游戏。文章里提到了许多关于电子游戏的例子，请试想一下这些概念是否也适用于其它类型的游戏。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Level 2: Game Design / Iteration and Rapid Prototyping

Last time we asked the question: what is a game? Today, we look into a related question: what, exactly, is game design? Last time, we made a simple game. This time, we will look into the process of how games are made in general. While it is possible to make a race-to-the-end board game in 15 minutes, you will need to take a little longer if you are looking to make the next Settlers of Catan or World of Warcraft.

Course Announcements

Some administrative things that have come up since Monday:

?    First, I would like to apologize to those who are registered for the misbehavior of the wiki. It was sending out hourly announcements of updates… and there were a lot of updates! I have attempted to turn off these updates, so you should hopefully not receive any more “wiki-spam” but if you do, you can shut it off manually by going to your own settings and changing notifications to “Never.”

?    As of 5am GMT this morning, the discussion forums are set up and operational. I look forward to seeing some really great discussion. There were quite a few spambots that tried to register, so I had to check every forum account against course registrations. If you got an email that your account was rejected, it just means I was unable to match it up to a course registration; please try again. If you have not yet created a forum account, you can make it easiest for me by using the same email on the forums that you used to register for this course… and if you’re unwilling to do that, at least put some kind of identifying information in there (like your name and location) so I can find you in the list. Thank you.

?    Lastly, to those of you who sent in a registration email after the course started (that is, if your email was timestamped after Monday, noon GMT), I apologize for not being able to add you after the fact. Registration emails have taken a lot of my time prior to the start of the course, and if I accept late registrations I will not have the time to do other things for the course. Whether you are registered or not, this blog is free and open to the public (as is the Twitter feed), and I hope you do still follow along and get a lot out of the experience.

Game Design

We will use the word “design” a lot in this course, and unfortunately it is a term that is a bit overused, so I will clarify what I mean here. As it says in Challenges, game design is the creation of the rules and content of a game. It does not involve programming, art or animation, or marketing, or any of the other myriad tasks required to make a game. All of these tasks collectively can be called “game development” and game design is one part of development.

Unfortunately, I have seen the term “design” used (particularly in some college curricula) to refer to all aspects of development. When used in the video game industry (or the board game industry), “game design” has a very specific meaning, and that is the meaning that we will use for this course.

Multiple Types of Game Design

As mentioned in Challenges, there are many tasks associated with game design: system design, level design, content design, user interface design, world building, and story writing. You could fill several 10-week courses with any one of these, so this summer course will not be a full treatment of the entire range of game design. We will touch lightly on UI, story writing and content when relevant, but the majority of this course focuses on system design (also sometimes called “systems design” or “core systems design”).

System design is about defining the basic rules of the game. What are the pieces? What can you control? What actions can you take on your turn (if there are “turns” at all)? What happens when you take each action, and how does it affect the game state? In general, system design is the creation of three things:

?    Rules for setup. How does the game begin?

?    Rules for progression of play. Once the game begins, what can the players do, and what happens when they do things?

?    Rules for resolution. What, if anything, causes the game to end? If the game has an outcome (such as winning or losing), how is that outcome determined?

If you look back at Three-to-Fifteen from Monday, you’ll notice those very simple rules contain all of these parts. The creation of those rules is system design, and that is what we will be spending most of our time with over this summer.

What is a Game Designer?

As you may have noticed, game design is an incredibly broad field. Those of us who are professional designers sometimes have trouble explaining what we do to our families and friends. Part of the reason for this is that we do so many things. Here are some analogies I’ve seen when trying to explain what it is like to be a game designer:

?    Game designers are artists. The term “art” is just as difficult to define as the word “game”… but if games can be a form of art (as we saw in Costikyan’s definition, at least), then designers would be artists.

?    Game designers are architects. Architects do not build physical structures; they create blueprints. Video game designers also create “blueprints” which are referred to as “design docs.” Board game designers create “blueprints” as well — in the form of prototypes — which are then mass-produced by publishers.

?    Game designers are party hosts. As designers, we invite players into our space and try our best to show them a good time.

?    Game designers are research scientists. As I will touch on later today, we create games in a manner that is very close to the scientific method.

?    Game designers are gods. We create worlds, and we create the physical rules that govern those worlds.

?    Game designers are lawyers. We create a set of rules that others must follow.

?    Game designers are educators. As we will see later when we start reading Theory of Fun, entertainment and education are strongly linked, and games are (at least sometimes) fun because they involve learning new skills.

If game design is all these things, where would it fit in a college curriculum? It could be justified in the school of education, or art, or architecture, or theology, or recreation management, or law, or engineering, or applied sciences, or half a dozen other things.

Is a game designer all of these things? None of them? It is open for discussion, but I think that game design has elements of many other fields, but it is still its own field. And you can see just how broad the field is! As the field of game design advances, we may see a day where game designers are so specialized that “game design” will be like the field of “science” — students will need to pick a specialty (Chemistry, Biology, Physics, etc.) rather than just “majoring in Science.”

Speaking of Science…

How is a game designed? There are many methods.

Historically, the first design methodology was known as the waterfall method: first you design the entire game on paper, then you implement it (using programming in a video game, or creating the board and pieces for a non-digital game), then you test it to make sure the rules work properly, add some graphical polish to make it look nice, and then you ship it.

Waterfall is so named because, like water in a waterfall, you can only move in one direction. If you’re busy making the final art for the game and it occurs to you that one of the rules needs to change, too bad — the methodology does not include a way to go back to the design step once you are done.

At some point, someone figured out that it might be a good idea to at least have the option of going back and fixing things in earlier steps, and created what is sometimes known as the iterative approach. As with waterfall, you first design the game, then implement it, and then make sure it works. But after this you add an extra step of evaluating the game. Play it, decide what is good and what needs to change. And then, make a decision: are you done, or should you go back to the design step and make some changes? If you decide the game is good enough, then that is that. But if you identify some changes, you now go back to the design step, find ways to address the identified problems, implement those changes, and then evaluate again. Continue doing this until the game is ready.

If this sounds familiar, it is because this is more or less the Scientific Method:

1.    Make an observation. (“My experience in playing/making games has shown me that certain types of mechanics are fun.”)

2.    Make a hypothesis. (“I think that this particular set of rules I am writing will make a fun game.”)

3.    Create an experiment to prove or disprove the hypothesis. (“Let’s organize a playtest of this game and see if it is fun or not.”)

4.    Perform the experiment. (“Let’s play!”)

5.    Interpret the results of the experiment, forming a new set of observations. Go back to the first step.

With non-digital (card and board) games, this process works fine, because it can be done quickly. With video games, there is still one problem: implementation (i.e. programming and debugging) is expensive and takes a long time. If it takes 18 months to code the game the first time and you only have two years, you will not get a lot of time to playtest and modify the game.

In general, the more times you iterate, the better your final game will be.

Therefore, any game design process should involve iterating (that is, going through an entire cycle of designing, implementing and evaluating) as much as possible, and anything you can do that lets you iterate faster will usually lead to a better game in the end. Because of this, video game designers will often prototype on paper first, and then only get the programmers involved when they are confident that the core rules are fun. We call this rapid prototyping.

Iteration and Risk

Games have many kinds of risk associated with them. There is design risk, the risk that the game will not be fun and people won’t like it. There is implementation risk, the possibility that the development team will not be able to build the game at all, even if the rules are solid. There is market risk, the chance that the game will be wonderful and no one will buy it anyway. And so on.
The purpose of iteration is to lower design risk. The more times you iterate, the more you can be certain that the rules of your game are effective.

This all comes down to one important point: the greater the design risk of your game (that is, if your rules are untested and unproven), the more you need iteration. An iterative method is not as critical for games where the mechanics are largely lifted from another successful game; sequels and expansion sets to popular games are examples of situations where a Waterfall approach may work fine.

That said, most game designers have aspirations of making games that are new, creative, and innovative.

Why This Course is Non-Digital…

Some of you would rather make board games anyway, so you don’t care how video games are made. But for those of you who would love to make video games, you may have wondered why we will be spending so much time making board and card games in this course. Now you know: it is because iteration is faster and cheaper with cardboard. Remember from Monday: you can make a board game in 15 minutes. Coding that game will take significantly longer. When possible, prototype on paper first, because a 15-minute paper prototype and an hour-long playtest session can save you months of programming work.

Later in this course, we will discuss in detail methods of paper prototyping, both for traditional board games and also for various types of video games.

There is another reason why we will concentrate primarily on non-digital games this summer, particularly board and card games. This is a course in systems design, that is, creating the rules of the game. In board games, the rules are laid bare. There may be some physical components, sure, but the play experience is almost entirely determined by the rules and the player interactions. If the rules are not compelling, the game will not be fun, so working in this medium makes a clear connection between the rules and the player experience.

This is not as true in video games. Many video games have impressive technology (such as realistic physics engines) and graphics and sound, which can obscure the fact that the gameplay is stale. Video games also take much longer to make (due to programming and art/audio asset creation), making them an impractical choice for a ten-week course.

The connection between rules and player experience is also muddied in tabletop role-playing games. I realize that many of you have expressed an interest primarily in RPG design, so this may seem strange to you. However, keep in mind that an RPG is essentially a collaborative story-telling exercise (with a rules system in place to set boundaries for what can and can’t happen). As such, a wonderful system can be ruined by players who have poor story-telling and improv skills, and a weak system can be salvaged by skillful players. As such, we will stay away from these game genres, at least in the early stages.

Trying it out

Take that 15-minute game you made last time, and play it, if you haven’t already. As you are playing, ask yourself: is this more fun or less fun than playing your favorite published games? Why? What could you change about your game to make it better? You do not have to play the game to completion, but only for as long as it takes you to get the overall feeling of what it is like to play.
Then, after playing once, make at least one change. Maybe you’ll change the rules for movement, or add a new way for players to interact. Maybe you’ll change some of the spaces on the board.

Whatever you do, for whatever reason, make a change and then play again. Note the differences. Has the change made the game better, or worse? Has this one change made you think of additional changes you could make? If the game got worse, would you just change the rule back, or would you change it again in a different way?

We will be looking at the playtest process in detail later in this course. For now, I just want everyone to get over that fear: “what if I play my game and it sucks?” With the game you designed on Monday, the odds are very high that your game does suck (seriously, did you expect to make the next Gears of War in 15 minutes?). This does not make you a “bad designer” by any means — but it should make it clear that the more time you put into a game and the more iterations you make, the better it gets.

Lessons Learned

The one big takeaway from today is that the more you iterate on a game, the better it becomes. Great designers do not design great games. They usually design really bad games, and then they iterate on them until the games become great.

This has two corollaries:

?    You want to have a playable prototype of your game as early in development as possible. The faster you can playtest your ideas, the more time you have to make changes.

?    Given equal amounts of time, a shorter, simpler game will give a better experience than a longer, complicated game. A game that takes ten hours to play to completion will give you fewer iterations than a game that can be played in five minutes. When we start on the Design Project later in this course, keep this in mind.

Homeplay

Before next Monday, read the following. I will be referencing these in Monday’s content when we talk about the formal elements of games:

?    Challenges for Game Designers, Chapter 2 (Atoms). This will act as a bridge between last Monday when we talked about a critical vocabulary, and next Monday when we will start breaking down the concept of a “game” into its component parts.

?    Formal Abstract Design Tools, by Doug Church. This article builds on Costikyan’s I Have No Words, offering some additional tools by which we can analyze and design games. While he does use many examples from video games, think about how the core concepts in the article can apply to other kinds of games as well.（source:gamedesignconcepts）