|
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.
|
Printer-Friendly Version
So, have you tried articy:draft yourself? If yes, what do you think of it ?
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.
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
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: http://www.gameclassification.com/EN/about/article.html.
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?
And by-the-way, I really enjoyed your book and your PhD thesis. It was very inspiring to mine.
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:
http://www.layersdesigntool.com/
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.
Also, another similar "game design deck of cards" that may interest you is Playgen's "Adding Play" (http://gamification.playgen.com/). 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!