Designing a Magic System - Part Three (Powers and Patterns)

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

In the first part of this series, I outlined the importance of suspension of disbelief in designing a magic system to fit the narrative of the game. But from a game design perspective, what do I mean by magic system? After all, there are distinct differences between the implementation of magic across various games - what unifying factors can we find within these implementations to allow us to consider which design is 'best' for the game play? Several games which feature magic prominently should help suggest the common ground.

Angband and the majority of Angband variants have a limited amount of mana available which slowly regenerates over time. Spells cost mana to cast and take a single turn to use, and the player can cast a spell that results in negative mana, but at the risk of fainting, both losing health and costing additional time. In addition, magic objects can be found, which have a limited number of charges, or require a recharge time to use. As the player power increases, their maximum mana also increases, which means that they can cast spells more frequently.

Advanced Dungeons & Dragons (2nd edition and earlier) limits the player by forcing them to pick a set number of spells each day to use. As the power of the player increases, they may learn and therefore cast additional spells per day, including spells of higher 'level' which are more effective. The spells must be learned in advance, so priests, especially, tend to conservatively learn healing spells, as these are almost inevitably useful. The 3rd edition of D&D allows a priest to substitute any spell for a healing spell to alleviate this defiency in the design.

Magic: The Gathering uses the concept of mana pools. At the start of each turn, the player has an empty mana pool. Then, by tapping sources of mana from cards that the player either has in play, or plays throughout the turn, the amount of mana in the player's mana pool increases. This mana comes in various colours, which correspond to the five basic card colours, as well as a colourless mana, which can correspond to each type. Then, the player uses mana from their mana pool, to play additonal cards or use powers of cards already in play. This deplenishes the total mana that the player has available. The limiting factors for the use of magic, are the total cards that the player can tap to generate mana, the majority of which 'untap' at the start of the player's next turn and can be tapped again. In particular, the player can place one land card per turn, and land is the primary source of mana in the game.

World of Warcraft is similar to Angband, in that the player has a total pool of mana which they can cast spells from. In addition, spells individually have a cool down, so that a spell cannot be spammed multiple times in a row. Some spells have an instant casting time, which means they take effect immediately, but others take longer to cast and can potentially be interrupted or delayed. World of Warcraft is well worth studying because there are a number of excellent resources such as the WoWwiki which provide thorough detail of the in-game magic system for those of us worried about the addictive effects of actually playing the game.

Looking at the above four magic systems, there are a number of systems that limit the use of magic. And this suggests a more formal definition of what an magic system is from a game design perspective: 'the use of any game ability which is limited over time by a game mechanic intended to balance this ability'.

This definition is sufficiently general to cover all of the above games, whether time is real time (WoW) or over discrete turns. It also potentially includes abilities such as Mario's double-jump (which can be used twice while in the air but no more), any game that allows you to sprint for a limited time (such as Half-Life), or even first person shooters that that have a limited rate of fire to the weapons.

But I don't see this generality as a problem: you can turn this around and use the same techniques for game design of first person shooter weapons, to design an effective magic system. The damage per second metric that the developers of Dystopia carefully evaluated for the design of the weapons in this Half-Life 2 mod (interview was here but appears to have disappeared), is as important for the design of the Rogue class in World of Warcraft, is as important as the damage per turn metrics that are critical in Angband and variants.

So what game design patterns are common to magic systems? I'll take a leaf from Gamasutra's excellent overview of game design patterns, in particular with regards to the importance of naming patterns, for presenting several ideas. Each of these design patterns is used in one or more of the magic systems above.

1. Battery

Problem: We don't want the player to use an in-game ability an unlimited number of times in succession, as this would unbalance the game. However, a short sequence uses is appropriate, followed by a delay during which the ability cannot be used. This may be to balance the damage per second of the ability, or create an interesting trade off between selecting different abilities to use.

Solution: The ability runs off of a battery which has a total charge. Each ability costs some of the battery charge, and the battery regenerates over time to replenish the charge. The maximum charge divided by the usage cost determines the total number of times that the ability may be used in succession, and the regeneration rate determines the time required to get back successive uses of the ability.

If the player has multiple abilities, they may have a different battery for each ability, or abilities may share a single battery (Such as the sprinting and the flashlight in Half-Life 2). The total amount of recharging may also be limited, in which case the battery reserve acts more like ammunition. There may be a recharge delay between the initial use and the start of recharging (cf shields in Halo or mana in Magic: the Gathering). Battery power may also be 'coloured' so that some abilities can use the battery power but not others.

Consequence: The battery allows the player to have periods of high utilisation of an ability followed by a respite during which the player is more vulnerable. This results in the game having a flow of activity followed by recovery; which fits the pattern of behaviours that Valve has reported being ideal behaviour at a more macro level, as players are unable to sustain frantic activity continuously. The battery also has tactical impact due to the increased risk during the recharging period - should the player space out use of the ability to ensure that they have a reserve in the event of requiring it unexpectedly, or should they use the ability as much as possible immediately to overwhelm any obstacles.

Examples: Mana in Angband and World of Warcraft fits the battery paradigm. The recovery time in Angband also results in increased danger, as more monsters will spawn on the dungeon level the longer the player rests.

2. Power plant

Problem: The player has a number of abilities which we want them to use simultaneously, such as moving and attacking. We still want to allow a tactical trade off, but to have periods where the player is completely unable to use the ability extremely risky, so we want these periods to be rare and explicitly requested (as opposed to the battery design pattern, where normally use can exhaust the battery).

Solution: The abilities run off a power plant which has a total power output insufficient to allow all abilities to be used simultaneously. Power is allocated to each ability explicitly, so that a percentage of the ability can be used if less than full power is allocated to it (e.g. the player may move slower, or not be able to fire as quickly, or use as many weapons at once). Some abilities may instead have a threshold power level, which is the minimum or mandatory power level required to use the ability.

Consequence: The power plant requires more management than the battery, in that instead of just explicitly using the ability, the player must also be responsible for allocation of power appropriately. If the player does not specify an allocation, the previous allocation continues to be used until the power levels are changed. Note unlike the battery, the power plant is never explicitly exhausted (see refueling below, however).

Note that the power plant design pattern may implicitly occur for an ability that has a timed effect and uses the battery paradigm. If the recharge time exceeds the charge cost, it is possible to use the ability continuously, and therefore the power plant design may be more appropriate in this instance. This occurs in UnAngband where bless is a timed spell, whose casting cost is so low the mana required to cast the spell is regenerated by the time it finishes. An equivalent power plant design for timed spells would be a significant UI improvement in this case.

Example: In Incursion, spells that have timed effects that last all day. Instead of casting these explicitly, the player just decides whether the effect is on or off, and then reduces the total amount of mana available to them for the remainder of the day if the effect is applied. This means that they regenerate to a lower total mana level than if the effect was not applied.

The power plant design pattern could be used to increase the tactics required in Eve: Online, as at present, there is no decision around whether or not to move at full speed and fire all weapons at once.

3. Refueling

Problem: Suspension of disbelief may require that a resource does not regenerate perfectly or is completely inexhaustable. Therefore, a battery may run out after a limited number of recharges, or a power plant may be exhausted after a limited power output.

Solution: The player must refuel the battery or power plant by performing a small fetch quest to a refueling point on the map. To increase the likelihood of nearby fuel being available and to decrease the repetitive nature of the fetch quest, fuel may also be dropped by defeated enemies.

Consequence: The player may have to risk exposing themselves or abandoning a secure position in order to recover fuel. This may minimise the risk of any map exploits being taken advantage of. This is balanced by the unfortunate necessity of having to repeatedly move to a common point, away from the action in the game.

Example: Weapons in Team Fortress 2 all have limited ammunition, which is quickly exhausted. Replacement ammunition boxes of various sizes respawn around the map, as well as an ammunition cabinet at the player respawn points which fully replenishes ammunition. Killed enemies will drop their weapons, which can be picked up to replenish ammunition as well.

4. Cool down

Problem: Some abilities can be used by the player to trap an opponent, by using the ability frequently enough that the opponent is never given sufficient recovery period from the side effects of the ability. These abilities can include anything which involuntarily moves the target around the map, as well as anything that disables the target or interrupts target actions. The player can then exploit the trap, by using the ability continuously.

The battery design makes it hard to enforce an upper limit on the number of times an ability can be used, because it may be possible to regenerate enough charge during the time the opponent is disabled or the time recovery to move or recover from interruption. The power plant design makes this impossible to enforce.

Solution: Allow the opponent to have a counter move to each possible ability, that they can use to avoid the trap (See David Sirlin's website for commentary on this design pattern). However, designing counter for each ability is difficult - in which case, the cool down is a good fall back method. The cool down is a period during which one or more abilities may not be used again, following an initial ability use. Note that the cool down may also apply to a combination of abilities that could create a trap together.

Consequences: The cool down forces the player to use other abilities during the cool down period, which may result in greater UI complexity, both to show the cool down duration, and make additional abilities quickly accessible.

Example: Many abilities in World of Warcraft are restricted by cool downs. Rods and activatable artifacts in Angband also have a cool down timer.

5. Juggling

Problem: Allowing a player to use abilities limited over a time period may not be appropriate. For instance, a platform game may require that the player jump twice with millisecond separation, but allowing the player to do this while in the air will allow the player to walk on the air between platforms. Additionally, resource constraints may prevent the game from running multiple copies of the ability at once.

Solution: Restrict the use of the ability on a non-time dependent criteria, usually related to either how many uses of the ability are already in play or having a battery regeneration condition that is not time dependent.

Consequences: The player is forced to juggle use of this ability in a less intuitive manner.

Examples: The original Space Invaders could only display a limited number of player bullets. The player could fire immediately once one bullet hit a target however, allowing them to attack closer targets more quickly than further away targets. See also Mario's double-jump for another example.

6. Ramp-up

Problem: The player wants to feel progression over the course of the game, and there is not enough of a skill requirement in the game to provide this feeling of progression through improving player skill.

Solution: Over time, the maximum capacity (either battery charge, power plant output or another measure) of the ability improves. This could be from turn to turn, as additional resources are brought into play, or over a longer period of time as the game is played. At approximately the same time, the challenges faced also ramp up, to ensure the game stays approximately as difficult to play.

Consequence: There are two key consequences of this design. Firstly, any part of the game design that modifies the slope of the ramp up curve needs to be carefully considered. Secondly, the skill level requirement of the game may be flattened out completely by grinding parts of the game to increase the capacity ahead of the difficulty curve, or by making the increase in challenge too explicitly linked to increasing player power. The best decision here may be to make one or the other increase explicitly time dependent, so that the player is unable to take advantage of grinding for extended period.

Example: The Power Nine in Magic: The Gathering are an excellent example of abilities which unduely increase the slope of the curve of mana development. In fact, almost every card which provides additional mana has the same consequence. With regards to grinding, no examples are necessary as it is a core RPG requirement.

7. Build & Respec

Problem: Giving the player an unlimited choice of abilities makes them unduely powerful, because of some of the abilities are designed exploit a specific opponent weakness. If the player can use any ability, they can always exploit this weakness, therefore any opponent with a weakness is less powerful than otherwise designed.

Solution: Restrict the player choices by having a build system of some kind, such as by using classes, skills or an inventory of abilities that they can use. Put restrictions in place, so that the build system allows a balanced set of abilities to be chosen, and the player to learn the advantages and disadvantages of each ability selection early in the game. Make respecifying the build as easy as possible, so that the player can change the ability load out at any point in the game, while limiting the respec so that it cannot be easily done in the middle of an encounter with an opponent.

Consequences: The build and respec system is a complex process, both to design and for the players to understand. It is critical that the player is given the opportunity to respec as often as possible, so that if they make an incorrect or suboptimal choice in their build design, they can fix this with minimal consequences. The game designer can also use this to evaluate if certain abilities are under or overpowered by the frequency of their selection in builds.

Examples: Unfortunately, class and skill based games do not usually have a good respec system for the class and skill builds, unless it features frequent death and respawning into a new class. The Dungeons & Dragons magic system allows a respec of the spell list at the start of each day, which is as close as that game system comes to an adequate respec system. Only inventory based games allow a flexible respec system with the appropriate limitations. See Skills vs Classes for an expanded argument to this effect.

Part four discusses some further design patterns: damage and status effects. Feel free to suggest other design patterns in the comments thread.