|
Game mechanics are harder to talk about than any other aspect of game design. The terms we use are largely abstractions -- things like negative feedback loop and difficulty progression. They're a nuisance to prototype and test, too, because unless they're simple enough to implement in a board game, you have to either write code or use a spreadsheet, and neither one is particularly fast or intuitive.
Recently I've co-written a book that's (partly) about a better way to do it. The book is called Game Mechanics: Advanced Game Design, published by Peachpit and available here. (Instructor and media review copies are also available free to qualified applicants). This month's column condenses part of chapter 5 of the book. My co-author is Joris Dormans, a Dutch game designer and scholar.
Joris created a free tool called Machinations that I think will revolutionize the way we develop, and teach, game mechanics. (I really don't like hype, so I don't say that lightly.) Here, I'm going to introduce what Machinations is and what it does.
Machinations is a visual language for diagramming game economies, and a tool for drawing, and above all, simulating them without writing code.
Joris (pronounced YOR-is) had read my book Fundamentals of Game Design and created a way to diagram some of the basic features of internal economies that I talked about: resources, sources, drains, converters, and traders. Then he added several more that make his system more powerful and flexible.
How the Machinations Tool Works
The Machinations Tool allows you to create and save digital versions of Machinations diagrams and see how they change over time. The Tool looks similar to an object-oriented 2D drawing application such as Microsoft Visio. It has a workspace in the middle and a variety of selectable tools in a side panel.
 The Machinations Tool, available at www.jorisdormans.nl/machinations
When you tell the tool to run, it performs the events that are specified by the diagram in a series of time steps or iterations (we use the terms interchangeably). The tool changes the state of the diagram. When it has completed one iteration, the tool then executes another with the diagram in its new state, and so on, repeatedly until you tell it to stop. You can control the length of each time step by setting an interval value; if you want the tool to run slowly, you can set the interval to several seconds per time step.
 A simple Machinations diagram running. The small circles are resources, either stored in a node, or moving from node to node.
Machinations diagrams permit you to abstract as much or as little as you like. You can use them to focus on all, or only part, of a game's mechanics. Using Machinations diagrams, you can design and test your game's mechanics at different levels of detail. For example, it's often sufficient to model a game from the perspective of a single player, even if the game is actually played by multiple players. In other cases, it's useful to model the mechanics for one player at a higher level of detail than other players. Or you can leave out certain aspects of the game, such as players taking turns.
Machinations Diagram Basic Elements
The Machinations framework is designed to model activity, interaction, and communication between the parts of a game's internal economy. A game's economic system is dominated by the flow of resources. To model a game's internal economy, Machinations diagrams use several types of nodes that pull, push, gather, and distribute resources. Resource connections determine how resources move between elements, and state connections determine how the current distribution of resources modifies other elements in the diagram. Together, these elements form the essential core of Machinations diagrams. We'll start with the simplest ones.
Pools and Resource Connections
A pool is a location in the diagram where resources gather. Pools are represented as open circles, while the resources that are stored in a pool are represented as smaller circles that stack on them. If there are too many resources in a pool to show them as stacks, the tool displays a number instead.

Pools are used to model entities. For example, if you have a resource called money and an entity called the player's bank account, you would use a pool to model the bank account. Note, however, that pools cannot store fractional values, only integers.
The simplest kind of connection is a resource connection, and it transfers resources from one node to another. They're represented as solid arrows connecting the nodes of the diagram. Resource connections can transfer resources at different rates. A label beside the resource connection indicates how many resources can move along the connection in a single time step. If a resource connection has no label, its rate is considered to be 1.

You can specify random flow rates for resource connections by entering them in the Label box. Random rates are represented in different ways. If you simply enter D, a die symbol will appear beside the resource connection to indicate an unspecified random factor. The Machinations Tool can generate random numbers using the same dice notation that is commonly used in pen-and-paper role-playing games. In these games, D6 stands for a random number produced by a roll of one six-sided die, whereas D6+3 adds 3 to the same dice roll, and 2D6 adds the results of two six-sided dice and thus will produce a number between 2 and 12.
You can also create random values using percentages. A resource connection labeled 25 percent indicates that there is a 25 percent chance that one resource can flow along that connection at each time step. When using percentages, it is possible to use percentages higher than 100 percent. For example, 250 percent indicates a flow rate of at least two plus a 50 percent chance of one more.

Activation Modes
In each iteration, the nodes in a Machinations diagram may fire. When a node fires, it pushes or pulls resources along the connections that are connected to it. Whether a node fires depends on its activation mode. A node in a Machinations diagram can be in one of four different activation modes:
- A node can fire automatically, which means it simply fires every iteration. All automatic nodes fire simultaneously. Automatic nodes are marked with an asterisk (*).
- A node can be interactive, which means it represents a player action. In the Machinations tool, interactive nodes fire after the user clicks them. Interactive nodes have a double outline.
- A node can be a starting action, which means that it fires only once, before the first iteration. In the Machinations Tool, starting actions fire immediately after the user clicks the run button. They're marked with the letter S.
- A node can be passive, which means it can fire only in response to a trigger generated by another element (we discuss triggers later). Resources can be pulled out or pushed into it by other nodes, but it does not pull or push them itself unless triggered. Passive nodes have no special mark.

Pulling and Pushing Resources
When a pool fires, it will try to pull resources through any inputs connected to it. The number of resources it pulls is determined by the rate of the individual input resource connection. Alternatively, a pool can be set in push mode. In this mode, when the pool fires, it pushes resources along its output connections, at the flow rates of its output resource connection. A pool in push mode is marked with a P. A pool that has only outputs is always considered to be in push mode, in which case the P marker is omitted.

If a pool is trying to pull more resources than exist at the far end of its inputs, it will handle it in one of two ways:
- By default, a node pulls as many resources as it can, up to the flow rates of its inputs. If not enough resources are available, it still pulls those that are.
- Alternatively, a node can be set to pull all or no resources. In this mode, when not enough resources are available, none are pulled. Nodes that are in all or none pull mode are marked with an ampersand (& sign).
Hourglass Example
Using pools and resource connections, we can construct a simple hourglass. In this case, two pools are connected by a single resource connection. The top pool (A) is passive and contains five resources, while the bottom pool (B) is automatic and starts without any resources. After each iteration, B will pull one resource from A until all resources have moved from A to B. After that, there are no further changes to the state of this diagram.

|
personally pac man is simple enough to me to not need a complex economy chart, and the game becomes more complex looking at the chart then looking at the game, but the idea of a "state machine" gameplay chart seems nice.
looking at a game like settlers, this could be very usefull for planning the game out and finding particular strategies that might be over powered or issues that one could potentially face (although those negative cases typically stand out when testing the game)
i'll be sure to test it out and thank you for making it freely available.
I've just gone ahead and made a number of small games to try out loot and exploration and combat systems and even without graphics and an interface they became fun to "play" exceedingly quickly with the right balance.
I actually find it "fun" to just build up my SCV's and then rush the comp in Starcraft using just this tool.
Although the first diagrams looked intelligibly similar to a spreadsheet, I can see this being VERY effective in communicating concepts to external parties with higher abstraction, while still having the detail & power to go very deep as a working language inside a project.
I only wish resource counters went past 999 so I could import my Excel values directly! :(
Either ways, this a HUGE boon to any kind of economy modeling, and I'm sure I'll be tinkering with this lots. Thank you for sharing it!
This is not to say the article and the book lack originality: although Petri nets have been used for a while as a modelling tool, and adapted in various ways to suit different application domains, this is the first time I see their basic concepts applied to game design.
However, since depending on which (sub)set of Machinations symbols you use you end up falling in one of the several known classes of Petri nets, it's worth mentioning that these form the foundation of the diagrams presented in the article, mainly because there exist a vast number of mathematical results available for them. As a result, it is possible to leverage those existing results in order to design and check diagrams so as to guarantee certain properties, such as conservation of tokens (what you call resources), lack of deadlocks, etc...
It's totally possible that you provide this additional background in the book, but since I don't see it in the article, I thought I'd mention it.
Oh, yes, here's the obligatory Wikipedia link so as to clarify what I am talking about:
http://en.wikipedia.org/wiki/Petri_net
For my part, I've noticed there's also a lot of overlap with Environmental Systems modelling:
http://www.amazon.com/Dynamic-Modeling-Environmental-Systems/dp/03 87988807
Pic of what I'm talking about:
http://ars.sciencedirect.com/content/image/1-s2.0-S030438000700306 7-gr2.jpg
This, fortunately looks a hell of a lot easier to use than STELLA:
http://www.iseesystems.com/softwares/education/stellasoftware.aspx
To explain myself better, consider the following situation: as a game designer, you model using a Machinations diagram a certain game economy. Now, a question you might want to ask yourself is whether - due, for instance, to the players' actions - you end up with so much cash in-game that it ends up being essentially worthless. You might try to come up with a answer based on the good old "gut feeling", or by running a bunch of simulations assuming different "usage patterns"; this is not going to guarantee, however, that the economy will behave the way you want in practice.
If your economy happens to be equivalent to a known class of Petri nets, your question is equivalent to ask whether the net is bounded. In this scenario, chances are that mathematicians have developed some boundedness criterion to prove that cash in the game economy will not explode to infinity, no matter what. You could have worked out such a criterion for yourself (depending on your prowess in mathematics), but by being aware of this equivalence, you are not forced to re-invent the wheel.
The example above is the first thing that came to mind, so maybe there are better case studies, but at least I hope it made my message clear.
EDIT: reply fail, should have appeared indented above :P
Joris's work took inspiration from Stephane Bura's article on Petri nets as a means of modeling games, "A game grammar" http://www.stephanebura.com/diagrams/
Stephane, in turn was reacting to Raph Koster's 2005 talk "A Grammar of Gameplay" http://theoryoffun.com/grammar/gdc2005.htm
This is very much the birth of a science of game design...we are seeing some of the mathematical and structural bones of our folk systems laid bare. While there will always be room for pop culture hand-wringing (like we see in the current front page David Cage article), Dormans, Bura and Koster are exploring a fundamental vein of thought that is ultimately likely to have a lasting impact on how we design games.
What is wonderful about Machinations is that it is moving out of the theoretical realm and into the realm of practice. You can use these diagram to understand dynamics and emergence of your current system and they'll give you insights that were otherwise extremely difficult to intuit. I regularly use some of the patterns in the book to transform games rather radically. By knowing the underlying structure of a working game, it starts being far less risky to manipulate the surface in interesting ways.
take care,
Danc.
Edit: Which is meant, in no way, to diminish how uniquely awesome Machinations is.
Greetings
Kelvin
Joris
Thanks mate!
Now make an iPad version :)