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.