Gamasutra: The Art & Business of Making Gamesspacer
Game Design Tools for Collaboration
View All     RSS
October 31, 2014
arrowPress Releases
October 31, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Game Design Tools for Collaboration

March 5, 2013 Article Start Page 1 of 3 Next

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.

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.

Article Start Page 1 of 3 Next

Related Jobs

The Workshop
The Workshop — Marina del Rey, California, United States

InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Mobile Developer C++ (m/f)
The College of New Jersey
The College of New Jersey — Ewing, New Jersey, United States

Assistant Professor - Interactive Multi Media - Tenure Track
Next Games
Next Games — Helsinki, Finland

Senior Level Designer


Xantomen Fernandez
profile image
An interesting reading, thank you. What is your opinion on the software "articy:draft", in relation with this models?

Damien Djaouti
profile image
I haven't tried articy:draft yet, so thanks for the tip. I've just looked at its website, and it looks like a very interesting tool. But, if I understand the description well, it doesn't seem to be able to produce working prototype, it solely designed to help you craft an interactive "GDD". Anyway, it still looks like an improvement over traditional GDD, and seems to be some kind of software application of the theoretical tools mentioned in the article.

So, have you tried articy:draft yourself? If yes, what do you think of it ?

Amit Ginni Patpatia
profile image
Articy:draft is pretty handy actually, I give a taste of it personally in this video, if you want a quick idea besides their "tutorial" videos which I don't really find helpful.

Damien Djaouti
profile image
Thanks for your video, it's very interesting. In a way, Articy:draft diagrams feel a bit like the ones proposed by Cook's Alchemy. Now, I wish someone would create an "Articy:craft" tool that allows to generate some playable prototypes using the diagrams produced in Articy:draft!

Tony Ventrice
profile image
The paradox of game systems modeling seems to be: the broader the scope, the more confusing the output. The finite state diagram under the 'Tokens' section reads the easiest and seem much more universally accessible than what follows.
The exception is the Angry Birds example using Cookís Game Alchemy and this illustrates perhaps what all of these models should be striving for first and foremost: the elegance of a focused, readable, repeatable format.
If a system is confusing, perhaps itís trying to cover too much ground. As the article states, games are deeply layered, each layer is its own system and deserving of itís own model. Ultimately, the task of bringing all those layers together into a meaningful whole is almost impossible to reduce to diagram form; it's that sought-but-never-tamed skill that make talented designers special.

Damien Djaouti
profile image
I couldn't agree more. But, as a growing number of "Game Design" courses are proposed all over the world, shouldn't we try to find a way to teach future game designer how to learn the way games system can be "layered", and how to deal with these layers to produce a meaningful (or at least functional) game?

Alexandre Laine
profile image
Very interesting paper. Thanks :)

I've been using the Token and Alchemy models for as long as I've been designing games. I didn't really look for a name and "official" rules for these, I just used my programmer knowledge to do my best in communicating with the programmers. These is just an extension of UML and all the questions you have to ask yourself when making the analysis of the clients need for a software : when the user hits this button, what shoud come up and what 'mechanics' are running in the background to display the correct result. However I didn't know about the Layer model and it can be interesting, although I think it can easily be integrated in the other 2 I already use.

Sometimes I think that trying to find a model that works for every existing game types and for the ones yet to be invented is impossible. Trying to create a simple model (meaning with only a few elements to use) will limit it to simple games, and trying to make an exhaustive model will make it impossible to use for even large games (ie the Layer model which can contain up to 100 in Jesse Schell's book). So maybe defining "gameplay bricks / pre-existing mechanic blocks" for different game types could be a good way to go, especially as some genres are well established and mastered already. Then providing a set of sementic tools to use to create additional, inovative features that will fit in the model's rules can make it open for additions and let it evolve while the game design practices evolve.

Another point that I want to raise regarding this article titled "Game Design Tools for Collaboration" is that you don't really talk about communicating with artists, writters, sound designers and other departments. Sounds are parts of a feedback, so are some graphics and when you think about it, they have to be plugged together by the programmers. Focusing on the core mechanics is good and necessary to set the ground rules of your game, but I like my documentation to be useful for the entire team, regardless of their department. Unless we add these to the model, there is a huge amount of work left to have a real overall view of the game and the effects it will have on the player. Sometimes the fun doesn't come from learning something, but enjoying the visual and sound feedbacks the player gets from executing a 'meaningless' action.
Moreover, if we can write a document exhaustive enough to contain informations useful for the entire team, and clear enough to be used by all the departments, it's a win-win situation and a real gain of time that can be spent on tweaking, testing and improving the game.

Hope I made myself understandable, I got a little bit carried away from my initial thoughts :D

Damien Djaouti
profile image
Thanks for your very interesting comment. Actually, a game design tool project I've been working on quite a while ago was based on the "gameplay bricks" idea. My goal was to identify core "gameplay" components, then allow designers to first map them roughly to define a core gameplay, and finally allow them to fine-tune the various parameters of each "brick" to create an unique game.

This idea have yet to result in a fully functional software design tool, but if you are interested in how I see the "gameplay brick" idea, you can find out more in a 2006 article published here:

Regarding your comment on the "collaborative" side of the tools, you are right, my main goal with the tools presented here was for communication between game designers and game developers. I haven't been looking at communication needs for others departments, but your idea of "one document to communicate it all" is very interesting. Do you have some example of such document that you could share?

Joris Dormans
profile image
Nice article, Damien. And thanks for including Machinations to your list. One minor observation, although Machinations once started based on UML long ago, its current form is much closer to Petri-nets. Suggesting a close relation between Machinations and UML might set people who are familiar with UML on the wrong foot.

Damien Djaouti
profile image
Yes, sorry about that Doris. I think it's because I've been following your work on this topic since your first articles, and as a computer scientist I was first more appealed by the way you built your own framework from UML. And even if it's now something really different, I think people familiar with UML will still have some ease to learn your tool compared to people who aren't (but again, this is just a subjective opinion based on the reaction of colleagues in the computer science lab to whom I showed your tool).

And by-the-way, I really enjoyed your book and your PhD thesis. It was very inspiring to mine.

Panupak Methachaiyasit
profile image
Thanks for writing this article Damien, this is just what I need. I am a game programmer who also has a responsibility to design a game mechanic. Even though our gameplay has a potential but it is still lacking something that can make it great. After reading this article, I think I finally have a way to identify the problems.

Damien Djaouti
profile image
Thanks, I'm glad the article was helpful to you. Do not hesitate to share here the experience of solving gameplay problems in your game with such tools!

Paolo Taje'
profile image
Thanks for citing my work, Damien.

I just want to show you all a "spin-off" of that article, a Layer-based deck of cards useful for prototyping and brainstorming.
Here's the link:

It's a tool that still lacks an updated theroretical background (I've changed the layers a little) but I plan to work on that in the future.

Damien Djaouti
profile image
Thanks for the tip, Your Layer-based cards looks very interesting. I'll try them out with my students!

Also, another similar "game design deck of cards" that may interest you is Playgen's "Adding Play" ( I didn't mention it in the article because it's a tool 100% geared towards game design IMHO, but it's also a very interesting deck of cards (and with a slightly different "layering" than yours Paolo, so maybe you'll want to try it out).

Anyway, definitively looking forwards your next article of Game Layers!