Author: by Damien Djaouti

Can a tool for modeling game design make it easier for designers to work with engineers? Many different tools and frameworks have been proposed, and researcher Damien Djaouti explores them for practicality and adaptability.

This article presents a selection of "formal game design tools" that may be able to bring game design and software engineering closer. Nowadays, game designers can rely on a set of theoretical tools to create video games. These tools are first intended to facilitate the design phase. However, some of them have a strong potential to communicate designers' ideas to the rest of the team, especially to developers. We will study four examples of such tools, before discussing how they may ease the communication between design and engineering departments in video game studios.  

Introduction

Traditionally, to present his work to the rest of the team, a game designer writes a Game Design Document that details every aspect of the game. However, as revealed in a 2010 study, game developers in the industry report that an extremely comprehensive document is useless if team members no longer have the time to read it.

Instead, they are experimenting new methods tailored for the communication needs between disciplines. Meanwhile, the study of game design has produced an abundance of literature since the beginning of the 2000s.

Among these books and research articles, some game designers are proposing tools that intend to formalize game design. Could some of these "formal game design tools" be able to help game designers to communicate their ideas to game developers?

To try to answer this question, we gathered a corpus of books and articles related to game design, ranging from 1999-2012. Inside these books, we identified several formal models related to the many aspects of game design. Some models are trying to formalize the game structure; others are trying to formalize players' behaviors, and a few tools are even trying to model the whole player-game relation.

Through this article, we will highlight four models that enable designers to model a game structure. We will first present these tools before discussing how they can be used as internal communication tools by development studios.

A Token-Based Model

The core idea of this model is to build a game structure with elementary pieces called "tokens." As explained by Andrew Rollings and David Morris in their book Game Architecture and Design, tokens are basic elements that compose a game. Each token can contain one or several other tokens. Hence, tokens can be used to build a hierarchical structure of all the game elements.

For instance, Angry Birds (Rovio Mobile, 2009) can be divided into four tokens: "Birds", "Pigs", "Obstacles" and "Score Counter." "Score Counter" and "Birds" are part of a larger "Player" token. "Birds", "Pigs", and "Obstacles" can be divided into several sub-tokens: "Red Bird", "Blue Bird", "Black Bird", "Wood Obstacle", "Ice Obstacle"... Using this set of tokens, one can easily create an interaction matrix to model all the "token-token interactions" that can occur during a game.

Extract of a token hierarchy and of an interaction matrix for Angry Birds.

As stated by the two authors, this model is well suited to simple games, but can quickly become harder to use with more elaborate games. Therefore, they introduce a variant of the token model to handle more complex game structures. This variant keeps the aforementioned idea, but introduces "variable state tokens."

Each "token" is now a "Finite State Machine." It will have different states during the course of the game. They propose a diagrammed approach to represent state variations for each token. An example is given below for the "Black Bird" token from Angry Birds. By using both the interaction matrix and the state diagram, game designers should be able to formalize the structure of complete videogames. As interaction matrixes and state diagrams are part of software engineering culture, this tool should help designers to communicate their creations to programmers.

A state machine-diagram for the "Black Bird" token.

Diagram-Based Machinations

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.

Game Layers

Another approach to formalize game design is to divide it into a set of 'slices' to focus the designer's attention when he creates a game.

These slices are related to anything involved with videogames, from inner game structure to player experience. Several examples of such models exist.

The simplest ones are using three slices, such as the MDA model [pdf] and Katie Salen & Eric Zimmerman's Primary Schemas. Aki Jävrinen's "game elements" are an evolution of the MDA model aiming to provide more details through the use of nine different slices of a game. Such models may also be heavily detailed, as shown by Jesse Schell's "lenses" his book, The Art of Game Design, provides a hundred slices.

Among these "slice-based" tools, one of the most suited for architecture seems to be proposed by Paolo Tajè. His model divides the game-player relationship into six "layers." By focusing his attention on a single layer at a time, a game designer should be able to create or to modify a game design more easily. These layers are ordered in a precise manner from the "game" to the "player":

A representation of Angry Birds using Tajè's Game Layers.

This model provides an overview of the different elements in a game to help designers to spot potential design flaws. By summarizing and categorizing all the game features in a single document, this tool is handy to quickly communicate the game design to other departments. First, the Token, Prop, Dyn, Goal, and Meta layers can be used by software engineers as a reference to build a digital prototype. Then, the Psycho layer will allow checking whether players feel the expected emotions during beta tests.

Discussion

All these architectural tools serve a simple purpose: presenting a game structure in a formalized way. Although each model features various levels of details and complexity, the four models presented in this article could be very useful when a game designer needs to explain her creation to software engineers.

As discussed in the introduction of this article, some game developers in the industry are seeking for new tools to complement or replace the traditional Game Design Document. I think that the models presented in this article could be a convenient way for the design department of a game studio to communicate with the development one. By using such formal models, the game designer shapes his own work in a way the software engineers are used to.

Although some models are not based on previously existing standards (such as UML or Petri net), they all seem deeply influenced by the process of abstraction tied to programming languages, and more specifically by the "object-oriented programming paradigm. Indeed, all these tools divide a game into distinct and autonomous elements, and explicitly state how these elements interact with each other. The table below summarizes my observations regarding the potential uses of these models.

Comparison between the four "formal game design tools":

As suggested by this table, the four models can be useful for a single game project. For example, to create a game like FarmVille, a game designer might start by sketching all the game elements into "Tokens" (e.g. crops, animals, land units...). He can then define the basic interactions between tokens through an interaction matrix (e.g. crops can be planted on land units...).

However, the quite complex economical system of such a game would be easier to model with Machinations (e.g. proportion of resources produced by each type of crop for a given amount of time…). The documents produced thanks to these two models should help the Software Engineers to build running prototypes of the game. The Alchemy and Layers models will then allow the designer to formalize guidelines for the beta test. Whether to use Alchemy or Layers depends on the inner complexity of the game.

Another approach consists in relying on a single model. For instance, Alchemy can produce an exhaustive document that may be used to communicate with both engineering and testing departments. Indeed, this tool allows detailing each rule and element of the game through its "mechanics" system. It should guide the engineers. These "mechanics" can then be linked to an "expected player experience" composed by the acquisition of "skills." This information can be used as a reference by beta testers.

Conclusion

As of today, none of the tools presented in this article seems to be widely used by game development studios. While some professionals might find them impractical, we think that this situation is largely due to two factors: ignorance of the existence of such models, and difficulty to fit them in the game creation process.

By presenting a selection of four formal models related to game design, I hope to help people being aware of the existence of such theoretical tools. As for the way to fit them in the game creation process, we think that they can be useful in two cases. First, they may help a designer to create a game design by guiding him with a "defined framework."

Additionally, these tools are helpful to build the software architecture of video games. They make a game designer present his work in a form similar to the object-oriented paradigm. It may help game designers to communicate with software engineers to build solid architecture. By modeling the expected player reactions, some of these tools may even help designers to give clear guidelines to the testing department. So, formal game design tools may be a solution for game studios wishing to experiment new communicational tools to replace the traditional Game Design Document.

However, for now these tools remain theoretical and do not allow direct code generation. A further step to formalize game design would be to create prototyping software based on these models. Indeed, with programs like IBM's Rational Rose, software engineers can automatically generate code by drawing UML diagrams. So, why don't game designers have access to similar tools for videogames?

We already observe that some amateur game creation tools, such as GameMaker and The Games Factory 2 are sometimes used in the industry to build prototypes. They share conceptual similarities with the tools presented in this paper.

For instance, to ease the creation of the game rules, The Games Factory 2 features a giant table looking like the "token interaction matrix" introduced by Rollings and Morris. But, as of today, no such prototyping software is truly based on an existing theoretical model. Hence, some researchers are conducting experiments to build new software tools based on solid theoretical models.

I already mentioned the software tool based on Machinations. It can perform some automated tests to check for potential design flaws, but it does not allow designers to create playable prototypes yet. Another example is Ludocore [pdf], which is a tool to build playable games prototypes by using the event calculus logical language. Thanks to its strong theoretical foundations, it generates useful "gameplay traces." The tool logs the actions of players to help designers who use this tool to improve the rules of their games.

I, along with a team of researchers, am also doing some experiments in this field. Our "Gam.B.A.S." tool is based on a theoretical model that divides a game structure into elementary pieces called "GamePlay bricks." We are currently working on an improved version of the theoretical model to build a better software tool.

The design of such tools is an experimental task that requires a high investment in research & development. Unlike graphics or physics-related research, the creation of new professional design tools is hard to convert into a unique selling point feature for a commercial video game. Therefore, this field appears to be an opportunity for university laboratories to get involved in videogames-related research. A few academic projects already exist, but we hope that many others researchers and industry professionals will be interested in exploring the field of "formal game design tools."