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