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":

• Token, at the bottom, is a layer to reference every game element (i.e. "tokens", as defined by Rolling & Morris).
• Prop layer contains the different "properties" of the tokens. We observe here a high similarity with the Object-Oriented paradigm: "token" would be "objects" and "prop" would be their embedded "methods."
• Dyn lists all the actions a player can perform.
• Goal lists all the goals a player have to reach to win the game.
• Meta references any other element that is not defined in the previous layers, but that is still playing an active role in shaping the player experience.
• Last but not least, Psycho summarizes any emotion the player is likely to feel when he is playing.

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