Game Development Reference
In-Depth Information
Machinations
In the previous chapter, we showed how a game's internal economy is one impor-
tant aspect of its mechanics. We used diagrams to visualize economic structures
and their effects. In this chapter, we introduce the Machinations framework, or
visual language, to formalize this perspective on game mechanics. Machinations
was devised by Joris Dormans to help designers and students of game design create,
document, simulate, and test the internal economy of a game. At the core of this
framework are Machinations diagrams, a way of representing the internal economy
of a game visually. The advantage of Machinations diagrams is that they have a
clearly defined syntax. This lets you use Machinations diagrams to record and com-
municate designs in a clear and consistent way.
We will be using Machinations diagrams throughout this topic, so it is important
that you learn how to read them. This chapter will take you through most of the
elements that make up a Machinations diagram. However, a word of caution: The
Machinations framework is a lot to take in at once. The framework comprises many
interrelated concepts that are best understood together. This means there is no real
natural starting point to explain all these concepts. We have tried to introduce the
elements of a Machinations diagram in a logical order, but don't be surprised if you
find yourself referring to earlier concepts on occasion.
Machinations is more than just a visual language for creating diagrams, however.
Dormans has built an online tool for drawing the diagrams and simulating them
in real time. With it, you can construct and save Machinations diagrams easily, and
you can also study the behavior of your internal economy. You can find the tool at
Appendix C (which you can find online at
www.peachpit.com/gamemechanics
)
includes
a tutorial on how to use the Machinations Tool. You can find a quick reference
guide to the most important elements of Machinations diagrams in Appendix A.
Game mechanics and their structural features are not immediately visible in most
games. Some mechanics might be apparent to the player, but many are hidden
within the game code. We need a way to describe and discuss them.
Unfortunately, the models that are sometimes used to represent game mechanics,
such as program code, finite state diagrams, or Petri nets, are complex and not
really accessible for designers. Moreover, they are ill-suited to represent games at a
79
