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. 🙂
15 Responses to “Rules versus mechanics”
Sorry, the comment form is closed at this time.
Nice article, Raph!
I generally agree that mechanics are the “black box” (in the aggregate) and that rules are the paths from input to output of said box.
However, I disagree with your example that “Jump on enemy” is a Mechanic. To me, this is a Contextual result of the Rules that govern how the Mechanic “Jump” is handled. The direct, player-facing input is the action “Jump” (the input thus the mechanic); where and how the actor lands is a Context: on solid ground, no ground, on an enemy, etc. Contexts – in my mind – are the realm of Rules, not Mechanics. In chess, I take my Turn (mechanic). On my turn, I must Move a Piece or Forfeit (rule). When I Move a Piece (mechanic), it may move to an empty space without passing through any other pieces or to an opponent-controlled, occupied space on the game board in accordance with its move pattern (rule). If the Piece is moved to an opponent-controlled, occupied space, remove the opponent’s Piece from the board (rule). Capturing is not a “mechanic”; it is an outcome of the mechanic Movement given the Context of “Destination is Enemy-Occupied” and the Rule that the Piece previously occupying the space be removed from play.
Notice that Mechanics offer the player an option. Rules determine what happens after an option is selected.
Possible tweet reply: “Mechanics are processes with input options; Rules provide Contextual output results based on player input.”
And now you’ve got me thinking about what the “simple machines” of electronic gaming could be. So far I’ve got “movement”, “collision”, and “state change”, and can’t think of any more. 😛
Ooh! “Selection”! The screw to “collision”‘s inclined plane.
On topic, I like the distinction between “Rule” and “Mechanic”, but also see how different people might still draw (or describe) the line between the two in different ways. Well worth thinking about.
Technically, landing on an enemy has nothing to do with jumping at all. You can do it by falling off a ledge too. That’s why I said it’s at the intersection of multiple ludemes. The rule on landing on an enemy is not in the jumping system at all.
That’s why I see it as living at the systemic level, and therefore is a mechanic. Mechanics are often built out of smaller mechanics.
You notion of Context is basically the same as the notion of feedback and prior prep, I think. And a I said in the blog post, I agree that capturing is technically feedback (though overall, the notion of capturing is a mechanic — a given specific capture is feedback).
Seems easy enough to squeeze all of that into Twitter, just make a lot of tweets in series 😉 But seriously…
The thing that was most eye-opening from asking this question was just how many different answers there were. Paraphrasing the many responses, here are a few answers:
* Rules are constraints on the player, mechanics are more general.
* Mechanics are ways to modify the game state, rules are the way the players interact with the mechanics.
* Mechanics are individual atomic elements of how the game works (what you call “ludemes”), rules are combinations of related mechanics.
* Rules are individual atomic elements of how the game works, mechanics are combinations of related rules.
* Rules are the laws that govern the game, mechanics are the process of implementation.
* Rules are limits and constraints on what the player can do, mechanics are the set of things players can do.
* Rules are things the player can or can’t do. Mechanics are the player actions taken to achieve an objective.
* Rules are the contraints of the game that are exposed to the players. Mechanics are the underlying “black box” of how they are actually implemented.
* Mechanics are the smallest kind of gameplay events / event chains. Rules are the numeric relationships between various game objects/values (exact quantities, triggers, exchange rates, etc.)
* Mechanics are available player actions, rules are the conditions that govern when those actions are available + the effects of those actions on the game state.
* Rules are the game’s social contract with the player, mechanics are the enforcement of the rules.
* Rules are for non-digital games, mechanics are for video games.
In other words: “Yes, there’s a difference, but we’ll be darned if we can agree on what it is.”
Time to get the grammarians together to hash this thing out once and for all at the next GDC?
Thank you, Raph, for your thoughtful reply.
Thank you, Ian, for posing the question and for summarizing the answers!
I’m working with some Knowledge Organization folks to help us understand these kinds of questions.
Best,
–NK
The system I use also separates rules and mechanics.
Rules are simple statements like: “presing A the character jumps in such and such way”, “when the character hits floor it stops falling”, “if the character hits a block with the head, the block breaks”, “if the character lands on an enemy, the enemy dies”, etc.
Mechanics are collections of rules. For example, the jump mechanic could be the collection of all these rules.
I also use the term dynamics, but I use it to describe the ways mechanics interact with the players. Like strategies, mistakes, deceivings… For example: “run to an enemy and jump before hitting him trying to fall on top of it” or “trying to jump so close from a border to cross a gap that the character falls” or “enemy X jumps sometimes, so if the player tries to jump over it he can be hitted”
In a day to day use it can be useful to speak of “adding a rule to a mechanic to avoid some unwanted dynamic” and such.
So, for me, mechanics are convenient agrupations of rules, and dynamics are the way these rules behave while playing.
Ian, I like the idea of “forging a standard” to ease future GD work and communication. What about “getting together” all the people responsible for the tweets you received, and then, through internet discussion (maybe here, maybe at another “place” such as email discussions), we try to get to some “common standard”, by hearing everyone?
I think that uniformity of jargon is something very important to the area.
This would have to be true, as in the case of falling on an enemy and “killing” it. Technically speaking this would not fall under “Jumping.”
Jump
The action of rising into the air.
Falling
The action of traveling back to “ground level.”
Landing
The action of contacting “ground level.”
Those would all be “Mechanics” with their own sets of “Rules” to dictate how the action is carried out as a “Result,” such as how high one can jump or how far they can travel across a plane. The “Result” of killing an enemy that occupies a space you “Land” in would be the output of a mechanic that is activated via the rules of “Landing.”
To be thorough, one must consider all three things to properly build a fun game that would be simple for a player to understand. Rules, Mechanics, and Results. If any of those three are overly complicated (or strict,) then you will simply lose the attention of the player, or worse; cause them to cheat which severely diminishes the “play value” of the game and reduces the amount of time they will spend playing it.
That said, you must also cross-check the rules of one mechanic with the rules of the ones immediately affecting, or affected by it. For instance:
Input: Player presses A
Mech: Player Character (PC from here on out) lifts off ground.
Rule: Player stops rising at X vertical distance.
Mech: Player begins to fall.
Rule: Player falls at set speed.
Mech: Player lands.
Rule: Player dies or lands based on distance traveled in “Falling”
Result: Player kills enemy IF they “Land” in an “enemy space” AND have traveled less than the maximum distance allowed in “Falling.”
One may also set a conditional mechanic to output a result for special cases, such as being able to “Fall” further if landing on an enemy.
I think the whole communication process could be made simpler if developers recognized the importance and differences in all three terms for base design. Sometimes (though often considered counter-intuitive) things must become more complicated to flow more efficiently.
As a note: I am not a game developer, just a fan who understands how complicated and in-depth the process can be. I’m one of those odd people that often breaks things down to their base elements to figure out how it works, and finds it rewarding. I can’t begin to tell you how many times I have defended developers when it came time to implement a bug fix. Most people never care what goes into the process, so I try to fight the ignorance wherever I can. So, if I am completely wrong, just tell me I’m stupid; I can take it, lol. I hope the coding I included in this works…
[…] First, let’s consider what a mechanic is. A month ago, Raph Koster wrote a blog about the difference between mechanics and rules. While rules are not related to what I am talking about here, his post describes mechanics rather […]
[…] box, and the emotions that our cognitive system triggers as part of its own feedback mechanisms.(source:raphkoster) 分享到： QQ空间 新浪微博 开心网 […]
[…] game), as can parameters (eg. your run versus your sprint speed in a first person shooter). Some prominent designers consider the rules or mechanics to be a black box. They certainly can be in some cases, […]
[…] game), as can parameters (eg. your run versus your sprint speed in a first person shooter). Some prominent designers consider the rules or mechanics to be a black box. They certainly can be in some cases, […]
[…] Rules vs. Mechanics. Raph Koster’s blogpost (2011). […]
[…] Koster, R. (2011). “Rules versus mechanics”. Retrieved 29/08/2012, from: https://www.raphkoster.com/2011/12/13/rules-versus-mechanics/ […]
[…] Araújo & Roque, 2009; Cook, 2006, 2007; Hunicke, LeBlanc & Zubek, 2004; Koster, 2005, 2011; Sicart, 2001), but the most relevant idea here is that a mechanic is a metaphor for the actual […]