The idea of dividing a game into "elementary pieces" is also the backbone of more complex models, such as Raph Koster's "ludemes." Inspired by Koster, Stéphane Bura introduced a system to represent game structures with diagrams. He used the Petri net modeling language as a base for his own model.
Actually, he "hijacked" all the elements of this language to make them relevant to game design. Thus, Petri net's "Tokens" are now used to represent resources, "Places" are the games elements, and "Transitions" define all the actions of players.
Although Bura's model should be interesting for people acquainted with Petri net, we think that Joris Dormans' model will be easier to understand for most software engineers. Indeed, this model is based on UML.
It relies on "collaboration diagrams" to represent interactions between each game element. Dormans drafted a first model [pdf] that strictly follows the UML standards. It evolved to an UML-inspired custom way of diagramming game structures. Called "Machinations", this model is well suited to design games featuring an internal economy, i.e. games where resources are involved during play.
The first step is to create "resource pools" that represent game elements. Then, pools can interact with each others according to four principal ways: to produce resources, to drain resources, to convert resources, or to exchange them. With the help of Ernest Adams, Dormans recently wrote a full book about game design based on this model, an extract of which is available on Gamasutra.
List of the diagram elements used in Machinations by Dormans.
More than a simple theoretical model, Dormans also built a software tool to draw such diagrams. When a diagram is drawn, the game designer can test it and see how the resources are flowing during a simulated game play. Although this tool does not generate any code, it allows game designers to formalize their designs and to perform some kind of "automated beta-testing." Resulting diagrams can then be handed to the development team in order to create digital prototypes.
A Game Alchemy
Going further with the diagram idea, Daniel Cook proposes a tool that can represent not only the structure of the game, but also the player-game interactions. To build his model, he defines the player as "[an] entity that is driven, consciously or subconsciously, to learn new skills high in perceived value. They gain pleasure from successfully acquiring skills." This definition is close to Koster's view on "fun," as expressed in his book A Theory of Fun: "Fun, as I define it, is the feedback the brain gives us when we are absorbing new patterns for learning purposes."
Regarding the structure of the game, Cook divides it into a set of "mechanics". Each of these "mechanics" is associated to a "skill" that players have to learn (e.g. Mario earns an extra life when he collects 100 coins). According to Cook, "skills" are simply chunks of information that a player must discover to understand how to win the game. Several "mechanics" are likely to be involved in the learning of a single "skill." These "mechanics" are composed of four steps, as mentioned in the figure below:
Detailed view of a mechanic from Game Alchemy, by Cook.
Cook uses "mechanics" as elementary pieces to represent the whole player/game structure in a diagrammed form. Each mechanic is a kind of "atom" that can be connected with other mechanics to create a "non-linear skill learning chain." Thus, this tool is able to generate a formalized structure showing both the connections between the game rules and between the player and the game.
It is a convenient way to communicate a game design to all the departments of a team. For example, developers can use it to support a "top-down" approach to build the software architecture of the video game. They will be able to build a first level architecture with an overview of all the mechanics and then to refine the inner architecture of each mechanics separately. By providing information on the player-related skills, this tool may also become a reference guide during beta-tests, in order to see what "skills" players successfully learn (or not) from the current iteration of the game.
Excerpt from a representation of Angry Birds using Cook's Game Alchemy.