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-...). 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.
