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.
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.
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.