Case Study: SimWar

From MachinationsWiki
Jump to: navigation, search

Previous: Randomness and Nondeterministic Behavior


The Machinations framework can be used to study existing games and support the design of new games. To illustrate the use of the framework I choose to discuss a game of some renown within the design community, yet has never been built. SimWar was presented during the Game Developers Conference in 2003 by game designer Will Wright[1][2], who is well-known for his published simulation games: SimCity, The Sims, etc. SimWar is a hypothetical, minimalistic war game that features only three units: factories, defensive units, and offensive units. These units can be built by spending an unspecified resource that is produced by factories. The more factories a player has the more resources come available to build new units. Factories cost 5 resources, defensive units 1 resource and offensive units 2 resources; making defensive units cheaper than the offensive ones. Only offensive units can move around the map. When an offensive unit meets an enemy defensive unit there is a fifty percent chance that one destroys the other and vice versa. Figure below can be seen as a visual summary of the game and includes the respective building costs of the three units. During his presentation Will Wright argued that this minimal real-time strategy game still presents the player with some interesting choices, and displays dynamic behavior that is not unlike the behavior found in other games within the same genre. Most notably Wrights argued that a `rock-paper-scissors' mechanism affects the three units: building factories trumps building defenses, building defenses trumps building offensive units, whereas building offensive units trumps building factories. Wright describes a short-term versus long-term trade-off and a high-risk/high-reward strategy that recalls the `rush' and `turtle' strategies found in many real-time strategies.


Simwar design.png


Building SimWar, Step 1

Building up a model SimWar using Machinations diagrams is best done in few steps. Starting with the production mechanism, a pool is used to represent a player's resources. The pool is filled by an automatic source. The source's production rate is initially zero, but is increased by 0.25 for every factory the player builds. Factories are built by clicking the interactive converter labeled 'BuyF', which will pull resources only when at least five are available. contains this diagram. The structure is a typical implementation of a Dynamic Engine pattern that we have seen before. As all dynamic engines, it creates a positive feedback loop: the more factories a player builds the quicker resources are produced which in turn can be use to build even more factories. Notice that, in this case, the structure requires players to start with at least 5 resources or 1 factory otherwise players can never start producing.


Building SimWar, Step 2

Resources are also used to buy offensive and defensive units. The mechanics for this are represented by the figure below. This diagram makes use of color coded resources. The resources produced by the converter labeled `BuyD' are black while the resources produced by 'BuyO' are green as indicated by the color of their respective outputs. This means that black resources (representing defensive units) and green resources (representing offensive units) are both gathered on the 'Defending' pool. However, by clicking the 'Attack' gate, all green resources are pulled towards the 'Attacking' pool. Thus only offensive units can be used to launch an attack.



Building SimWar, Step 3

The figure below illustrates how combat between two players is modeled. Each attacking unit of one player (red on the left) generates a chance a defending unit of another player (blue on the right) is destroyed, and vice versa. In addition, attacking units also generate a chance a factory is destroyed, but that drain is only active when the defending player has no defending units left. Away from Will Wright's original set, we have fabricated the 25% chance for each attacker to be able to destroy a factory.


Putting It All Together

Combining the structures of each step, a model can be created for a two player version of SimWar. One player controls the red and orange elements on the left side of the diagram, while the other player controls the blue and green elements on the right side of the diagram. Both sides are symmetrical. Note that, in contrast to first step, the supply of resources is ultimately limited (as it is in most RTS games). This is to prevent the game from potentially dragging on for ever. If both players run out of resources before they managed to destroy the other, the game ends in a draw.



The chart displays the relative strength of each player as it developed over time during a simulated session. The strength is measured by adding five for every factory the player owns plus one for each offensive and defensive units. The chart displays what might be called the fingerprint of an interesting match.

Testing Game Balance

NOTE: This section is out of date and needs updating to the new scripting methods of version 4.0

This particular session was played by two artificial players set up to follow what might be called a 'turtling' strategy, favoring factories and defensive units over offensive units. The script these players followed was:

BuyF = 100-Factories*30
BuyD = 100-Defense*15
BuyO = Factories*20+Resources*2

Another type of artificial player was created by setting up the script to follow a 'rushing' strategy, by building one factory before directing all resources towards building offensive units:

Attack = Defense*10-70
BuyF = 200-Factories*100
BuyD = 100-Defense*50
BuyO = 100

The 'rushing' strategy proves to be very unsuccessful. Try this out by deactivating the 'turle' AP and activating the 'rush' AP for one side. The 'rushing' player builds up a large attack, but generally does not recover once its units are lost. After that attack, it is fairly easy for the 'turtling' player to defeat red with a series of smaller attacks. Out of one thousand simulated session, the 'rushing' strategy managed to win only twice. Most published real-time-strategy games are balanced towards rushing strategies, as the latter tend to be harder to execute, and mastered later by players. In order to balance the game a number of 'tweaks' were tested: I increased the costs for factories and defensive units, and decreased the cost for offensive units and run the simulation one-thousand time for every modification (see table below). Surprisingly, increasing the cost for defensive units seem to have little effect. Even when a defensive unit costs more than an offensive unit, making it a really poor choice, the turtle strategy remained dominant. This leads to the conclusion that the balance between rushing and turtling strategy is mostly affected by the balance between production and offensive units, and little by the balance between offensive and defensive units. Also note that increasing the factory costs initially increases the average game length, but decreases it for costs above eight. This can be explained by the fact that increasing factory cost slows the game as it takes more time to build up production capacity. At the same time a very high factory cost favors the rushing strategy, which tends to win faster than the turtling strategy. At higher factory costs the second effect dominates the first effect.


Table tweaks.png


In order to test out some of these effects yourself, below is an editable version of the SimWar diagram:




Previous: Randomness and Nondeterministic Behavior