Feedback Analysis and Recurrent Patterns

From MachinationsWiki
Jump to: navigation, search

Previous: Feedback Profiles, next Implementing Machinations Diagrams

An analysis of a game's feedback loops can be used to identify structural strengths and flaws in its design. To create interesting and varied gameplay feedback is an important device, and most successful games incorporate two or more, but not that many more, feedback loops in its main structure. Structural flaws, or `bad smells' in analogy to software engineering, are constructions that are best avoided. If we take Risk again as our example, we can identify one of its problems from play experience: building as often as you can is an effective, almost dominant, strategy. To counter this strategy the game includes a a special rule preventing the players from building on more than three subsequent turns. Inspection of the feedback structure of the game suggests other ways of resolving the problem. Attacking feeds into a triple positive feedback structure (through territories, cards and continents), which is a strength of it its design, but apparently the feedback is not effective enough. Strengthening the feedback of territories will help only a little as building is part of the same feedback loop and will probably encourage the unwanted behavior. Either the feedback through cards or the feedback through continents needs to be improved. The card feedback loop involves two random factors: success of attack and the blind draw of the card itself. This makes the feedback unpredictable and very hard for the player to assess. In general, involving too much randomness in the same loop is best avoided, especially when this randomness affects different steps in the loop. It is very hard to balance and predict the feedback of such a loop, so reducing the randomness, for example by allowing the winner a pick of three open cards, will help a lot.

Alternatively the feedback through the capture of continents can be improved. The problem with this feedback is that it has a high return, is permanent, direct and fast: it is very obvious and will inspire strong reaction by opposing players, in other words it acts as a red flag. Combined with a relative high investment, it constitutes an effective but risky strategy. The strength and the obviousness of the feedback invites a strong negative feedback. This creates a feedback loop that is too crude: it is either on and going strong or it is off. Either the player succeeds in taking and keeping a continent and has a very good shot at winning, or the player is hit hard and loses what usually is a considerable investment. By making the feedback less strong, and perhaps increase the number of continents (or rather regions) for players to conquer, a more subtle feedback loop is created that will pay-out more often without unbalancing the game too much. (On the other hand, the game is called 'risk' for a reason, risk taking is an intended part of the game play. How much risk is suitable for this game is also a matter of taste.)

Recurrent Patterns

Looking at feedback structures in games, many recurrent patterns emerge. For example, both Monopoly and Risk share a similar structured, positive feedback loop that can be found in many other games as well. This pattern, which I call a Dynamic Engine, revolves around a source producing one type of resource, which can be converted to improve the source. The figure below depicts this elemental feedback pattern, using the generic names energy and upgrades for the two resources involved. In Monopoly these resources are money and property respectively, whereas in Risk these are armies and territories. The pattern can be found in many more games. In StarCraft the player invests minerals to build SUV units to mine more minerals.

Settlers of Catan has a more complicated implementation of this pattern, one where a player needs to build roads before that player can build villages, and where villages can be upgraded to cities. In this case the dynamic engine is also part of a Engine Building pattern.

Gameplay Signature

A dynamic engine has a very typical gameplay signature. When play begins players will invest most of their energy in upgrades for a while. At a certain point, players start to use the energy elsewhere or, when that is the set goal for the game, simply collect it. When one plots the output of energy over time in a graph, this leads to a sharply cornered line (see figure below). This signature is recurrent in all games that use a dynamic engine, although it might be obscured by the randomness or nondeterministic behavior caused by other feedback structures. For example, with one strategy in StarCraft called 'turtling', players invest a lot in building their base, before starting to build an offensive force to attack the enemy. When these players start attacking their offensive output is usually quite large. In the opposite strategy, called the 'Zerg rush' after one of the game's playable factions, the players invest little in their base, instead they start building offensive units as fast as they can in a bid to overpower their opponents before they have built up adequate defense (see figure below). The effectiveness of the latter strategy depends on the speed of the attacking player, but also on the balance between offensive capabilities, defensive capabilities and the building costs of the units involved.

Signature dynamic engine.png

The game signature of a Dynamic Engine
(see also Artificial Player for runnable example)

Starcraft strategies.png

Strategies in Starcraft

Previous: Feedback Profiles, next Implementing Machinations Diagrams