作者：Damien Djaouti

本文介绍了一些“正式的游戏设计工具”，能够拉近游戏设计师和程序员的距离。现在，游戏设计师可以依靠一系列理论工具来设计电子游戏。这些工具首先是为了便利设计环节。然而，其中有些工具可能有助于设计师将想法传达给团队中的其他成员，特别是开发人员。在下文中，我将首先介绍四个这种工具，然后探讨这些工具如何促进游戏工作室的设计部门与程序部门之间的交流沟通。

引言

在将自己的想法传达给团队中的其他成员时，游戏设计师一般会先写一份游戏设计文件，详细地介绍游戏的方方面面。然而，2012年的研究表明，有些游戏开发者认为那份极其全面的文件事实上毫无用处，如果团队成员没有时间阅读的话。

所以，他们正在实验能促进不同学科之间交流的新方法。同时，自2000年以后，游戏设计的研究文献也非常多了。

在这些书籍和研究文章中，有些游戏设计师提出了一些规范化游戏设计的工具。这些“规范化的游戏设计工具”能够促进设计师与开发者之间的交流吗？

为了解答这个问题，我们收集了许多1999-2012年之间的游戏设计相关的书籍和文章资料。在这些书里，我们确定了与游戏设计的诸多方面有关的几种规范化模型。有些模型旨在规范化游戏结构，有些模型试图规范化玩家行为，还有些工具甚至尝试制做一个玩家-游戏关系模型。

在本文中，我将重点介绍有助于设计师规范游戏结构的四种模型。我们将首先讨论这些工具，再研究如何将其用作开发工作室的内部沟通工具。

符号模型

这个模型的核心概念就是，用一些称作“符号”的元件构建游戏结构。正如Andrew Rollings和David Morris在他们的书《Game Architecture and Design》中解释的，符号是构成游戏的基本元素。各个符号可以包含一个或若干个其他符号。因此，符号可以用于构建所有游戏元素的层级结构。

例如，《愤怒的小鸟》（Rovio Mobile，2009）可以分解出四个符号：“小鸟”、“猪头”、“障碍物”和“记分器”。“记分器”和“小鸟”下属于更大的“玩家”符号。“小鸟”、“猪头”和“障碍物”可以再分成几个

次级符号：“红鸟”、“蓝鸟”、“黑鸟”、“木头障碍物”、“冰块障碍物”……使用这一系列符号，可以轻易地制作出一张模拟在游戏中发生的所有“符号-符号互动”的矩阵图。

(《愤怒的小鸟》中的符号层级和互动矩阵图)

正如那两名作者所说的，这个模型很适合简单的游戏，但对于更复杂的游戏就不太管用了。因此，他们引入了符号模型的变体来处理更复杂的游戏结构。这个变体除了保留上述符号外，又引入“变量状态符号”。

现在，各个“符号”都是一个“有限状态机器”。在游戏的过程中，各个符号有不同的状态。Andrew Rollings和David Morris用一个简图表示各个符号的状态变量。下图是《愤怒的小鸟》中的“黑鸟”符号。通过同时使用互动矩阵和状态图，游戏设计师可以规范化整个游戏的结构。因为互动矩阵和状态图都是软件工程文化的一部分，所以这个工具应该有助于设计师和程序员之间交流想法。

图解模型

将游戏分解成“元件”的想法也是更复杂的模型的基础，如Raph Koster的“ludemes”。受Koster的启发，Stéphane Bura引入了一种用图形表示游戏结构的系统。他使用Petri Net(PN)建模语言作为他的模型的基础。（游戏邦注：Petri Net是1960年代由卡尔·A·佩特里发明的，适合于描述异步的、并发的计算机系统模型。它既有严格的数学表述方式，也有直观的图形表达方式，既有丰富的系统描述手段和系统行为分析技术，又为计算机科学提供坚实的概念基础。）

事实上，他“劫持”了所有这个语言的元素，把它们与游戏设计关联起来。因此，现在可以用PN的“符号”代表资源，“地点”代表游戏的元素，“转移”代表玩家的所有活动。

尽管对了解PN的人来说，Bura的模型应该是很有趣的，但我认为大多数软件工程师更容易理解Joris Dormans的模型。因为这个模型是以UML（统一建模语言）为基础的。

它以“协作图”为基础来表示各个游戏元素之间的交互活动。Dormans画的第一个模型严格地遵守UML标准。之后，它演变为一种基于UML的图解游戏结构的自定义方法，即“图解模型”。这个模型很适合用于设计具有内部经济系统的游戏，即玩法中涉及资源的游戏。

第一步是制作一个“资源库”，用于表示游戏元素。然后，这个库可以与其他东西产生交互作用，即执行四个基本过程：产生资源、清空资源、转化资源、交换资源。在Ernest Adams的帮助下，Dormans最近以这个模型为基础，写了一本关于游戏设计的书。

(Dormans的图解模型中使用到的图形元素。)

结构模型

在Dormans的图解模型的基础上，Daniel Cook进一步提出一个工具，不仅可以表示游戏的结构，而且可以体现玩家-游戏的交互作用。在构建模型时，他定义玩家为“受驱动的实体，有意识或无意识地学习具有高感知价值的新技能。他们从成功地掌握技能中获得快乐”。这个定义接近于Koster对“乐趣”的理解。在Koster的书《乐趣理论》中，他提出：“乐趣，我认为就是，当我们以学习为目的而掌握新模式时，大脑给我们的反馈。”

至于游戏结构，Cook将它分解为一系列“结构图”。各个结构图都对应一种玩家必须学习的“技能”（例如，当马里奥收集满100个金币，生命就增加一条）。根据Cook的说法，“技能”只是玩家为了理解如何赢得游戏必须发现的信息块。学习一个“技能”可能涉及若干个“结构图”。这些“结构图”由四个部分组成，如下图所示：

Cook使用“结构图”作为表现所有玩家/游戏结构的元件。结构图之间可以互相关联，然后形成一个“非线性技能学习链”。因此，这个工具能够产生规范化的结构，用于反映游戏规则-规则关系和玩家-游戏关系。

使用这种模型，游戏设计师可以很方便地把想法转达给团队中的所有成员。例如，开发者可以使用它来辅助建立游戏的软件结构的“自上而下”的方法。开发者还可以用所有结构图的简图建立第一层结构，然后再分别确定各个结构图的内部结构。通过提供关于玩家相关技能的信息，这个工具可能还可以成为游戏测试的参考指南，便于开发者发现玩家成功掌握（或没有掌握）的“技能”。

（用Cook的结构模型表示《愤怒的小鸟》）

图层模型

另一种规范化游戏设计的方法是将游戏分解成一系列“图层”，使设计师在设计游戏时能专注于某个图层。

这些图层与游戏中的任何东西都相关，从内部游戏结构到玩家体验。这个模型存在若干变体。

最简单的变体只使用三个图层，如MDA模型和Katie Salen的Eric Zimmerman的初级模型。Aki Jävrinen的“游戏元素”是MDA模型的改进版，使用了九个图层，以便提供更详细的信息。如Jesse Schell在他的书《游戏设计的艺术》中所显示的，有些这类模型多达上百个图层，可能太过详尽了。

在这些“基于图层”的工具中，最适合表现游戏结构的一种应该是由Paolo Tajè提出的模型。他的模型将游戏-玩家关系分解成六个图层。游戏设计师每次只要专注于一个图层，就可以更简单地设计或调整游戏。这些图层按照“游戏”到“玩家”的顺序准确地排列：

符号，位于底层，是代表每一个游戏元素（即Rolling和Morris所说的“符号”）的一层。

属性层，包含符号的不同“属性”。它与对象型图解模型非常类似：“符号”相当于“对象”、“属性”相当于对象内置的“方法”。

动态层，罗列了所有玩家可以执行的活动。

目标层，罗列了所有玩家为了赢得游戏必须达到的所有目标。

变化层，在上一层中没有确定的、但仍然对玩家体验具有重要作用的元素均属于这一层。

心理层，概括了玩家游戏时可能产生的所有情绪。

（用Tajè的图层结构表示《愤怒的小鸟》）

从这个模型，可以看出游戏的不同元素的概况，有助于设计师发现潜在的设计缺陷。通过将所有游戏功能总结并分类成单个文件，游戏设计师可以很轻松地把设计想法反映给其他部门。首先，程序员可以使用符号层、属性层、动态层和变化层作为建立数字原型的参考；然后，再利用心理层检验游戏测试时玩家是否产生预期的情绪反应。

讨论

所有这些构建工具都具有相同的目的：以规范化的方式体现游戏结构。尽管各种模型具有不同程度的详细度和复杂度，但在游戏设计师必须向程序员解释某个创意时，本文中提到的这四个模型都是很有用的。

正如在本文的引言中提到的，有些游戏开发者正在寻找辅助或替代传统的游戏设计文件的新工具。我认为借助本文中提到的模型，游戏工作室的设计部门可以很方便地把想法传达给其他部门。通过使用规范化的模型，游戏设计师可以把自己的成果转化为程序员也习惯的形式。

尽管有些模型不是以早已存在的标准（如UML或PN）为基础的，但它们都受到编程语言的抽象过程的深刻影响，更准确地说，是受到“对象型编程图解”的影响。确实，所有这些工具都把游戏分解成不同的和独立的元素，并明确地表示所有这些元素之间的交互作用。我用下表总结这些模型的潜在用途。

四种“规范化游戏设计工具”的比较：

由上表可知，这四种模型都适用于简单游戏项目。例如，制作像《FarmVille》这类游戏，游戏设计师可以先用“符号”表示游戏的所有元素（如农作物、动物、土地……）；然后通过矩阵图定义这些符号之间的基本交互作用（如农作物可以种在土地上……）。

但是，具有复杂经济系统的游戏应该使用图解模型（游戏邦注：例如，在给定时间内，各种农作物产生的资源的属性）。这种模型产生的文件有助于程序员建立游戏的可执行原型。设计师可以使用结构模型和图层模型规范化游戏测试的指导方针。使用结构模型还是图层模型，取决于游戏的内部复杂度。

另一种方法是使用单一的模型。例如，结构模型可以产生详尽的文件，用于程序和测试部门之间的交流以。这个工具通过“结构图”系统详述各条规则和游戏元素，能指导程序员的工作。这些“结构图”可以与由学习“技能”产生的“预期的玩家体验”关联起来。测试员可以把这些信息作为参考。

结论

直到今天，本文中介绍的工具都没有得到游戏工作室的广泛使用。虽然有些专业人士可能觉得它们不实用，但我们认为这主要是出于两个原因：一是不知道这些模型的存在，二是难以将它们运用于游戏制作过程。

通过介绍与游戏设计相关的这四个模型，我希望游戏开发者能意识到这类理论工具的存在。至于将它们运用于游戏制作过程，我认为它们实用性体现在两方面：一是有助于设计师在“确定的框架”的指导下设计游戏；二是这些工具有助于程序员构建游戏的软件结构。它们把设计师的成果转化为类似于对象型图解的形式，有助于设计师和程序员之间的交流。通过模拟预期的玩家反应，这些也许还能帮助设计师给测试部门提供清楚的指导方针。所以，游戏工作室希望用新的交流工具取代传统的游戏设计文件，规范化的游戏设计工具不失为一种理想的解决方案。

然而，因为直到现在这些工具仍然处于理论阶段，不能产生直接的代码。为了规范化游戏设计，下一步应该是根据这些模型制作原型软件。确实，有了像IBM的Rational Rose这样的程序，程序员可以通过绘制UML图形自动生成代码。所以，为什么游戏设计师不能使用类似的游戏设计工具呢？

我们已经发现有些业余游戏制作工具，如GameMaker和The Games Factory 2有时候也被业内人士用于建立原型。它们在概念上其实接近于本文所介绍的工具。

例如，为了减轻游戏规则设计的工作量，The Games Factory 2提供了类似于Rollings和Morris提出的“符号互动矩阵”的巨大的面板。但是，至今，没有任何原型制作软件以这些理论模型为基础。因此，有些研究者正在利用可靠的理论模型，尝试制作新的软件工具。

我已经提到基于结构模型的软件工具。它可以用于执行一些查找设计缺陷的自动测试，但设计师并不能利用它制作可玩的原型。另一个例子是Ludocore，它是一种建立可玩的游戏原型的工具，使用的是事件演算逻辑语言。多亏了它强大的理论基础，它产生实用的“游戏痕迹”。这个工具可以记录玩家的活动，从而帮助设计师改进游戏规则。

我与其他研究人员一起，也在这个领域做了一些实验。我们的“Gam.B.A.S.”工具的理论基础是，将游戏结构分解成名为“游戏砖块”的元件。为了制作更好的软件工具，我们现在正在制作这个理论模型的改进版本。

这类工具的设计是一种实验性工作，需要大量研究和开发投入。不像图像或物理研究，使用新的专业设计工具的很难转化为商业游戏的特殊卖点。因此，大学实验室如果想介入电子游戏相关的研究，这个领域似乎是个机会。

虽然已经有一些学术性项目了，但我们希望更多其他研究者和行业专家能够对探索“规范化游戏设计工具”产生兴趣。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

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.

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.

Diagram-Based Machinations

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.

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.”(source:gamasutra)