Chapter 5: Working with System Dynamics

 < Day Day Up > 



In the previous two chapters, we looked at games in terms of their formal and dramatic elements. Now, we’ll look at how the elements of games fit together to form systems, and how designers can work with system properties to balance the dynamic nature of their games.

A system is defined as a set of interacting elements that form an integrated whole with a common goal or purpose. General system theory, the idea that the interaction among elements of systems can be studied across a wide variety of disciplines, was first proposed by the biologist Ludwig von Bertalanffy in the 1940s. Variations of system theory have evolved over time, each focusing on different types of systems. Our goal here is not to look at all the various disciplines of system theory but rather to investigate how we can use an understanding of basic system principles to control the quality of interactions within our game systems, as well as the growth and change of those systems over time.

Games As Systems

Systems exist throughout the natural and man- made world wherever we see complex behavior emerging from the interaction between discrete elements. Systems can be found in many different forms. They may be mechanical, biological, or social in nature, among other possibilities. A system may be as simple as a stapler, or as complex as a government. In each case, when the system is put in motion, its elements interact to produce the desired goal, for example, stapling papers or governing society.

Games are also systems. At the heart of every game is a set of formal elements that, as we’ve seen, when set in motion, creates a dynamic experience in which the players engage. Unlike most systems, however, it’s not the goal of a game to create a product, perform a task, or simplify a process. The goal of a game is to entertain its participants. When we talked about formal and dramatic elements, we determined that games do this by creating a structured conflict and providing an entertaining process for players to resolve that conflict. How the interaction of the formal and dramatic elements is structured forms the game’s underlying system and determines a great deal about the nature of the game and the experience of the players.

As we mentioned earlier, systems can be simple or complex. Systems may produce precise, predictable results, or they may produce widely varied, unpredictable effects. What type of system is best for your game? Only you can determine this. You may want to create a game in which there is a certain amount of predictability—in which case you might design a system with only one or two possible outcomes. On the other hand, you may want to create a very unpredictable system, in which there are countless possible outcomes, determined by the choices of the players and the interactions of the game elements.

In order to understand why it is that systems act in such different ways, and be able to control the type of system elements that impact the outcome of your own games, we need to first identify the basic elements of systems and look at what factors within these elements determine how a system acts in motion.

The basic elements of systems are objects, properties, behaviors, and relationships. Objects within the system interact with each other according to their properties, behaviors, and relationships, causing changes to the system state. How those changes are manifested depend on the nature of the objects and interactions.

Properties

Properties are qualities or attributes that define physical or conceptual aspects of objects. Generally, these are a set of values that describe an object. For example, the attributes of a bishop include its color (white or black) and its location. The properties of a character in a role-playing game may be much more complex, including variables such as health, strength, dexterity, experience, level, as well as its location in the online environment, and even the artwork or other media associated with that object.

The properties of objects often form a mathematical kernel that can be essential to determining interactions of objects in a game system. The simplest types of game objects have very few properties, and those properties don’t change based on gameplay. An example of this type of object would be the checkers in a checker game. Checkers have only three properties: color, location, and type. While the location of checkers changes, their color never does. The type of checker can change from “normal” to “king” if it reaches the other side of the board. These three areas completely define the properties of checkers.

What would be an example of a game object with more complex properties? How about a character in a role-playing game? Figure 5.1 shows the main properties of a character from Diablo.

Objects

Objects are the basic building blocks of a system. Systems can be thought of as a group of interrelated pieces called objects, which may be physical, abstract, or both, depending on the nature of the system. Examples of objects in games might be individual game pieces (such as the “king” or “queen” in chess), in-game concepts (such as the “bank” in Monopoly), the players themselves, or representations of the players (such as the avatars in an online environment).

Areas or terrain can also be thought of as objects: the squares on a grid board or the yard lines on a playing field. These objects interact with other game objects in the same way that playing pieces do, and need to be defined with the same amount of consideration.

Objects are defined by their properties and behaviors. They are also defined by their relationships with other objects.

Behaviors

click to expand
5.1 Diablo: character properties

As you can see, this list defines an object of much greater complexity than our first example. Also, the properties of this object change over the course of the game, and not in a simple binary way, like the checker. Because of its greater complexity, the object in this case will probably have less predictable relationships with other objects in the system than would a simple object like a checker.

Exercise 5.1: Objects and Properties

start example

Choose a boardgame you have at home in which you are able to clearly identify the objects and their properties. Strategy boardgames often have objects with properties that are easy to identify. Make a list of all of the objects and their properties in the game you’ve chosen.

end example

The next defining characteristics of objects in a system are their behaviors. Behaviors are the potential actions that an object might perform in a given state. The behaviors of the bishop in chess include moving along any of the diagonals radiating from its current position until it is blocked by or captures another piece. The behaviors of the role-playing character described previously might include walking, running, fighting, talking, using items, etc.

As with the sheer number of properties, the more potential behaviors an object has, the less predictable its actions within the system. For example, let’s take the checkers example again. A “normal” checker has two potential behaviors: it can move diagonally one space, or jump diagonally to capture another piece. Its behavior is restricted by the following rules: it can only move towards the opponent; if it can jump an opponent’s piece it must do so; and if possible, it can make multiple jumps in a turn. A “king” has the same behaviors, but it does not have the rule regarding moving toward the opponent; instead, it can move forwards or backwards on the board. This comprises all the potential behaviors of the checker objects in the game (obviously, a very limited set of behaviors, which result in a fairly predictable game pattern).

Now, let’s look at the Diablo character again. What are the behaviors of this character? It can move: running or walking. It can attack using weapons in its inventory or skills like magic spells. It can pick up objects, converse with other characters, learn new skills, buy or trade objects, open doors or boxes, etc. Because of the range of behaviors available, the progression of this object through the game is much less predictable than the poor checker.

Does this make the game inherently more “fun,” however? We’ll discuss this later when we talk about playtesting; the fact is, the greater the complexity of gameplay does not always equate to more fun for the player, or a the better choice for all game designs. For now, it’s simply important to note that the addition of more potential behaviors tends to add choice and lessen predictability of outcome in a game.

Exercise 5.2: Behaviors

start example

Take the list of object and properties you created in Exercise 5.1 and add a description of the behaviors for each object. Consider all behaviors in different game states.

end example

Relationships

As we mentioned earlier, systems also have relationships among their objects. This is a key concept in design. If there are no relationships between the objects in question, then you have a collection, not a system. For example, a stack of blank index cards is a collection. If you write numbers on the cards, or mark them in several suits, then you have created relationships among the cards. Removing the “3” card from a sequence of 12 will change the dynamics of a system which uses those cards.

Relationships can be expressed in a number of ways. A game played on a board might express relationships between objects based on location. Alternately, relationships between objects might be defined hierarchically, as in the numerical sequence of cards described previously. How relationships between objects in a system are defined plays a large part in how the system develops when it’s put in motion.

The hierarchy of cards is an example of a fixed relationship: the numerical values fix a logical relationship between each of the cards in the set. An example of a relationship that changes during gameplay is the movement of the checkers on our checkerboard: pieces move toward the other side of the board, jumping and capturing the opponent’s pieces along the way. As they do so, their relationship to the board and to the other pieces on it continually changes.

Another example of a relationship is the progression of spaces on a boardgame like Monopoly. This is a fixed, linear relationship that constrains gameplay within a range of possibilities. On the other side of the spectrum, objects may have only loose relationships with other objects, interacting with them based on proximity or other variables. An example of this would be The Sims, where the relationships of the characters to other objects are based on their current needs and the ability of the objects in the environment to fulfill those needs. These relationships change as the characters’ needs change; for instance, the refrigerator is more interesting to a character that’s hungry, than a character who has just eaten a huge meal.

Change in relationships may also be introduced based on choices made by the players. The checkers game exhibits such change: players choose where to move their pieces on the board. There are other ways to introduce change into game relationships. Many games use an element of chance to change game relationships. A good example of this is seen in most combat algorithms. Here’s an explanation of how the combat algorithm works in WarCraft II[1].

Each unit in the game has four properties that determine how effective it is in combat.

  • Hit Points: these indicate how much damage the unit can take before dying.

  • Armor: this number reflects not only armor worn by the unit, but its innate resistance to damage.

  • Basic Damage: this is how much normal damage the unit can inflict every time it attacks. Basic damage is lowered by the target’s armor rating.

  • Piercing Damage: this reflects how effective the unit is at bypassing armor. (Magical attacks, like dragon’s breath and lightning, ignore armor.)

When one unit attacks another, the formula used to determine damage is: (Basic Damage – Target’s Armor) + Piercing Damage = Maximum damage inflicted. The attacker does a random amount of damage from 50%–100% of this total each attack.

To see how this algorithm tends to introduce chance into the relationship between objects, or units as we’ve been calling them, let’s look at an example from the strategy guide on Battle.net:

An ogre and a footman are engaged in combat. The ogre has a Basic Damage rating of 8, and a Piercing Damage rating of 4. The footman has an Armor value of 2. Every time the ogre attacks the footman, it has the potential to inflict up to (8 – 2) + 4 = 10 points of damage, or it could inflict as little as 50% damage, or 5 points. On average, the ogre will kill the footman in about 8 swings.

The poor footman, on the other hand, with a Basic Damage of 6 and a Piercing Damage of 3, will only inflict 3 or 5 points of damage each time he attacks the ogre, which has an Armor value of 4 [that’s (6 – 4) + 3 = 5]. Even if the footman is extremely lucky and does the maximum amount of damage with every attack, it will take 18 swings to kill that 90 Hit Point ogre. By that time, the ogre will have pounded him into mincemeat and moved on.

This example actually shows two ways of determining relationships: chance and rule sets. As can be seen by the calculation, there’s a basic rule set determining the range within which damage can fall. Once that range is set, however, chance determines the final outcome. Some games tend more toward chance in their calculations, while others tend more toward rule-based calculations. Which method is best for your game depends on the experience you want to achieve.

click to expand
5.2 WarCraft II: going up against an ogre

Exercise 5.3: Relationships

start example

Take the list of objects, properties and behaviors you created in Exercised 5.1 and 5.2 and describe the relationships between each object. How are these relationships defined? By position? By power? By value?

end example

[1]http://www.battle.net/war2/basic/combat.shtml



 < Day Day Up > 



Game Design Workshop. Designing, Prototyping, and Playtesting Games
Game Design Workshop: Designing, Prototyping, & Playtesting Games (Gama Network Series)
ISBN: 1578202221
EAN: 2147483647
Year: 2003
Pages: 162

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net