Gamasutra: The Art & Business of Making Gamesspacer
The Designer's Notebook: Machinations, A New Way to Design Game Mechanics
View All     RSS
October 25, 2014
arrowPress Releases
October 25, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

The Designer's Notebook: Machinations, A New Way to Design Game Mechanics

August 16, 2012 Article Start Page 1 of 3 Next

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

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.

Article Start Page 1 of 3 Next

Related Jobs

Digital Extremes
Digital Extremes — LONDON, Ontario, Canada

University of Central Florida, School of Visual Arts and Design
University of Central Florida, School of Visual Arts and Design — Orlando, Florida, United States

Assistant Professor in Digital Media (Game Design)
The College of New Jersey
The College of New Jersey — Ewing, New Jersey, United States

Assistant Professor - Interactive Multi Media - Tenure Track
Bohemia Interactive Simulations
Bohemia Interactive Simulations — Prague, Czech Republic

Game Designer


Lars Doucet
profile image
Nifty! This would have been super helpful for modeling energy economies in games like Super Energy Apocalypse.

Chris McLeod
profile image
I think may just have to pick up a copy. Easy ways to simulate complicated systems is just what we need!

Zaphod Plumbo
profile image
Sadly, it's a Flash applet.

Ernest Adams
profile image
That's what makes it widely available, except for those poor souls whose machines have been crippled by Steve Jobs.

Michael Joseph
profile image
This is clear confirmation that Steve Jobs faked his death! Steve joins the ranks of Elvis, Tupac and Jesus!

Bill Miller
profile image
Hey, you forgot Jim Morrison with Steve Jobs, Elvis, Tupac and Jesus!

Freek Hoekstra
profile image
cool idea, especially for complex games!
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.

Samuel Batista
profile image
This is absolutely fascinating! As a young developer building my skills I've mostly been concerned with programming and leaning how to implement game systems. This article makes me want to explore game mechanics and feedback loops in more detail, so I can arrive at a formula I am pleased with before writing a lot of the game code. This has the potential to fundamentally alter how I approach game design, from a "make lots of games till you stumble onto a combination of fun mechanics that work together", to "prototype many game mechanics designs on a simulator until you find a set of mechanics that leads to interesting and unexpected results, then make a game out of it".

Mike Blackney
profile image
Thank you so much for this. Great article, Ernest, and great tool, Joris!

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.

Julian Gosiengfiao
profile image
Nifty indeed!

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!

Luke Shorts
profile image
While the article is undoubtedly interesting, I think it would be worth mentioning that the Machinations diagrams are essentially a class of Petri Nets, wrapped in a formalism that makes them more palatable to game designers.

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:

Lars Doucet
profile image
Neat background info!

For my part, I've noticed there's also a lot of overlap with Environmental Systems modelling:

Pic of what I'm talking about:

This, fortunately looks a hell of a lot easier to use than STELLA:

Ernest Adams
profile image
Joris Dorman's PhD thesis "Engineering Emergence," which forms the skeleton of Game Mechanics, does discuss Petri nets. (He isn't pretending to have invented something new without having done any research.) But we pulled that discussion out of the book because we had space constraints, and because they don't really do we wanted for a undergraduate textbook.

Saul Gonzalez
profile image
There's a problem with the commenting system. You need to remove the space in Lars' link before it'll work.

Joris Dormans
profile image
Actually there are a few subtle differences between Petri nets and Machinations. Petri nets use places and transitions that would function much like pools and gates in Machinations. However, Petri-nets doe not have anything like the state connections, I am not sure if you can do something like changing the flow rate of a source based on the number of resources on a pool in a Petri net. And I do not want to think what it does to the math. But you are right in observing that there is a similarity between the two and that much of the knowledge and maths of Petri nets might actually transfer to Machinations. However, I would be careful to apply it with too much liberty.

Luke Shorts
profile image
Well, the comment was not meant to allege a lack of research in the related fields. Furthermore, I haven't used your diagrams to model any game design problem, but I can see them being at least more descriptive than standard Petri net language. Still, since I have some experience in working with modelling tools and simulators, I believe that - also from a user's perspective - awareness of, let's say "neighbouring" modelling paradigms is very important.

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

Daniel Cook
profile image
For some of the history behind Machinations, I recommend you look into the game grammar research that has been silently bubbly in the background for several years. This is an unsung braintrust seeking to revolutionize game design. If they were physicists, their names would be Faraday, Curie and Bohrs

Joris's work took inspiration from Stephane Bura's article on Petri nets as a means of modeling games, "A game grammar"

Stephane, in turn was reacting to Raph Koster's 2005 talk "A Grammar of Gameplay"

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,

Isaac Barry
profile image
Jay Forrester's System Dynamics, predates everything you've mentioned by thirty years and has several prominent examples of software implementations (Vensim, STELLA, etc.). An older version of Machinations is even linked on System Dynamics sites. :)

Edit: Which is meant, in no way, to diminish how uniquely awesome Machinations is.

Seiji Tanaka
profile image
Machinations is making me realize how much time I've wasted in the past iterating on my systems. Being rather new to the scientific side of game design, I wasn't sure if games I'm making can really benefit from an economy simulator. Then I was thoroughly humbled after modeling one of my games in Machinations that a game can't exist without some form of economy. Thank you for this write-up and I will definitely be investing in the book.

Ernest Adams
profile image
You sound like a native speaker of English, but just in case you're not, Game Mechanics is due to be translated into Japanese this fall, and the Japanese version will be available in the spring.

Kelvin Autenrieth
profile image
Great Tool, looking forward to use it. It seems useful for some higher educational Game Design Workshops I am working within. But I am still struggling a bit with some functions. Is there a forum or any other space to discuss it where I could ask some specific questions?


Joe Garfield
profile image
+1 for link to a forum or mailing list. I'd like to model my game (a tower offense styled game) at the top-most level where players make decisions but I haven't been able to find a decent way to model distance between groups of combatants + multiple waves of combatants. I'm sure somebody has figured this out already so I'd like to get in on that somehow (hence, forums).

Joris Dormans
profile image
I've just created a forum. You can find it at It's kinda empty for now. Don't expect to much too soon. Machinations is just starting to attract the number of users that might support a forum.

Heather Stark
profile image
I know I don't look like Marlon Brando in an undershirt - or in any other piece of clothing - but this makes me think "stella!!!!!!" (a popular system dynamics modelling tool), except fitter as it's got an ontology that's tuned for the application domain. Nice!!!!

Rafael Kuhnen
profile image
Really cool stuff.

Thanks mate!

Tadhg Kelly
profile image
Super fascinating stuff Ernest / Joris.

Now make an iPad version :)

Ronildson Palermo
profile image
Great tool, I'll need some time to get used to it though! =7

Rob Lockhart
profile image
You should give a workshop at GDC. I would attend the hell out of that.

Joris Dormans
profile image
Actually we already sent in a proposal for a lecture, and are preparing one for a workshop.