这个模型的核心概念就是，用一些称作“符号”的元件构建游戏结构。正如Andrew Rollings和David Morris在他们的书《Game Architecture and Design》中解释的，符号是构成游戏的基本元素。各个符号可以包含一个或若干个其他符号。因此，符号可以用于构建所有游戏元素的层级结构。
现在，各个“符号”都是一个“有限状态机器”。在游戏的过程中，各个符号有不同的状态。Andrew Rollings和David Morris用一个简图表示各个符号的状态变量。下图是《愤怒的小鸟》中的“黑鸟”符号。通过同时使用互动矩阵和状态图，游戏设计师可以规范化整个游戏的结构。因为互动矩阵和状态图都是软件工程文化的一部分，所以这个工具应该有助于设计师和程序员之间交流想法。
将游戏分解成“元件”的想法也是更复杂的模型的基础，如Raph Koster的“ludemes”。受Koster的启发，Stéphane Bura引入了一种用图形表示游戏结构的系统。他使用Petri Net(PN)建模语言作为他的模型的基础。（游戏邦注：Petri Net是1960年代由卡尔·A·佩特里发明的，适合于描述异步的、并发的计算机系统模型。它既有严格的数学表述方式，也有直观的图形表达方式，既有丰富的系统描述手段和系统行为分析技术，又为计算机科学提供坚实的概念基础。）
最简单的变体只使用三个图层，如MDA模型和Katie Salen的Eric Zimmerman的初级模型。Aki Jävrinen的“游戏元素”是MDA模型的改进版，使用了九个图层，以便提供更详细的信息。如Jesse Schell在他的书《游戏设计的艺术》中所显示的，有些这类模型多达上百个图层，可能太过详尽了。
我们已经发现有些业余游戏制作工具，如GameMaker和The Games Factory 2有时候也被业内人士用于建立原型。它们在概念上其实接近于本文所介绍的工具。
例如，为了减轻游戏规则设计的工作量，The Games Factory 2提供了类似于Rollings和Morris提出的“符号互动矩阵”的巨大的面板。但是，至今，没有任何原型制作软件以这些理论模型为基础。因此，有些研究者正在利用可靠的理论模型，尝试制作新的软件工具。
Game Design Tools for Collaboration
by Damien Djaouti
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.
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.
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.
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.
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.”(source:gamasutra)