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:

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).
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.
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."
The input enters a black box system, where the input is evaluated.
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.
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.
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.
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).
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.

So no, to me rules and mechanics are not exactly the same, Ian. But I couldn't think of how to fit the above into a Tweet.