Machinations: A New Way to Design Game Mechanics
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 reviewcopies 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.
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.
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.
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:
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:
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.
The state of a Machinations diagram refers to the current distribution of resources among its nodes. When the resources move from one place to another, the state changes. In the Machinations framework, you can use state changes to modify the flow rates of resource connections. In addition, you can trigger nodes to fire, or activate or deactivate them, in response to changes in resource distribution.
To make this possible, Machinations offers a second class of connections called state connections. State connections indicate how changes to the current state of a node (the number of resources in it) affect something else in the diagram.
State connections are shown as dotted arrows, leading from the controlling node and going to a target, which can be either a node, a resource connection, or, rarely, another state connection. Labels on the state connection indicate how it changes the target.
There are four types of state connections that are characterized by the type of elements they connect and their labels. The four types are label modifiers, node modifiers, triggers, and activators. In this condensed version of the chapter, we'll concentrate on two: label modifiers and activators.
Remember that a label on a resource connection determines how many resources can move through that connection in a given time step. Label modifiers connect an origin node to a target label of a resource connection (or even another state connection).
A label modifier indicates how state changes in the origin node modify the current value of the target label at the current time step as indicated by the state connection's own label. The new value takes effect in the next time step. The amount of the change in the origin node is multiplied by the label multiplier's own label.
So, if the label modifier says +3 and the origin node increases by 2, then the target label will increase by 6 in the next time step (it will add 3 twice, once for each change in the origin node). However, if the label modifier says +3 and the origin node decreases by 2, then the target label will decrease by 6.
The label of a label modifier always starts with a plus or minus symbol. For example, in the figure above, every resource added to pool A adds 2 to the value of the resource flow between pools B and C. Thus, the first time B is activated, one resource flows to A and three resources flow to C. The second time, one resource still flows to A, but now five resources flow to C.
Activators connect two nodes. They activate or inhibit their target node based on the state of their origin node and a specific condition. The activator's label specifies this condition. Conditions are written as an arithmetic expression (for example, ==0, <3, >=4, or !=2) or a range of values (for example, 3-6). If the state of the origin node meets this condition, then the target node is activated (it can fire). When the condition is not met, the target node is inhibited (it cannot fire).
Advanced Node Types
Pools are not the only possible nodes in a Machinations diagram. In this section, we will describe several more types of nodes that you can use, including special nodes for the four economic functions (sources, drains, converters, and traders) that I originally described in Fundamentals of Game Design.
In contrast to a pool, a gate does not collect resources. Instead, it immediately redistributes them. Gates are represented as diamond shapes that often have multiple outputs. Instead of a flow rate, each output is labeled with a probability or a condition. The first type of outputs are referred to as probable outputs while the others are referred to as conditional outputs. All outputs of a single gate must be of the same type.
Probabilities can be represented as percentages (for example, 20 percent) or weights indicated by single numbers (for example, 1 or 3). In the first case, a resource flowing into a gate will have a probability equal to the percentage indicated by each output. The sum of these probabilities should not add up to more than 100 percent. If the total is less than 100 percent, there is a chance that the resource will not be sent along any output and be destroyed instead.
In the case of weights, the chance that a resource will flow through a particular output is equal to the weight of that output divided by the sum of the weights of all outputs of the gate. In other words, if there are two outputs, one with a weight of 1 and the other with a weight of 3, the chance that a resource will flow out the first one is 1 in 4, and the chance that it will flow out the second one is 3 in 4.
An output is conditional when it is labeled with a condition (such as >3 or ==0 or 3-5). In this case, all conditions are checked every time a resource arrives at the gate, and one resource is sent along every output whose condition is met. The conditions might overlap; this can lead to duplication of resources or, when no condition is met, to the destruction of the resource.
Gates have one of two distribution modes: deterministic distribution and random distribution. Adeterministic gate will distribute resources evenly according to the distribution probabilities indicated by percentages or weights if it has probable outputs. When it has conditional outputs, it will count the number of resources that have passed through it every time step and will use that number to check the conditions of its outputs. (It can be convenient to think of a deterministic gate with conditional outputs as a counting gate.) Note that the count starts over each time step, so if one resource arrives, a deterministic gate has no special symbol and is represented as a small open diamond.
A random gate generates a random value to determine where it will distribute incoming resources . When it has probable outputs, it will generate a suitable number (either a value between 0 percent and 100 percent or a number below the total weights of the outputs). When its outputs are conditional, it will produce a value between 1 and 6 to check against the conditions, just as if the diagram rolled a normal six-sided die. Random gates are marked with a die symbol.
Gates are very powerful and include a number of other features that we don't have room to discuss here. Below are a few types of gates.
Sources are nodes that create resources. They are represented as a triangle pointing upward. Like any other node in a Machinations diagram, sources can be automatic (the default), interactive, passive, or it can activate once before a diagram starts. An example of an automatic source is the steady regeneration of the protective shields of the player's star fighter in Star Wars: X-Wing Alliance. The action to build armies in Risk would be modeled as an interactive source of armies, and passing Go in Monopoly would be a passive source of money that is triggered by a game event. The rate at which a source produces resources is a fundamental property of a source and is indicated by the flow rates of its outputs.
Drains are nodes that consume resources; a resource that goes into a drain disappears permanently. The Machinations framework includes a special drain node represented as a triangle pointing downward. The rate of a drain is determined by the flow rate of its input resource connection. Some drains consume resources at a steady rate, while others consume resources at random rates or intervals. You can also make a drain consume everything its input resource connection is attached to by labeling the resource connection with all.
Converters convert one resource into another. They are represented as a triangle pointing to the right with a vertical line through it. Converters are designed to model things like factories that turn raw materials into finished products. A windmill, for example, turns wheat into flour. Converters act exactly as a drain that triggers a source, consuming one resource to produce another. As with sources and drains, converters can have different types of rates to consume and produce resources as specified by their inputs and outputs. For example, a converter representing a sawmill might turn one tree into 50 boards of lumber.
Traders are nodes that cause resources to change ownership when fired: Two players could use a trader to exchange resources. Machinations diagrams represent a trader as a vertical line over two triangles that point left and right. Use traders when a given number of resources of one type is exchanged for (not converted into) a given number of another type. This is ideal for any situation that resembles shopping: the merchant receives money, and the customer receives goods in a stated proportion (the price). If either the merchant or the customer does not have the necessary resources, the trade cannot take place. Fallout 3, in which all traders' supplies are limited, is a good example.
Putting It Together
That's the end of the excerpt from chapter 5 of Game Mechanics, but I now want to show you a few things you can make with Machinations. Here's a diagram that shows all of the elements I introduced earlier.
Going from left to right, we have an automatic source (the * next to the source designates it as automatic), which initially generates 2 resources every time step, and sends them to a passive pool. The pool is the origin of a state connection (the dotted arrow) that reduced the label on its input resource connection by 0.1 for each arriving resource. After 20 iterations, the label will be down to zero and the source won't send any more.
The pool is connected to an interactive converter that takes three resources in and converts them to five whenever it is clicked. The five output resources then go into a random gate that sends 25 percent of them back to the pool, and 75 percent to a drain, where they disappear. The trader off to the right is not yet hooked up to anything.
A Couple of Examples
Machinations lets you model and simulate dynamic systems at arbitrary levels of abstraction. Here, for example, is the basic positive feedback loop of Monopoly:
Income arrives at a low random rate, initially between 1 and 6 units every time step. (The default Machinations random value generator is one six-sided die, although this value is settable.) The money goes into a passive pool.
At any point, the player can click on the Buy Property converter, which turns a single Money resource into a Property resource that goes into the Property pool. The state change in the Property pool is transmitted back to the label on the Income source's output connection, increasing the amount of money raised each turn.
This is the classic upgrade process for everything from Monopoly to StarCraft: investing in production facilities consumes stored resources but increases production of new ones.
Here's a simple self-regulating mechanism that we're all familiar with.
The state connection from the cistern to the water supply is not a label modifier but an activator. It permits the water supply to provide water so long as the amount in the cistern is below 20 units. Then the cistern gets full, the water supply shuts off (in the Machinations tool, it turns grey). An interactive drain drains the entire contents of the cistern immediately whenever it is clicked. The word all is a special label designating an unlimited flow rate for a resource connection.
These are just trivial examples to give you an idea of the kinds of feedback loops and control systems that are available in Machinations. The book includes a whole library of design patterns - - different kinds of engines and friction systems, escalation patterns, and miscellaneous patterns for things like technology trees.
I've described fewer than a quarter of Machinations' many powerful features in this article. You can build all sorts of things with it. Chapter 6 of Game Mechanics includes examples from side-scrolling action games, shooters, RPGs, racing games, RTS games, and more. It's not designed for building complete games, but it does let you create and test parts of a game economy and elaborate on it. You can also execute multiple runs at high speed, collect data and display or export it, and create artificial players to try out different strategies to see if any of them are dominant.
The remainder of Chapter 5 takes you step by step through the stages of modeling the various features ofPac-Man, from the ghosts to the fruit to the super dots. It can't reproduce the layout of the maze itself, of course, but it enables you to see the various mechanisms and how they interact with each other. Here's the final result (be aware, it includes features I haven't described here):
The Machinations Tool, along with numerous sample diagrams, is available free of charge at Joris Dormans's web site: http://www.jorisdormans.nl/machinations.