Difference between revisions of "Machinations Framework"

From MachinationsWiki
Jump to: navigation, search
 
(19 intermediate revisions by the same user not shown)
Line 1: Line 1:
The theoretical framework behind this project has been submitted to the GameOn North America Conference 2009 in Atlanta. Below you can find a brief explanation.
+
Next: [[Flow of Resources]]
 +
----
 +
 
 +
The Machinations framework formalizes a particular view on games as rule-based, dynamic systems. It focuses on game mechanics and the relation of these mechanics and the dynamic gameplay that emerges from them. It is based on the theoretical notion that structural features of game mechanics are for a large part responsible for the dynamic gameplay of the game as a whole. Game mechanics and their structural features are not immediately visible in most games. Some mechanics might be close to a game's surface, but many are obscured by the game's system. Only a detailed study of a game's mechanics can shed a light on the game's structure. Unfortunately, the models that are used to represent game mechanics, such as representations in code, finite state diagrams or Petri nets, are complex and not really accessible for designers. What is more, they are ill-suited to represent games at a sufficient level of abstraction, on which structural features, such as feedback loops, become immediately apparent. To this end, the Machinations framework includes ''Machinations diagrams'' which are designed to represent game mechanics in a way that is accessible, yet retains the structural features and dynamic behavior of the games they represent.
 +
 
 +
The theoretical vision that drives the Machinations framework is that gameplay is ultimately determined by the flow of tangible and abstract resources through the game system. Machinations diagrams represent these flows and foreground the feedback structures that might exist within the game system. It is these feedback structures that for a large part determine the dynamic behavior of games. This is consistent with findings in the science of complexity that studies dynamic and emergent behavior in a wide variety of complex systems. By using Machinations diagrams a designer can give game systems a shape which would normally remain invisible. The main premise is that through Machinations diagrams, structure and quality in game mechanics become tangible.
 +
 
 +
Machinations diagrams are designed to capture game mechanics. As such, they are not only a design tool; they are also useful as an analytical tool to compare and analyze existing games. The Machinations framework allows us to observe recurrent patterns across many different games. Machinations diagrams are a medium to express and reason about these patterns.
 +
 
 +
Machinations diagrams can be drawn with any tool. The language was designed to draw easily on a computer, or on paper. At the same time, the syntax of the language is exact. It describes unambiguously how different elements interact. This allowed the development of a ''Machinations software tool'', which can be used to simulate and experiment with game systems. With this tool, a user can run and interact with a Machinations diagram. To a certain extent, a user can play a game represented as a Machinations diagram. In addition, the Machinations tool allows users to define `artificial players' that interact with a diagram automatically. This means that games can be simulated without any actual interaction of real users. Such a simulation can run very quickly, allowing a user to experiment and gather quantitative data from thousands of simulated play sessions quickly and efficiently. To support this, the tool features automatic charts to collect data from each simulated play session.
 +
 
 +
The figure below is an overview of the Machinations framework and its most important components. It summarizes the discussion above.
 +
 
 +
 
 +
 
 +
[[image:machinations_overview.png]]
 +
 
 +
 
 +
 
 +
Machinations diagrams create an abstracted perspective on game mechanics and are often used to focus on certain aspects of a game. The framework does not dictate how much detail a diagram should capture or what aspects of the game economy one should represent. Using Machinations diagrams many different aspects can be captured at many different levels of detail. The best perspective and level of abstraction is largely determined by context and purpose. Often it is sufficient to model games from the perspective of a single player, even if the game is actually played by multiple players. In these cases, it is often fairly easy to imagine how a diagram might be duplicated and combined to represent the multiplayer situation.  In other cases it is useful to model one player at a higher level of detail than other players. Likewise, particular aspects of games such as taking turns might be abstracted away. At a high level of abstraction, there often is little difference in the effects of players acting simultaneously and asynchronously, or in alternating turns. I have tried to keep the level of detail low and the level of abstraction high in the examples used in this chapter. This way the structural features of the internal economy are best foregrounded, which best serves the purpose of examining the effects of these structures on emergent gameplay. For this reason the natural scope for Machinations diagram is that of a single player and his or her individual perspective on the game system. Although it is certainly possible to model multiplayer systems, the framework, as it currently stands, does not include features designed to support multiplayer games in particular. For example, the main input device for interaction with a Machinations diagram is the mouse; there is no support for multiple input devices. Likewise, turn taking is geared towards a single player only: the system responds to every turn in a similar way. There is no support for alternating turns for a number of players; and it does not prevent the players to take actions outside `their turn'.
 +
 
 +
The Machinations framework focuses on rules and mechanics and does not take into account all elements of game design. Most importantly, the Machinations framework excludes all elements of level design. As such, the framework is more effective for games that do not rely on level design that much. This includes most board games, strategy games and management simulation games. While the framework will still be applicable to games that rely more on level design, for these games the framework can only describe a part of the picture. Level design will be the subject of the next chapter.
 +
 
 +
Moreover, The Machinations framework does not involve the player or any cultural dimension of representation through games. The framework treats games as complex state machines: interactive devices that can be in many different states, and whose current state determines the transition to a new state. This is an approach that can be and has been critiqued: without players games would be, quite literally, meaningless. The formal rule systems of games are subject to constant change and reinterpretation by players. A formal approach always runs the risk of turning a blind eye towards this dynamic and important dimension of games. However, building game systems is an important task of a game designer. It is this system that codifies the player's possible interaction and generates individual game experiences. The aim of the Machinations framework is to understand the elementary structures that contribute to emergent gameplay and that ultimately facilitates the expressive and dynamic nature of games.
 +
 
 +
Finally, one more word of caution: when one sets out to model anything as complex as games, a model can never do justice to the true complexity of the reality of gameplay. The best models succeed in stripping down the complexity of the original by leaving out, or abstracting away, many important details. This is certainly the case with the framework and diagrams I present here. However, any model is a tool that can help us understand and work with complex systems. To be able to use the model to the best effect, understanding the concepts that informed the creation of the model is required. As any model, the Machinations framework and diagrams only facilitate understanding; they are never a substitute for it.
 +
 
 +
----
 +
Next: [[Flow of Resources]]
 +
 
 +
 
 +
<!--The theoretical framework behind this project has been accepted as an extended paper for the GameOn North America Conference 2009 in Atlanta. Below you can find a brief explanation. The paper can be found on my website: [http://www.jorisdormans.nl/article.php?ref=machinations follow this link].
  
 
These feedback diagrams are intended to represent a game's internal economy and flow of resources. According to literature most, if not all, games have an internal economy and this economy plays a vital role in its emergent behavior. A game's economic system is dominated by the flow of resources. In games resources can be anything: from money and property in Monopoly, via ammo and health in first person shooters, to experience points and equipment in role playing games. Even more abstract aspects of games, such as skill level and strategic position can be modeled through the use of resources.
 
These feedback diagrams are intended to represent a game's internal economy and flow of resources. According to literature most, if not all, games have an internal economy and this economy plays a vital role in its emergent behavior. A game's economic system is dominated by the flow of resources. In games resources can be anything: from money and property in Monopoly, via ammo and health in first person shooters, to experience points and equipment in role playing games. Even more abstract aspects of games, such as skill level and strategic position can be modeled through the use of resources.
  
These are animated diagrams: you will need to click the start button to activate the diagram. When a diagram is running it cannot be edited, click the stop button before making any changes. You can experiment with the diagram below (you can click on red stars to actively redistribute resources)...
+
These are dynamic diagrams: you will need to click the start button to activate the diagram. You will see resources moving around and some of the values of the diagram change as a result of the new distribution. The are also interactive. In the diagram below you can activate the 'Converter' by clicking it. The best diagrams almost feel like playing the game, which of course makes sense as these are models of games.
 +
 
 +
<embed src="../Machinations.swf?file=../concepts/overview.xml&mode=view&width=600&height=200" width="600x" height="200px"> </embed>
 +
 
 +
The most basic elements of these feedback diagrams deal with the flow of resources. The resources themselves are represented by small colored circles that flow through the diagram. In games resources are produced by certain entities or actions, in the diagram these are represented by a [[Source]]. Actions that cause resources to be removed from the game are represented by a [[Drain]]. A [[Pool]] is place where resources are gathered. Usually a player or AI has some sort of influence on how to use the resources that are collected in a pool. Often resources can be sent along different paths from a pool. A [[Gate]] is a place where resources are immediately redistributed. [[Flow Connection|Flow Connections]] between the elements determine the routes a resource can travel.
 +
 
 +
Apart from resources, sources, drains and pools, these diagram uses state information to communicate between the different elements. State is communicated by [[State Connection|State Connections]] (dotted lines). These communicate a numeric value that corresponds to the number of resources that is currently on an entity.  
  
<embed src="../Machinations.swf?file=test.xml" width="800x" height="600px"> </embed>
+
Elements can fire, a source that fires produces a number of resources, a converter or a drain fires when it has gathered enough resources. Sometimes elements are fired automatically, but elements represented with double lines are interactive. These only fire if you click them (and if the diagram is running).  
  
The most basic elements of these feedback diagrams deal with the flow of resources. The resources themselves are represented by small colored circles that flow through the diagram. In games resources are produced by certain entities or actions, in the diagram these are represented by a [[Source]]. Actions that cause resources to be removed from the game are represented by a [[Drain]]. A [[Pool]] is place where resources are gathered. Usually a player or AI has some sort of influence on how to use the resources that are collected in a pool. Often resources can be sent along different paths from a pool. A [[Knot]] is a place where resources are immediately redistributed. Black lines connecting the elements represent the routes a resource can travel.
+
Elements might also be [[Inhibition|Inhibited]]. Inhibited elements can never fire, not automatically and not in response to a user click.
  
Apart from resources, sources, drains and pools, these diagram uses state information to communicate between the different elements. State is communicated by state connecters (dotted lines). These communicate a numeric value that corresponds to the number of resources that is currently on an entity.  
+
The basic elements of these feedback diagrams are Pools, and Gates. Sources, Drains can be replaced by Pools with infinite capacity while [[Converter|Converters]] and [[Trader|Traders]] can be created from a combination of these elements.
  
Elements can fire, a source that fires produces a number of resources, a converter or a drain fires when it has gathered enough resources. Inhibitors links can prevent elements from firing. Normal inhibitors need to pull a resource from another element or prevent the first element from firing. State inhibitors only check if a state is one or more (and do not affect the number of resources pulled).
+
Follow any of the following links to explore these concepts further.
 +
* [[Source|Sources]], [[Drain|Drains]], [[Pool|Pools]], [[Gate|Gates]], [[Converter|Converters]], [[Trader|Traders]], [[Flow Connection|Flow Connections]], [[State Connection|State Connections]], [[Modifier|Modifiers]], [[Inhibition|Inhibition]], [[Trigger|Triggers]], [[Chart|Charts]], [[Artificial Player|Artificial Players]], [[Turn-Based Diagram|Turn-Based Diagrams]], [[Diagram Settings]]
  
The basic elements of these feedback diagrams are Sources, Drains, Pools, and Knots. A [[Converter]] and a [[Trader]] can be created from a combination of these elements.
+
There are also four tutorials to get you going with the diagrams and the basic concepts behind them.
 +
* Tutorial 1: Feedback loops in games
 +
* Tutorial 2: Modeling Starcraft
 +
* Tutorial 3: Feedback Signatures
 +
* Tutorial 4: Feedback Patterns
 +
* Tutorial 5: About modeling, scope and folding diagrams (Note: unsure if this is going to be a tutorial or a paper/discussion)
 +
-->

Latest revision as of 13:22, 7 September 2011

Next: Flow of Resources


The Machinations framework formalizes a particular view on games as rule-based, dynamic systems. It focuses on game mechanics and the relation of these mechanics and the dynamic gameplay that emerges from them. It is based on the theoretical notion that structural features of game mechanics are for a large part responsible for the dynamic gameplay of the game as a whole. Game mechanics and their structural features are not immediately visible in most games. Some mechanics might be close to a game's surface, but many are obscured by the game's system. Only a detailed study of a game's mechanics can shed a light on the game's structure. Unfortunately, the models that are used to represent game mechanics, such as representations in code, finite state diagrams or Petri nets, are complex and not really accessible for designers. What is more, they are ill-suited to represent games at a sufficient level of abstraction, on which structural features, such as feedback loops, become immediately apparent. To this end, the Machinations framework includes Machinations diagrams which are designed to represent game mechanics in a way that is accessible, yet retains the structural features and dynamic behavior of the games they represent.

The theoretical vision that drives the Machinations framework is that gameplay is ultimately determined by the flow of tangible and abstract resources through the game system. Machinations diagrams represent these flows and foreground the feedback structures that might exist within the game system. It is these feedback structures that for a large part determine the dynamic behavior of games. This is consistent with findings in the science of complexity that studies dynamic and emergent behavior in a wide variety of complex systems. By using Machinations diagrams a designer can give game systems a shape which would normally remain invisible. The main premise is that through Machinations diagrams, structure and quality in game mechanics become tangible.

Machinations diagrams are designed to capture game mechanics. As such, they are not only a design tool; they are also useful as an analytical tool to compare and analyze existing games. The Machinations framework allows us to observe recurrent patterns across many different games. Machinations diagrams are a medium to express and reason about these patterns.

Machinations diagrams can be drawn with any tool. The language was designed to draw easily on a computer, or on paper. At the same time, the syntax of the language is exact. It describes unambiguously how different elements interact. This allowed the development of a Machinations software tool, which can be used to simulate and experiment with game systems. With this tool, a user can run and interact with a Machinations diagram. To a certain extent, a user can play a game represented as a Machinations diagram. In addition, the Machinations tool allows users to define `artificial players' that interact with a diagram automatically. This means that games can be simulated without any actual interaction of real users. Such a simulation can run very quickly, allowing a user to experiment and gather quantitative data from thousands of simulated play sessions quickly and efficiently. To support this, the tool features automatic charts to collect data from each simulated play session.

The figure below is an overview of the Machinations framework and its most important components. It summarizes the discussion above.


Machinations overview.png


Machinations diagrams create an abstracted perspective on game mechanics and are often used to focus on certain aspects of a game. The framework does not dictate how much detail a diagram should capture or what aspects of the game economy one should represent. Using Machinations diagrams many different aspects can be captured at many different levels of detail. The best perspective and level of abstraction is largely determined by context and purpose. Often it is sufficient to model games from the perspective of a single player, even if the game is actually played by multiple players. In these cases, it is often fairly easy to imagine how a diagram might be duplicated and combined to represent the multiplayer situation. In other cases it is useful to model one player at a higher level of detail than other players. Likewise, particular aspects of games such as taking turns might be abstracted away. At a high level of abstraction, there often is little difference in the effects of players acting simultaneously and asynchronously, or in alternating turns. I have tried to keep the level of detail low and the level of abstraction high in the examples used in this chapter. This way the structural features of the internal economy are best foregrounded, which best serves the purpose of examining the effects of these structures on emergent gameplay. For this reason the natural scope for Machinations diagram is that of a single player and his or her individual perspective on the game system. Although it is certainly possible to model multiplayer systems, the framework, as it currently stands, does not include features designed to support multiplayer games in particular. For example, the main input device for interaction with a Machinations diagram is the mouse; there is no support for multiple input devices. Likewise, turn taking is geared towards a single player only: the system responds to every turn in a similar way. There is no support for alternating turns for a number of players; and it does not prevent the players to take actions outside `their turn'.

The Machinations framework focuses on rules and mechanics and does not take into account all elements of game design. Most importantly, the Machinations framework excludes all elements of level design. As such, the framework is more effective for games that do not rely on level design that much. This includes most board games, strategy games and management simulation games. While the framework will still be applicable to games that rely more on level design, for these games the framework can only describe a part of the picture. Level design will be the subject of the next chapter.

Moreover, The Machinations framework does not involve the player or any cultural dimension of representation through games. The framework treats games as complex state machines: interactive devices that can be in many different states, and whose current state determines the transition to a new state. This is an approach that can be and has been critiqued: without players games would be, quite literally, meaningless. The formal rule systems of games are subject to constant change and reinterpretation by players. A formal approach always runs the risk of turning a blind eye towards this dynamic and important dimension of games. However, building game systems is an important task of a game designer. It is this system that codifies the player's possible interaction and generates individual game experiences. The aim of the Machinations framework is to understand the elementary structures that contribute to emergent gameplay and that ultimately facilitates the expressive and dynamic nature of games.

Finally, one more word of caution: when one sets out to model anything as complex as games, a model can never do justice to the true complexity of the reality of gameplay. The best models succeed in stripping down the complexity of the original by leaving out, or abstracting away, many important details. This is certainly the case with the framework and diagrams I present here. However, any model is a tool that can help us understand and work with complex systems. To be able to use the model to the best effect, understanding the concepts that informed the creation of the model is required. As any model, the Machinations framework and diagrams only facilitate understanding; they are never a substitute for it.


Next: Flow of Resources