作者：Raph Koster

Ian Schreiber在自己的Twitter上向众游戏设计师提出了一个问题，即“在你们每天使用的术语中，关于‘规则’和‘机制’有何区别？”

为了区分这两个术语，我甚至仔细思考了各种描述方式。

首先，我认为玩家和设计师对这两个术语的看法各有不同。

让我们以一个简单的例子为例：在游戏中跳跃。

在游戏中玩家将看到一个指示“你可以按压这个按钮而跳跃。”在此他们将看到一个规则，即如果他们错过了跳跃，便会掉落并死亡。他们同样也会知道，如果自己降落在敌人身上便能够杀死敌人，这便是另外一个规则。随后他们便会认为所有的这些内容就是游戏的跳跃机制。

如果以更正式的角度来看，我们可以使用Katie Salen和Eric Zimmerman在共同创作的《Rules of Play: Game Design Fundamentals》中所提到的术语，利用书中提到的3种规则类型分解“指示”和“规则”的定义。

基本规则是指那些牵扯到数理的内容。如掉落并死亡。或者从较高的屏幕上方掉落在敌人身上砸死它们。

操作规则是指出现在游戏指南中的规则。

隐含规则是指未明确指出的规则（例如，玩家死后控制台仍然保持运转）。

但是现在的关键是，玩家能够跳跃并降落在敌人身上并不是一种规则，因为这并不属于三大规则系统中的任何一种。

Hunicke, Zubek以及LeBlanc提出的MDA模型做了如下类比：

MDA框架将游戏分解成不同部分：

规则——>系统——>乐趣

并依此创建它们的设计对应体：

机制——>动态——>美学

MDA(from modelmetrics)

很明显，从这种模式中我们便清楚降落在敌人身上属于动态领域中的内容，动态描述的是机制运行行为是如何随着时间的发展作用于玩家的输入以及其他人的输出。

当我们着眼于MDA模型中的机制例子时，我们发现这里的定义都是以系统为中心——MDA实际上是一种系统化看待问题的方法。

在游戏设计的原子模型中，也就是所有游戏文法学家（游戏邦注：包括Raph Koster、Dan Cook和Stephane Bura等）所使用的模型，其核心原则便是游戏是由游戏所构成的，也就是我所提到的ludemes游戏元素（游戏邦注：最早出现于Ben Cousins提出的游戏理论，Dan将其称为“技能原子”）。每个ludeme拥有自己的规则；每个ludeme也将呈现出机制，动态和美学；以及最重要的内在游戏原子（并且它们是不断循环的）。从本质上来看，每个ludeme都是一个系统，或者说就像是一台小机器，当你进一步去研究这台机器时你将会发现一些更小的机器，而最终你能够从游戏中找到车轮，扳手，支点以及滑轮的等价元素。

很多ludemes并不含有Salen以及Zimmerman所描写的3种类型的规则。游戏文法只会关注基本规则，即它的目标是强调那些能够提供给玩家信息的特定ludeme。常见的高级ludeme（也包括ludeme群集）也就类似于Björk和Holopainen所提出的游戏设计模式。

在此，最重要的一点便是将反馈与ludeme中心的“黑盒子”机器区分开来。基于这种模式，我们便会将“掉落并死亡”直接理解为系统推动我们到达下一个平台所做出的反馈。所以这并不是一种规则，反倒更应该说是一种结果，而这却是两种完全不同的概念。

所以如果你问的是玩家，他们会告诉你掉落并死亡是规则，跳跃以及降落在敌人身上则是机制。

而如果你问设计师，你便可能获得各种不同的答案，因为就像我们上文所提到的，他们将根据不同工具理解游戏的运行方式。

所以：到底规则和机制是否相同，如果不同，它们又有何不同？我将从游戏文法的角度进行解释。

我倾向于规则是机制的构成要素。

我倾向于认为机制是ludeme的一种“黑盒子”元素或者说是技能原子。

所以让我们进一步解析这个跳跃例子：

1.这里存在一个预备阶段（即现有的动作向量，玩家角色的具体位置），并且这些内容是玩家在之前游戏中与ludeme的互动所造成的结果（所有的ludeme都拥有一个预备阶段，这些预备阶段可暗指“你之前所过的任何事”）。

2.这里有一个输入（即按压跳跃按钮）。玩家主要的认知挑战便是做出合理的预先准备，因为这是一种高度微粒化的移动，也就是意味着你在按压跳跃按钮时要考虑时机问题。

3.这里有一个目标，并且很大程度上取决于玩家的选择；他有可能“瞄准目标点”，也有可能选择“降落在敌人身上”。

4.输入操作将进入黑盒子系统中进行评估。

5.该系统将针对特定限制因素（游戏邦注：例如一些物理因素，如向上向量，重力影响，目的地位置等）评估输入操作的有效性。我将这些限制因素称之为规则，特别是基本规则。因为它们都是各自独立的内容；你可以去除重力影响，同样也可以添加降落惯性等。

6.状态将随结果而发生变化。就像“降落在目标点”的例子中，你可以选择是否这么做；而如此你也会收到掉落并死亡或者降落在某处的反馈。

7.而在降落到敌人身上的例子中，你将接触到一个独立的ludeme（目标是“毁灭敌人”），并且这个ludeme也拥有自己的规则，即“在Y轴的更高屏幕上方进行碰撞”。而这时候玩家所获得的反馈便取决于他们所遇到的规则。

8.总之，“跳跃”是一种机制，因为它包含了预备阶段和反馈。并且“跳跃到敌人身上”也是一种机制，因为它包含了整体的跳跃。

9.因此，MDA模型中的动态存在于机制与玩家美学体验之间——在此，游戏文法将美学体验定义为一种反馈，它是对黑盒子内容中心智模式的加工，也是我们的认知系统所触发的情感。

游戏邦注：原文发表于2011年12月13日，所涉事件和数据均以当时为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Rules versus mechanics

Ian Schreiber posted on Twitter asking

“Game designers: in your everyday use of the terms, is there a difference between “rules” and “mechanics”? If so, what?

I do make the distinction, and I had to think a bit about how to even phrase it. So here’s a quick thousand+ words on it.

First off, I think these are both terms that will feel different to a player vs a designer.

Let’s consider a simple example: jumping in a platformer.

In a platformer, the player sees the instructions “you can jump by pressing this button.” They see the rule that if they miss a jump, they fall and die. They also see that if they land on an enemy, it kills the enemy, which is another rule. They then think of all of this as the jumping mechanic.

From a more formal point of view, we can use Katie Salen and Eric Zimmerman’s terms and break apart the instructions and rules into the three types of rules that they describe in Rules of Play: Game Design Fundamentals.

Constituative rules are the ones that are mathematical. Fall and die. Make contact with an enemy whilst at a higher screen-space position, enemy dies.

Operational rules are what is printed in the instructions.

Implicit rules are unstated rules of behavior (no smashing the console when you die).

Now, the idea that you can jump and land on an enemy is not in here as a rule. That’s because it isn’t one. It’s emergent out of the system of rules.

The classic MDA paper by Hunicke, Zubek, and LeBlanc makes the analogy this way:

The MDA framework formalizes the consumption of games by breaking them into their distinct components:

Rules -> System -> Fun

…and establishing their design counterparts:

Mechanics -> Dynamics -> Aesthetics

Under this model, jumping to land on an enemy is clearly in the realm of Dynamics, which…describes the run-time behavior of the mechanics acting on player inputs and each others’ outputs over time.

The trick then is reconciling all of the Salen/Zimmerman rules types with this model. And indeed, when we look at examples of mechanics in the MDA paper, we find that the definition there tends to be centered around systems — MDA is essentially a system-based way of looking at things.

In an atomic model of game design, such as those used by all the game grammarians (myself, Dan Cook, Stephane Bura, etc), the core precept is that games are made out of games, which I call ludemes after Ben Cousins (Dan calls them “skill atoms”). Each ludeme has rules in its own right; each ludeme may exhibit mechancs, dynamics, and aesthetics. And most importantly, game atoms nest. They’re recursive. Essentially, each ludeme is a system, a little machine, and when you dig into what is inside the machine, you find smaller machines, eventually reaching the game equivalent of the wheel, the lever, the fulcrum, the pulley, etc.

Many of these ludemes will never have all three types of rules that Salen and Zimmerman describe. Game grammar focuses solely on the constituative rules. Its objective (as best described in Dan Cook’s article “The Chemistry of Game Design”) is to focus on what a given ludeme is teaching the player. Common higher-order ludemes (and therefore, clusters of ludemes) are then a direct match-up to Bj?rk & Holopainen’s game design patterns.

Critical to this is the notion of separating the feedback from the “black box” machine that lies at the heart of the ludeme. Under this sort of model, “falling and dying” is properly understood as being feedback given by the system on the way to a goal — reaching the next platform. So it isn’t a rule at all — it’s an outcome, which is not the same thing.

So, if you ask a player, they may tell you that falling and dying is a rule, and that jumping is a mechanic, and that landing on an enemy is also a mechanic.

If you ask a designer (well, a quasi-academic one like me), you might get a lot of different answers based on what of the above they use as their preferred tools for understanding how games work.

So: after all that, my answer to whether rules and mechanics are the same thing, and if not, how they are different! My approach will be biased by the game grammar way of looking at things.

I tend to think of rules as component elements of mechanics.

I tend to think of mechanics as the “black box” portion of ludemes or skill atoms.

So to decompose the jumping example:

1.There is a prep stage (existing vectors of motion, specific position of the player’s token). These arise out of previous interactions with ludemes in the game. (All ludemes always have a prep stage, which is implicitly defined as “everything you have done previously).

2.There is an input (pressing the button to jump). The key cognitive challenge is choosing the right prior prep, which given that this is a highly granular movement activity, largely means a timing problem of when to press the jump button.

3.There is a goal, which is largely determined by player agency. It may be “lan at targeted point,” it may be “land on an enemy.”

4.The input enters a black box system, where the input is evaluated.

5.In this case, the input is evaluated against specific constraints (physics such as vector upwards, effect of gravity, destination location). I call these rules — specifically, of the constituative sort. They are discrete; you can take out gravity, or add inertia on the landing, etc.

6.The state is updated with the result. In the case of “land at targeted point” you are basically going to make it or not. Feedback is given to the player of either falling and dying, or getting there.

7.In the case of landing on an enemy, you actually intersect with a separate ludeme altogether, which has as its goal “destroy enemy” and has as one of  its rules “collide while in a higher screen space position on the Y axis.” Feedback is given based on that rule being met.

8.In aggregate, “jumping” is then a mechanic, because it is inclusive of prep and feedback. “Jump on enemy” is a mechanic too, which includes the entirety of jumping (nested ludemes).

9.Dynamics therefore exist, as in the MDA model, in the interstices between the mechanic and the player’s aesthetics experience — which game grammar would specifically define as the feedback, the elaboration of the mental model of the contents of the black box, and the emotions that our cognitive system triggers as part of its own feedback mechanisms.(source:raphkoster)