Saturday 19 October 2013

More research in managing mechanic Machinations

More on managing mechanics and a little about economy's. But mostly managing mechanics.

I have been reading a 'Gamasautra' article about Machinations, which is about the flow and management of resources in a complex games system.It is interesting because there is a free flash tool for developers to test out their systems. It simplifies complex games systems and the user can break down their systems to individual parts to see how their in game flow of resources works. The reason this was invented was because it is difficult to paper prototype complex systems and if you do it via code, this can take a while and if it doesn't work, the code and time is wasted. This is also good for testing out feed back loops in game economies and certain structural features in games.

It can also be good for testing the resource flow of multi-player games for a single play because the designer can get into the mind set of a single player and look at their in game options. It is also a good way to look at the structural qualities of game mechanics with out any complex coding.

The main purpose if Machinations is for designers to model activity, communication between parts of a games internal economy and interaction. The article says any games economic system is dominated by the flow of it's resources.

The tool allows designers to model a game's internal economy by using Machination diagrams that use several types of nodes which, push, pull, gather and distribute game resources. It also has resource connections to determine how these resources move between two elements, and the state connections determine how the current distribution of resources in game modifies all the other elements of the diagram.

How does it work?

The diagrams are composed or pools and resource connections. A pool is a location which is where resources are gathered. In the applet they are represented by open circles and the ones with more complicated functions have a tweaked visual appearance (but that's for later). The resources stored with in them are represented by smaller circles stacked up on them. When the amount of resources is to high to show visually, they are represented by an integer number with in the circle.

Pools are used to model entities in an economy (but they can't use factional values, only integers). For example if you had a resource called 'Petrol' and an entity called 'Player's petrol tank', one would use a pool to model the petrol tank.

The most basic form of connection is a 'resource connection', it drives resources form a single to node (or entity) to another in the feedback loop game structure. In the diagram they are represented as solid arrows connecting the nodes in the diagram. These connection can transfer resources at all sorts of rates. There is a label adjacent to the resource connection indicating the quantity of resources that can be moved along the connection in a single time step. If the label is blank, it means it transfers one resource.

The random flow rates of resources between nodes can be specified and tweaked using the label box. Random rates are represented in different forms. For example, the rates can be represented using different die rolls and a die symbol will show near the connection. Due to this the applet diagram will randomly generate a number from the type of die (or dice) specified and possibly add a modifier to the combination. In other words the Mechinations Tool is able to generate random number combinations like pen and paper role-playing games. In PRG's a six sided die is represented as a D6 and two of those dice is represented as 2D6, thus the result would produce a number between 2 and 12.

But there is another way. These random number can be represented as percentages. A resource connection labeled 25 percent indicated there is a 25% change one resource can flow along the connection at each time step. One can use percentages higher than 100%. E.g. 350% means a transfer rate of at least three plus a 50% chance if one more.

Activation modes

In each iteration nodes can fire. When a node fires, it transfers resources along the connections which are connected to it. A node can fire depending on it's activation mode. A node has four activation nodes.

A node can fire automatically, so every iteration it fires. All automatic nodes fire together.

A node can be interactive, meaning it fires when the player clicks on it representing a player action. In the Machination tool these fire when a player clicks them. These nodes have a double out line.

A node can also be a starting action, this is represents with a little 's'. These fire before the first iteration, just after the user clicks the 'run' button.

A node can also be passive, meaning it only fires in response to a trigger generated by another element. Resources are able to be pushed to other nodes, but they don't push or pull unless triggered, these don't have a special mark.

Pulling and Pushing Resources

When a pool fires, it will attempt to pull any resources through any inputs connected to it in some way. The quantity it draws is determined by the rate set by the push nod. When in this node, when the pool fires, it pushed resources through it's out put connections, at the rate of it's out put resource connection. A pool push mode is indicated with a p, a pool which has only out puts is always considered to be in push mode, in that case the P marker is omitted.


If a pool is attempting to pull more resources than exits at the end of it's inputs, it will deal with it in one of two possible ways.

Automatically a node draws many resources as it possibly can, up to the flow rates determined by it's inputs. If not enough resources are accessible, it can still pull those which are.

Alternatively, a node (or pool) is able to be set to draw all of no resources. In this mode, when too few resources are accessible, nothing is drawn.


In a managing game this would be useful when dealing with an internal economy and distributing resources.

What will I include in my game from this?

For my recourse managing game I will include, resource pools since these are entities for resources to be held in.

Interactive nodes will defiantly be present since they represent a player action, when interacting with other entities to transfer resources. This action could be used as a trader for example in an economy.

Automatic nodes will be in my management game. I could use this to represent a 'source' where resources are created in the game for the economy.

Passive nodes. This could be used as a possible source or drain. However this would be more suited to being a converter or trader if used in an economy. In my option though it is more suited to being a converter. It could loosely be used as a source, but one that is infrequently used though.

Resource connections

I will defiantly use these in my game since resources need to flow to and form different entities in order to operate correctly. I could also utilize the rate at which the resources flow in these connections between entities. This would be useful when transferring resources from sources to another entity at specific rates, which could later be modified.

Pushing and pulling Resources

A node that pushes resources from one entity to another would be useful with a 'source' in a managing game since sources create resources from thin air and do not require any input. These would just push resources to the next node required or store them in the entity until needed.

If there was a player avatar this would be both a push and pull node since the player would gather all resources they could get from sources, yet they would push resources towards drains. E.g. bullets towards and enemy until the enemy dies in which the enemy is the drain.

A drain in a game economy would require a pull function since it will be physically removing resources from the game itself. It would be set to pull all resources because if not enough of a resource is available it will destroy any sent to it down a resource connection.

A converter and trader would need both a pull and push node since a resource product would flow through one connection and out the other end. A trader would be represented by a node that only draws resources when enough are available, if not nothing is drawn. This is because a trader needs a specific number of resources to trade for another set of resources.

This would also be good for a bank entity or inventory to store resources for a later time in a game. This is because all they have to do is store resources regardless of the quantity flowing from each connection.

What Might be included from this?

A converter on the other hand would pull any resources from it's inputs in order to convert the resources. This would be useful since it will pull as many resources as it can, up to the rates of it's inputs (upon t activation of certain conditions). However if not enough resources are available, it will pull as many as it can. This could work with a converter because it could convert as many resources as it can get it's hands on, depending of the requirements of the process.

Starting action nodes. I'm not sure weather this will be needed in the economy. It could be used to trigger of an event in a level in the game.

References

Adams, E. (2012). The Designer's Notebook: Machinations, A New Way to Design Game Mechanics. Available: http://www.gamasutra.com/view/feature/176033/the_designers_notebook_.php?page=1. Last accessed 19th October 2013.

1 comment:

  1. Hi Joe

    I am glad you found this resource useful. I think at this stage you could now start to put your proposal together. You don't need to have a specific game in mind. You are exploring the game economy, you can skin it once you have begun to understand the mechanics and their possibilities in more detail later. Can you take the ideas and model them in unity? would you have the scripting skills? what is involved.

    ReplyDelete