作者：Lewis Pulsipher

我总是对学生说，桌面游戏的规则就是用于详细描述游戏机制，所以这里的问题就是——“规则与机制的区别是什么。”当我私下与学生讨论这个问题时，我发现可能引起他们误解的内容主要是关于描述与说明，普遍与特殊之间的区别。

从教学观点来看，问题在于学生们总是会以自己的想法——即基于自己的意愿清单，而不是根据游戏的发展过程去描述游戏（经常是因为这些学生们通常都不知道游戏是如何发展的）。如果你正在撰写游戏规则或者游戏机制的相关说明，你就必须描写清楚游戏是如何“做到”这些内容。而一般描述则不足以帮助桌面游戏玩家更好地进行游戏，或者很难在程序员制作软件时给予适当的指示。

game rules(from planeta.wikispaces.com)

当你在构想一款游戏时，你可以说你想要使用某某机制，例如同时移动或战斗。但是当你在撰写规则或特定的游戏机制，不论是电子游戏设计文件还是真实的游戏规则，你都必须更加深入地描写一些细节内容（特别是关于战斗细节）。有时候，单单游戏机制的名称，如“同时移动”便能够透露给资深游戏玩家或者电子游戏开发者许多深入的内容，但是执行同时移动机制的方法有许多，而且你也必须清楚地阐明游戏规则或者有关特定机制的游戏设计文件内容。虽然这通常很难做到。

当你开始创造一款游戏时，你应该从“你希望游戏涉及哪方面内容”以及“你需要做些什么去实现这一设想”着手。我认为你将能够在中间阶段考虑游戏的结构问题，并且询问自己如何去弥合“是什么”与“怎么做”之间的差别。我们总是很难从对游戏的设想直接过渡到特定的游戏机制或者机制的分类中去。

回到最初的问题，即规则与机制的差别是什么？游戏规则必须包含机制的细节内容，以便玩家在阅读规则时便能够理解游戏机制。完整的规则必须描写游戏机制的相关内容。游戏机制是规则的一个子集。规则的基本目的是描写机制是如何运转的，并且同时也会包含其它内容。

同时，我也发现很多人对机制与玩家间的互动感到困惑。机制是游戏执行于玩家身上的一种行为，而玩家的行动则是基于自己的选择，并与机制产生交互作用而促成最后结果。桌面游戏要求玩家必须按照规则的说明执行机制。玩家玩游戏的行动并不属于游戏机制。

我们能够轻松地说出机制不是什么内容但是却搞不清楚“机制”到底是关于哪些内容。我曾经尝试将“所有”机制类别归为一个列表。而当我在网上搜索时发现，其他人所编写的“机制”的含义真的多种多样。而我也发现自己列出的内容都“处于边缘状态”。换句话说，也就是这些内容并不足以清晰地说明机制到底是什么或者不是什么。当讨论到机制时，我们更倾向于使用分类说明而不是详细描写。举个例子来说，“同时移动”或者“滚动和移动”属于游戏机制，并且可以通过不同方式加以执行。例如后者可以是“滚动两个骰子并向前移动你的方块”，或者“滚动两个骰子并根据第一个骰子以及第二个骰子所显示的数字向前或向后移动方块”，或者“滚动两个骰子，并根据其中一个骰子显示的数字或者两个骰子的数字之和向前移动方块”，或者“滚动两个骰子并且根据每个骰子显示的数字移动方块”等等。这些短语其实并不未提供足够的细节内容。它们是“滚动和移动”的四大分类内容，但是彼此间却存在着不同。如此看来，机制是明确的，而分类则是大体概述。

机制必须足够清晰，足够明确，不能存在任何具有误解性的描述。“如果情境A存在，玩家便能够做出选择”或者“如果玩家做了X，结果便是Y”，像这种包含“如果”的假设形式并不适合用于陈述机制。虽然你不需要非得成为程序员才能撰写规则，但是你在撰写规则时却需要如程序员在制作软件时的表达一样明确清晰。

尽管我并不能明确说出机制到底指什么，但是我却非常确定游戏规则中的某些内容并不属于机制。例如，游戏中的一些介绍，即告诉玩家关于游戏环境的信息以及他应该做些什么，不仅未提及游戏机制，甚至未阐明任何内容。还有规则前期的“如何获取胜利”部分，它只告诉玩家游戏目标而未说明获取胜利的任何详细机制。真正的获胜机制存在于主体规则的后部分，并且还包含能够决定游戏结尾的机制。早期的部分内容只是一些关于游戏环境的内容，以及游戏氛围或者主题的延伸。

我们能够从规则从看出游戏是否好玩。而一套优秀的规则将会包含一些例子，虽然它们不属于机制内容，但是却能够传达机制是如何运转的。虽然这部分内容呈现出的是不同环境，但却能够帮助玩家更好地进行游戏。

不管怎么说，规则的主要作用是用于直接描写游戏机制。你可以撰写一套只是阐述游戏机制的规则，但是对于玩家来说这种描写太过生硬，难以理解。传统游戏与现代游戏的一大区别便在于前者未包含太多机制，并且游戏规则中通常只包含一种机制，这可以让玩家清楚其中内容。

settlers of Catan(from reviews.cnet.com)

可以说，如果你的游戏面向的是那些不熟悉游戏的玩家，那么游戏规则就应该涵括更多信息而不是机制。当我购买了桌面游戏《卡坦岛》时我便肯定了这款游戏如此受欢迎的原因，因为游戏中设置了两套不同的规则，其中一套更是专门针对于不熟悉游戏的玩家们，帮助他们理解如何游戏。并且还有一个表格用于解释滚动两个骰子时的概率——这是游戏中一个非常重要的部分。虽然这些概率不属于游戏机制，但是确实滚动骰子机制的重要结果。对于那些不了解滚动骰子几率的玩家来说，这些内容尤为重要。同时，这也是游戏情境的一部分，尽管它并不属于游戏故事内容。但是正如故事与情境的关系一样，如果你理解滚动骰子的机率，你便能够知晓自己行动的意义，并更顺畅地进行游戏。

总体来看，游戏规则包含机制的说明以及游戏情境的描写。情境包含了氛围或主题以及其它与游戏相关的内容。

教授人们如何设计游戏需要重视的一大问题是，这些学生门并不清楚游戏机制会变得多么复杂，所以他们很少去正视这些机制。毕竟，他们早已习惯了电子游戏中那些执行于玩家身上且无需玩家费力的机制。如果他们玩过那些“人人都知道怎么玩”的传统桌面游戏——因为他们是伴随着这类游戏而长大，那么他们肯定不会把游戏玩法弄错。所以他们会想当然地认为可以在游戏中使用风险评估机制。但是这时候玩家就会问“风险评估机制到底是什么？”即使游戏设计师在一开始就使用了较为明确的机制名称，例如“同时移动”，但是仍然会有很多玩家对此感到疑惑。

所以结果便是，游戏设计学生在撰写规则时经常会遗漏掉一些重要事项。更糟糕的是，很多资深设计师在撰写规则初期也会犯这种错误，即使他们拥有充足的经验也不例外。我们必须重视这一问题。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Game descriptions, rules, and mechanics: what are the differences and similarities?

by Lewis Pulsipher

Recently a student in a video game design curriculum posted a note on the IGDA Game Design SIG about an assignment.  The assignment was to describe mechanics for a game and he said his instructor had told him he’d written rules instead, with the result being a poor grade.  I generally emphasize to students that the rules for a tabletop game detail the mechanics of the game, so the question became “what is the difference between rules and mechanics.”  And as I discussed this privately with the student I saw that part of the possible confusion was the difference between description and specification, between the general and the specific.

From a teaching point of view the problem is that students often describe what they would like a game to do– a wish list–but not how the game is going to do it.  (Which is usually because they really don’t have a clue how it’s going to do it.)  If you’re writing rules or writing a specifications of game mechanics you have to say how the game is going to “do it.”  (See “When you start a game design, conceive a game, not a wish list”http://pulsiphergamedesign.blogspot.com/2011/10/when-you-start-conceive-game-not-wish.html).  A general description is not good enough for tabletop players to play the game, or for game programmers to produce the software.

When you’re conceiving a game you can say that you intend to use such and such mechanic, for example simultaneous movement or combat using a combat table.  But when you write rules or specify mechanics, whether in a video game design document or in actual game rules, you’re going to have to go into much more detail (especially about combat).  Sometimes the name of the mechanic, such as “simultaneous movement,” can say a lot to experienced game players or video game developers, but there are lots of ways to implement simultaneous movement and your game rules or game design document specifying mechanics must be absolutely clear.  That’s hard to do.

When you’re starting a game you begin with what you want the game to do and you need to get to the point of how it’s going to do it.  I think there’s an intermediate stage where you’re considering the structure of the game, and that’s where my nine structural subsystems and the essential questions to ask yourself help you bridge the gap between the what and the how.  (The latest version of each will be in my forthcoming book about game design, and you can find versions on gamecareerguide.com.)  It’s usually hard to simply jump from what you want the game to do directly to the specific mechanisms or even to the categories of mechanisms.

But back to the original question, what is the difference between rules and mechanics?  The rules of a game must include details of mechanics so that someone reading the rules understands exactly how the mechanics work.  If the rules are complete, they MUST describe the mechanics of the game as well.  The mechanics are a subset of the rules.  The principle purpose of the rules is to describe how the mechanics work, but usually include other things as well.

By the way, I have seen people confuse what the player does with the mechanics of the game. Mechanics are what the computer enforces, the player’s actions are his choices that interact with the mechanics to provide a result.   A tabletop game requires the players to enforce the mechanics as specified in the rules.  Player actions to play the game are not mechanics.

But it’s easy to say what a mechanic is NOT.  I haven’t even attempted to get into the morass of exactly what a “mechanic” is.  I once started to make a list of “all” categories of game mechanics.  I quickly discovered as I looked around the Internet to see what other people have done that “mechanics” varies in meaning greatly from one place to another.  As I made my list I found many items “on the edges”.  In other words it is not clear what a mechanic is and what isn’t.   This is compounded by the tendency to use categories instead of specifics when discussing a mechanic.  For example, “simultaneous movement” or “roll and move” are categories of mechanics that can be implemented many ways.  For example, the latter can be “roll two dice and move your piece forward that many places,” or “roll two dice and move your piece forward or backward a number of spaces equal to one die and then the second” or “roll two dice and move your piece forward the distance equal to one of the dice, or the sum of both”, or “roll two dice and move one piece the distance of each die” and so forth.  And those brief phrases (especially the second one–I’m taking shortcuts) may not be sufficiently detailed to be absolutely clear.  All four are of the category “roll and move” but each is different from the others.  Mechanics are specific, categories are general.

Mechanics must be sufficiently explicit, sufficiently specific, that there can be no misunderstanding.  Most take the form of “if situation A exists, player can do (choices),” or, “if player does X, result is Y (with possible multiple possibilities)”, both forms of if:then:else statements.  You don’t have to be a programmer to write rules, but you have to be as explicit in the rules as programmers are in their software.

Despite the uncertainty about exactly what a mechanic is, I’m pretty sure there are some things in game rules that are not mechanics.  For example there’s usually an introduction,  something that gives the player an idea of the context of the game, what in general he’s doing, without referring to any mechanics let alone specifying any.  There is also early in the rules a “how to win” section that lets players know the objective of the game but does not necessarily specify all of the mechanics that determine who wins.  The actual mechanic(s) of winning are usually at the end of the main section of the rules along with mechanic(s) determining how the game ends.  The early sections provide a context for the play of the game, and extend the atmosphere or theme, if any.

A set of rules may also include hints about good play.  Finally, a good set of rules will include examples, which are not mechanics but which illustrate how the mechanics work.  These sections provide a different kind of context but are still included to help people enjoyably play the game.

Once again, however, the main thrust of rules is to describe exactly the mechanics of the game.  You could write a set of rules that only did that but it would seem abrupt to many players and might be difficult for some to grasp.  Something that sets traditional classic games apart from most contemporary games is that they have few mechanics and the rules can include only mechanics and still be understood by most gamers.

I think you could argue that the more a game is marketed to people who are not accustomed to playing games, then the more the rules will include information other than mechanics.  I thought it quite notable, when I first bought a copy of tabletop Settlers of Catan to find out what made it so popular (this is about 2004-5), that there were two differently-explained sets of rules included to try to help non-gamers understand how to play the game.  There was also a table showing the probabilities when rolling two dice, which is an important part of the game.  Those probabilities are not part of the mechanics but are a consequence of the mechanics of rolling two dice.  Yet for players who don’t understand the probabilities this inclusion probably helped.  Once again this is part of the context of playing the game although it’s not part of the story of the game.  But as with the story-context, if you understand the probabilities you’ll enjoy the game more and better understand what’s happening.

So we can in summary say that game rules include specifications of mechanics and a description of the context of the game: “how” and “what/why.”  That context can include the atmosphere or theme as well as other game-related material.

One of the problems of teaching people to design games is that they really don’t understand how complex game mechanics can become, and so they don’t try to set in their minds exactly what mechanics they’re going to use.  After all, most of them are accustomed to video games that enforce the mechanics on the players without effort from the players.  If they’ve played traditional tabletop games that “everybody knows how to play” because they grew up with them, they don’t remember misunderstanding how to play the games.  So they might think it enough to say that a game uses the risk assessment mechanic.  Well, the game player says, “what the heck is the risk assessment mechanic?”  Even if the beginning game designer uses a mechanic name that is more informative such as “simultaneous movement” there are still many more questions to be answered.

The result is that when students write rules they very commonly leave out important considerations.  But heck, even experienced designers leave out important considerations from early drafts of rules, despite all their experience.  So we keep plugging.（source:gamasutra）