Designing a Magic System - Part Four (Effects: Locks and Traps)

(You'll probably want to read parts one, two and three before starting this).

The variety of game design patterns to restricting magic is only part of the equation: it is not useful without having an indication of what magical effects should be in the game in the first place. While 'magic' by definition could be an infinite palette of wondrous brush strokes, the vast majority of games again settle on a limited number of design patterns to define how magic works within the game.

1. Damage

Problem: By definition or convention games are be won or lost - and the simulation of warfare and conflict is a fundamental to the earliest of games, such as Chess and Go. In order to represent conflict on an individual scale, as opposed to the massed armies or tribes, it is useful to have a representation of success or failure more complex than the binary alive / dead relationship. There are a number of ways of simulating this: it could be viewed as a tug of war which requires a success of failures on one side, where one or more successes reset the simulation back to its original values; or it could be as complex as a set of values that as they are depleted, the player on that side loses the ability to perform certain actions and eventually becomes incapacitated.

The problem with the tug of war relationship is that it can result in a perpetual conflict: the gains of one side offset by subsequent loses. Ideally in an ongoing game there should be an escalation of risk, so that as the game proceeds to a conclusion, the actions of the players become more critical to determining their ultimate success or failure. But the difficulty of simulating increasing incapacitation, as in the second example, is that failure results in a negative feedback loop. The game can effectively be over prior to one of the players being adjudged 'dead'. In this instance, there is little chance of a sudden reversal through late game play: and either the game must conclude in the surrender of one player or there must be significant value in attaining a game draw or significant shame in losing the game. Chess is a good example of such a game: and a significant design challenge in unit-based strategy games is ensuring the possibility of reversals instead of inevitable decline as unit attrition occurs.

Solution: Over the last 30 years of modern game design (the era during which the individual has superseded the unit as the most important playing piece), the simple scalar relationship of hit points has proven itself to be a strong middle ground between a tug-of-war solution, and a complex set of incapacitation values. Hit points are an abstract representation of damage to a player, abstract because as hit points are depleted, there is no additional penalty accrued to player actions: neatly side-stepping the negative feedback issues of gradual incapacitation. Hit points are well understood and from a design perspective simple to implement and balance. And more complex solutions are usually implementations of multiple hit point pools combined with status effects, so a fundamental understanding of hit points is necessary to understand more complex designs.

The damage effect of magic is to reduce the amount of one (actually zero) or more enemy hit points, and when they reach zero hit points, kill them and eliminate from the game. Damage can be broken down into the subcategories of instantaneous damage, and damage over time, as well as different damage elements (used to define potential enemy resistance to damage) and shapes (areas of effect in which enemies sustain damage). Damage can have any number of complex subtleties - see part six for a fuller discussion. Keep in mind that many games just rely on damage, with no other magic effects, and still have a vast range of possible choices as to how to apply that damage.

2. Status effects

Problem: Hit points are too simple for many game design(er)s: they are just a single scalar without any incapacitation effects. However, having multiple gradual incapacitation is too complex to design, as well as resulting in negative feedback loops.

Solution: Status effects separate player and enemy incapacitation from enemy damage. A status effect prevents the player from making one or more actions over a limited period of time at full effectiveness. The simplest to design status effects are binary: while under the impact of the status effect, the player cannot perform a particular set of actions, but the simplest to balance status effects are decremental: instead of preventing the action, the player can only do it with reduced effectiveness.

The complexity of status effects is effectively conveying to the player affected by the status effect that they have impaired or restricted choice of actions, and the number of different ways that this can be done is the restriction on the maximum number of possible status effects. For instance, the screen border may change different colours depending on which status effects are being applied to the player: this would imply a maximum of three different status effects could be used (as most colour spaces are three dimensional). Or a separate set of icons could be applied either to the GUI or hovering over the player graphic: in which case the size of the the icons (balanced by legibility issues) and the available screen real estate would dictate the maximum possible number of status effects in the game.

The time to recognise the status effect taking place is also a factor in real time games: which is why turn based games tend to have more status effects permitted.

While the number of different status effects is restricted by user interface considerations, the duration and number of possible actions restricted by a particular status effect is important to consider from a game balance perspective. These are key because of the need to avoiding designing guaranteed locks as a part of the status effect.

A lock is where the player can keep the status effect applied to an enemy (or vice versa) so that no effective action is possible by the enemy. A lock may occur because the enemy only has a restricted set of actions from which to choose, and the status effect blocks them all, or because the player is able to apply enough different status effects during the duration of each effect that they are able to prevent all enemy actions. For example: there are three different status effects in a game, and these last at least four game turns. The player is able to get a lock by applying each different status effect over the course of 3 turns, so that on turn 4, the enemy has all status effects applied and therefore completely incapacitated.

There are two methods to avoiding locks: either have useful actions which can never be affected by status effects (or only degraded by them, but to the point where they stay useful), or to have status effects have diminishing returns, so that applying multiple status effects (or the same status effect repeatedly) can never build the lock in the first place.

Note that the simplest status effect is the interrupt, which is where one player's current action is stopped by another player's action. It is possible in a game to get locks with just interrupts, and no timed status effects, so testing is inevitably required to ensure that the game is lock-free.

2a. Traps

Problem: Locks are an interesting and intriguing emergent behaviour that exists as a consequence of implementing another game feature (status effects). Dictating that a game should be lock-free is counter intuitive on several levels: the player should be encouraged to experiment with the game mechanics, and not prevented from exploiting them.

Solution: A intended lock design is a trap: that is, it is possible to design games where getting a lock on an opponent is an intended part of the game play. Traps are a sequence of player actions that result in getting a lock on an enemy for a short period of time.

The function of traps differs between single player games and multiplayer games. In multiplayer games, traps are to encourage yomi. A multiplayer trap should always have a guaranteed counter in the sequence leading up to the trap, but the counter should be high-risk (that is results in a worse position than falling for the trap if the player initiating the trap instead predicts that a counter will be used). David Sirlin writes extensively on the use of traps in his book Playing to Win.

In a single player game, there is no theory of mind of the opponent, because the opponent is a computer. The game may attempt to simulate an opponent, but any simulation will be less sophisticated than a real person. Therefore traps have a different function. When used against the player, a trap is intended to discourage certain behaviour. Unfortunately, this kind of learned helplessness is not the best psychological mechanism for encouraging game play, and should usually be avoided.

Against the computer enemies, traps should be treated as puzzle solving problems. A opponent should be introduced that poses a significant problem for the player, but for which a trap exists that significantly reduces the opponent threat. Deducing the trap should require puzzle solving skills, and applying the trap should require whatever level of manual dexterity, timing and hand-eye coordination is appropriate for the game audience target. Once the trap puzzle has been solved, this opponent becomes a skill test, and should either be removed or reduced in frequency.

It is worth stressing that traps (and all locks) should always cause damage (or other game win progression): otherwise the gameplay can be reduced to an inescapable infinite loop. A good example of this is paralysis in Angband: early in the dungeon the player encounters floating eyes which can paralyze them. Once paralyzed, the player can do nothing while the eye continues to gaze at them, paralyzing them repeatedly until they starve to death. The underlying lesson in this instance is to buy sufficient armour to have high enough an armour class to avoid the attack, and not to blindly run around corners. This lesson should be learned quickly and at little overall cost, as floating eyes are frequently encountered on the first level of the dungeon where little time has been invested in developing the character. Roguelikes are full of these kinds of 'learn not to do this' traps, which is paradoxically part of their appeal.

(Roguelikes can get away with designs that would completely wreck other games because of their procedural generation and permadeath mecahnics. In another genre, such an encounter early in the game would wreck the experience completely - in a roguelike, the lesson run away and don't fight everything should be gleened early on in the game playing process).

In part five, I'll be discussing more magic effect game design patterns: resets, information, door / key puzzles and build modifiers.