Magicka

Just a quick couple of notes:

1. Much to my (lack of) surprise, a game where you can mix spells and hurt yourself with them plays really well.
2. Reading the reviews so far, it sounds like I may have been moonlighting on the development while I slept...

Release early, release often.

Designing a Magic System Redux - Part Four (Pick any two)

You are encouraged to read parts one, two and three of this article series, and are strongly encouraged to read the original Designing a Magic System series of articles if you have not already done so. It turns out I had this article sitting in draft for about six months, so some of the Team Fortress 2 figures are a little out of date.

One thing I've tried to play with in Unangband is alternative character development models to the standard RPG tropes: experience and levels. Not that you'd ever guess by playing the game which appears hugely focused on level increase through experience gained from killing monsters. But a high level character in any Angband variant is incredibly fragile without the equipment that they will have gained along the way, which makes Angband much more about the correct selection and management of discovered items in the inventory, than it is about level gain or monster slaying.

I've discussed previously the differences between skills and classes, and some of the general disadvantages of each approach. I've also gone into detail about how to design a magic system, and how it may be worthwhile looking at differing systems of progression, without going into detail about the implementation details.

I want to talk about these details here - taking two specific progression designs from Unangband and give you the reasoning behind each of them; with specific regard to making the choices interesting.

The weakness of a lot of progression systems is that the choices are uninteresting. Take how most RPG skill systems work: where you buy skills from one or more talent trees using a pool of points which increases the longer you play the game. The choices in most of these systems are not exclusive, and instead merely become an ordering decision, that is, if you buy skill A, you can always buy skill B later on, and there is no difference ultimately in whether you choose A first or B first, provided you get both.

This problem is exacerbated in when the cost of skills deeper in the tree escalates - the Civilisation series of games being a good example - because you can skip buying one of the more expensive skills to effectively 'catch up' on all the cheaper skills you elected not to purchase previously.

The effect in both instances is that the characters end up being homogeneous midway through their progression - and only start to differentiate themselves at the higher level skills, instead of through out the talent tree.

You may argue that a particular system has skills which work in synergy, so that it is always worth picking skill ABCD in sequence, instead of EFGH, because the skills combined are worth more than e.g. ABGH. But in that instance, you're actually presenting less choice to the player, because ABGH users will be beaten by ABCD or EFGH users, so that despite having 8 skills in this example, there are only two real choices.

You may also argue that a particular system has pre-requisites so that to get skill C requires that you have learned skills A and B, E requires A and C, and so on, so that the skills at the tips of the tree are entirely dependent on which skills you have chosen earlier. But by using pre-requisites, you're again restricting the range of possible choices to only be meaningful at the tips of the talent tree, as opposed to choices further up the trunk.

There are several ways to avoid this. The first is by either using slots or sockets, so that the player can only choose a set number of skills to equip out of the possible talent trees. The inventory system in Angband is an example of using 22 slots to carry all possible discovered items, and the equipment system an example of using sockets to carry a single weapon, shield, amulet, light source, 2 rings and so on. A particular socket may hold weak, middle or powerful skills, so that you are forced to pick only one of the set of possible skills of each grade.

Take Team Fortress 2 as an example. At the time of writing, the sniper has 2 possible primary weapons, 3 secondary weapons, and 2 melee weapons. Using only 7 weapons, we have 12 possible sniper combinations because of the division of weapons into these 3 exclusive buckets. And if we could choose 3 items to carry, from 7 items total, there would be (7x6x5)/3! = 35 choices in all. Whereas a talent tree of 7 skills from, for example, 100 Rogues, would have at most 3 branches of up to 3 depth. Assuming a similar 3 selection limit, and approximating the possible choices by using a combinations with repetition counting approach, there can only be (5x4x3)/3! = 10 choices.

In general, if you have lots of skills and don't allow the player a large number of selections, you are better choosing a slot or socket approach. If you do allow a large number of selections, relative to the total number of skills available, the analysis of choices available in the talent tree by using a combinations with repetition approach breaks down, and you are instead limited by the depth of each talent tree which at best behaves like the slot approach. The socket approach has degenerate cases where the talent tree behaves better, but in general is far easier to design.

The second way to avoid this is with a sliding window approach, which is what I use in Unangband for developing abilities for familiars. A sliding window allows you at best only a subset of choices at any particular time, and periodically the window slides, so that early choices are no longer available, and later choices become available. With familiars, you can choose a new ability every two levels, and every four levels the window slides 10 abilities further on into the list of possible abilities. Since the window is also 10 abilities big (but in general does not have to be the same size as the slide distance), effectively you can choose 2 abilities out of 10 different abilities every four levels. This gives you approximately (10*9)^12 choices over the course of the game, at the cost of designing 120 different familiar abilities and putting them in an approximate order of power.

(I would hate to have to design talent trees containing 120 skills to give the same variety of choice.)

I could, of course, provide far more choices by allowing the player to pick from any of the 120 familiar abilities every time they advanced two levels (the slot approach), but aside from the game balance issues of allowing some high level monster abilities from the start, there is the real consideration that the human mind is limited in its ability to comprehend more than a limited set of choices, and breaks down its rational decision making process if presented with too much choice at once.

This limit also suggests an upper bound for the number of available talent trees to choose from, as well as the number of slots or sockets and the number of choices to be presented per socket. A lot of this is avoided in Angband because you only encounter so many items at once, and must discard choices that you've no room for in your inventory or equipment.

Designing a Magic System Redux - Part Three (Magic Items)

You are encouraged to read parts one and two of this article series, and are strongly encouraged to read the original Designing a Magic System series of articles if you have not already done so. This article also incorporates most of the text from another blog post which you may want to refer to the comments of.

I've been working on adding items with multiple 'pvals' to Unangband, and this is probably the most wide ranging set of changes I've made to the code since I began developing.

In Angband-speak, a pval is the value associated with a particular magic item flag: the +3 in a ring of Strength +3. Angband and many variants only allow you to have one numeric value per item, which was also historically overloaded with additional meanings such as the number of charges a wand would have. I've separated out that meaning (there is now a separate charge value) - and I'm now in the process of allowing items with multiple different numeric values e.g. a ring of Strength (+3) and Size (+7).

I'm not the first variant to have done this: so I'm taking an approach similar to Sangband, where the pvals are represented by a small numeric array of values, and then the flags to which pvals can apply become a bit array. So you end up with a situation where you might have pval[1] which is +3, and pval_flag[1] which is Strength, which in combination mean Strength +3.

The alternative is to have an integer array equal to the size of the possible different flags: the example here would be pval[STRENGTH_INDEX]=3. This obviously uses up a lot more memory and storage for each item, but with modern computers, the performance impact would be negligible. I've chosen the Sangband approach as much as a design constraint as a technical constraint - I have a hunch that people will have problems comparing two items which have more than 7-10 different discrete numeric values.

I have made a decision which increases the amount of code I've had to alter but should make it simpler long term, by also making item abilities such as to-hit bonus and to-damage bonus, weight and armour class, included in the pval framework I'm developing. To make this clearer, I've retitled them avals, short for ability values. An item now has abilities, associated with avals and which vary over an integer range, and flags, which are either on or off.

One possible abuse of the ability to use Angband items in multiple ways is the ability to throw ammunition instead of shooting it from a bow or crossbow. Ammunition is light, which means you can carry a lot of it, and throwing it is 'abusive' because the damage bonus that is applied to firing ammunition is also applied to thrown ammunition, without penalty. This is exacerbated in Unangband because the damage bonus was until the latest version counted twice for thrown weapons and not multiplied by missile launchers, which meant that throwing an arrow (+9,+9) may be more effective than firing it from a longbow.

The damage bonus in this example is insensitive to it's context - it is applied equally when the item is thrown, set in a trap, or fired from a missile weapon. And if you think the ammunition example could in some way be construed as sensible, consider that the damage bonus a bow applies to arrows fired from it, would also be applied if you threw the bow instead.

At the moment, I'm changing this: damage bonuses will be able to be context sensitive - a weapon that adds damage while fighting, won't necessarily benefit shooting, but may, for example, benefit being used in a trap.

I have the flexibility to allow missile weapons with incredibly good trap damage but no shooting damage bonus, but it is unlikely that a player would ever choose such a weapon over a missile weapon with superior shooting damage and no benefit in traps. Whereas if the weapon was multi-functional, it is more possible the player will attempt to take advantage of 'free' additional functionality at some point. I can do either approach with the approximately same level of cleanliness in the code: it is a data design issue, rather than code overhead cost.

There is a separate but related question about worn vs. wielded items. If a sword improves your ability to fight with it, does it also improve your ability to fight with another weapon if you hold it in your off-hand or even just strap it to your body? In particular, if you get one more blow per round with it, do you get that blow if it would be from another weapon?

On consideration, there are two related ways of thinking about magic items: firstly, how the abilities (avals) accumulate if the character is using multiple items which have this ability, and secondly whether the player inherits the power (ability, flag) of the magic item at all.

The simplest example is weight: if a character picks up two objects, both of which have weight, how is the character's overall encumbrance affected? This example is seemingly straight forward: the weight of the two objects is added together to give the total encumbrance.

But what if we measured encumbrance as the sum of weight, plus volume, plus length, which may be a more realistic way to model how difficult it is an item to carry? It may be possible to stack the two items side by side, so that the length of the total isn't the sum of the longest axis of each of them. So even this simple example can be complicated through extrapolation.

Then there is the problem of accumulating numeric values. +3 to hit, and +6 to hit is seemingly straight forward (+9 to hit), but how does one item which gives 50% resistance to fire, add to another item which gives 33% resistance to fire? Should it be additive, so that the player gets 83% resistance to fire? Or multiplicative, so that the player gets 66% resistance (1- (1-.5) * (1-.33))? I am a big fan of geometrical progression for resistances - because they provide a big impact initially which tapers off, but is still useful when added together. In the most straight forward geometrical progression scheme, level 1 resistance gives 50% resistance (1/2), level 2 gives 66% resistance (2/3), level 3 gives 75% resistance (3/4) and so on.

This also depends how you model fire damage to start with. What does 50 hp fire damage actually mean? Is 100 hp fire damage twice as hot? In which case, if you are modeling resistance to fire damage as ability to tolerate a temperature range, someone with 50 resistance may be able to ignore 50 hp completely, but take 50 hp damage from a 100 hp attack.

Specific versus damage bonuses are another tricky component to balance. In Angband, weapons have the ability to slay particular types of monsters for double, triple or higher damage, or branded with an element which does additional damage from fire, cold and so on. The Angband approach is to use the highest multiplier, rather than add the multipliers together. This is simplifies the creature design process as the designer is free to create a creature which is a hybrid of e.g. dragon and undead, without having to worry about this creature taking more damage from the weapon which is effective against both dragons and undead than against creatures which are just either dragon or undead.

The same applies to brands, even though we could model a weapon with multiple brands as doing both extra extra fire damage (which creatures immune to fire ignore) and extra cold damage (which creatures immune to cold ignore). If we treat this weapon as doing extra damage from each element, instead of picking the highest multiplier, creatures which are neither immune to cold or fire would take both sets of damage, which would make weapons with multiple brands much more effective than weapons with multiple slays.

But should this 'highest multiplier' approach be used across multiple items where e.g. a character could have a weapon with a fire brand, and also a ring which imparts a fire brand to the weapon. If yes, then there is no benefit to specialising in fire-based equipment, while there are plenty of draw backs. If no, and the multipliers add together, you have to balance for the maximum per item multiplier is multiplied by the number of possible items that the player can gain benefit from at the same time. Be sure to come up with a good reason for being unable to wear a ring on each finger and toe, and pierced through any available flap of skin.

With the inheritance question, it is clear some abilities are straight forward: they should be applied to the player if the item is equipped (fire resistance), or only apply to the object in question (proof against destruction by fire). It is specifically the 'use the item in question to perform a task' abilities which are not so clear. Take the ability to increase the amount of damage the player does.

As I highlighted earlier, it makes no sense to have the bow's damage bonus apply to the weapon when throwing it. So to address this, damage gets separated into 'damage while shooting', 'damage while setting traps' and so on. These are simple enough to apply to the player: or are they?

The dual wield problem, when a character is using a sword in his primary hand, and a dagger in his secondary, show that this is not necessarily straight forward. Does the dagger's 'damage while fighting' apply to attacks with the sword? In all likelihood, not (If you disagree, replace damage with fire brand. Does the dagger's fire brand also brand blows from the sword?). So we have to consider 'damage while fighting' as a specific property of the item, which we add at the time the item is used, as opposed to inherited by the player.

But this means that the same item ability is used in two different ways: an amulet of 'damage while fighting' is inherited by the player, but a dagger of 'damage while fighting' is only applied when we use the dagger. In which case, it may be simpler for some items to have a straight 'damage bonus', which is used whenever the item is being used, but not inherited by the player at all, whereas other items have a specific 'damage while shooting' bonus, which applies only when the item is being fired.

(I'm going to complicate this by also having rings apply some abilities only to items wielded in the hand they are worn on. This will be the left-hand for shooting and secondary weapons, and the right-hand for primary weapons.)

In the part five, I'll look at how Unangband evaluates the relative power of magic items, taking into account the inheritance or non-inheritance of various flags while keeping the above issues in mind.

But first, in part four, I'll take another look at skill acquisition.

Design A Magic System Redux - Part One (Status Effects)

In the original Designing a Magic System series of articles, I briefly looked at status effects as a way of separately out various incapacitation effects from hit points. Antoine's suggestion of an Enchanter class in Angband has forced me to take a closer look: both to justify my intuition that an Enchanter class would be inherently uninteresting, and set myself the challenge of trying to make this class, or the Sorcerer equivalent in Unangband, an interesting play style. Luckily I'm in the midst of implementing a whole host of new status effects in Unangband, so I'll be able to benefit from this design exercise as well as give you some insight into the decisions I've made.

My original thesis in Designing a Magic System was hit points are a good design compromise between a tug of war between two sides, which could result in games which never resulted in a victory condition, and incapacitating damage which would result in a negative feedback loop where the player could lose the game without being dead.

In this model, status effects become an idealized way of representing various types of incapacitation without being directly linked to hit points. Status effects are almost always timed, to allow the ability limited by the status effect to recover naturally should the player survive long enough, and can be recovered from using a variety of resets. It is important when designing status effects that it is not possible to get a lock on the player, but you can intentionally design traps, which are best suited to multi-player games, to allow a player to get a significant advantage by applying a lock, but at increased risk should the opponent predict that they are attempting this technique.

(If you are not familiar with locks and traps, I recommend that you refer to the original articles).

The canonical example of a status effect is the interrupt - this interrupts whatever the other player is doing and forces them to start again. If the interrupt takes less time than whichever action the other player is attempting, you can keep your opponent constantly interrupted - and if you start your interrupt action before they do, you can get a lock on the other player by interrupting their attempts to interrupt you. If the game has an action which takes less time than an interrupt, but does much less damage than the standard action, you can create a trap: the other player may attempt a standard attack for a lot of damage, but be at risk of your interrupts, or use the weak attack to avoid being interrupted, which exposes them to your standard attack. The trap in this example is only interesting if the other player is a human opponent: because it forces you to build a model of what the other player is thinking - in effect, to second guess them.

The interrupt as a status effect can be problematic for two reasons: the interrupt can be constantly applied if the duration of the interrupt is longer than the time required to apply it, and if there is no way the opponent can get a win if you choose to always interrupt. I've referred to both of these as locks, but these are actually different but related behaviours. (Note in this example, the duration of the interrupt is actually the duration of whichever action your opponent was attempting, plus the duration the interrupt prevents further activity for.)

Even if you are careful to ensure the interrupt action takes longer than the time it interrupts the other player, if you team up with other players, it may be possible to get a lock on a single player through judicious timing of interrupts. (Or conversely, multiple enemies could get a lock on you).

But imagine an interrupt which only affects some of the possible actions the other player could choose. An example in Angband is blindness. Blindness has a partial effect on the player's melee and shooting skills, completely prevents spell casting and reading scrolls, but has no impact on the player's ability to quaff potions, or use rods, staffs or wands. As a designer, you can minimise the risk of constant blindness by designing items which can reset the blindness effect and ensuring that they are usable via a action which blindness does not prevent - as a player, you can minimize the risk by ensuring that you carry these items. The counter-example to be avoided: a helmet of blindness which can only be removed by reading a scroll of remove curse. This would give the player into permanent blindness once they accidentally wear this item - not catastrophic, but a significant impact on the overall game.

(For the Unangband equivalents, you could extend this table to include all the possible status effects to get a feel for what different types of partial incapacitation could do.)

By using partially incapacitating status effects, and allowing resets, we can side step the risk of unintentional locks because the player can always reset themselves out of a lock, or choose an action which is unaffected by the lock that allows them to progress towards winning. (Using rods, staffs and wands are permitted while blind for this very reason).

There is still the risk of cumulative locks as follows: imagine there are some number of partially incapacitating effects, each of which affects the player's ability to do certain things, but when some of these effects are applied together the player is totally incapacitated. You can design your way out of this problem by ensuring that there is always something the player can do - but I think there is a more interesting alternative.

I've been using the term path to victory somewhat loosely: but let's be more rigorous about it. The path to victory is the total distance (number of actions or time) that the player needs to win the game. The shortest path to victory is the player doing the optimal action at every point and the opponent picking the most suboptimal action: the game is unbalanced if both the player and opponent choose their most optimal action and either is guaranteed victory. Unbalanced games are fine against multiple opponents (Angband being a classic example of this).

For this argument, assume the path to victory is always progressed by doing damage to the opponent's hit points. In this instance, the most logical way to win is by using your most damaging attack. A counter strategy to this is to use status effects against you which prevent you using your most optimally damaging attack, and force you to use a more suboptimal attack. Ideally the first status effect to apply would be the one that causes the most difference between the two: but it may also make sense to use a status effect which lasts longer and gives your opponent a bigger window for counter attack.

The path to victory is blocked completely if the opponent is able to use a combination of attacks which prevent you doing any damage at all to them. We call this a lock.

The above is pretty self-explanatory and you can see various techniques for reducing the risk of a lock (always allow a damaging attack and a reset to be available, reduce the duration of the combined status effects so that the time to implement them all exceeds that figure etc).

Here's my theory: the risk of a lock becomes a non-issue, when the distance to achieve a lock (time or actions) is the same as the length of your path to victory. That is, if the effort required to get a lock on an opponent equals or exceeds the effort required for to win against that opponent, from a design point of view you don't have to worry about the risk of a lock being applied. In essence, getting the lock is just as difficult as winning.

(In fact, you can have a more generous margin, because it may not be initially clear whether direct damage or a lock is the correct approach to take.)

Antoine's Enchanter (and Unangband's Sorcerer) then becomes a class which can lock opponents through a combination of status effects with about as much effort as another magic using class would take to kill them.

And in part two, I'll look at which status effects that Unangband has to support this.

Designing a Magic System - Part Fifteen (On Hacks)

(You'll probably want to read parts one, two, three, four, five, six, seven, eight, nine, ten, eleven, twelve, thirteen and fourteen first).

The school spell lists as I designed them in part fourteen are intended to be a mix of banding tradition as well as an attempt to find new ways of making magic in Unangband interesting. I've been inspired here, as much elsewhere, by the design work in Sangband and elsewhere by Leon Marrick and although aided by many, this particular series of articles is dedicated to him and the insight and inspiration he has given me and many others.

Angband is a game of resources: and each magic school has a different way of handling the resources of light, food, escape, healing, mana (spell points) and item identification which help define them. Wizards have no reliable source of food at all, and no high level healing, but can readily concentrate mana to recover it and have the most flexible range of escape spells, and both the ability to light rooms as well as to use light as an attack, and to replace their fuel based light source with a magical spell which can be indefinitely powered provided that sufficient mana is available (and that the wizard is not plunged into darkness by letting this spell run out - spells require light to be read from their respective spellbooks). The Unangband Wizard has the ability to take advantage of magical items such as wands and staffs: both with a spell (gauge magic) which readily identifies the number of charges that the item has, and a recharge magic spell to replenish these charges as they are used.

I attempted to balance the flexibility and power of the wizard escape spells by limiting them significantly for the other magical schools. Druids can only teleport to and from water or natural areas (defined as being adjacent to plants), masters only to and from darkness, thaumaturgists require a nearby source of fire, and sorcerors can only teleport temporarily, returning to the location that they teleported from after a moderate amount of time passes. This was done to allow other escape spells, such as temporary hasting, and spells which shape and change nearby terrain, such as wizard lock and warp wood, to be preferred by these classes in various ways. However, the escape spells are much less flexible, perhaps too inflexible, to be reliably used, and since escape is of critical importance to magic using classes it may mean that the wizard ends up being the preferred class choice for Unangband players.

Druids are encouraged to manipulate their surroundings and many druid spells have been made synergistic with each other: while they can only teleport near nature, they can create trees to bring nature to them in the first place, and then these trees can be used to tangleroot opponents or recover health using the tree of life spell; similarly the mana pool spell draws mana from nearby sources of water. Once opponents are entangled, it becomes much easier to affect them with slow building natural attack spells which are their forte (a yet to be implemented forte at the moment unfortunately), and the ground can be further prepared by shaping the rock by turning it to mud. Food for a druid is trivially satiated with a single spell, light is randomly scattered around them as opposed to lighting up whole rooms (which encourages more preparation to 'fill the gaps'), and item identification through a useful but obscure system of runes which hint at a particular items function.

Masters summon monsters, and while the friendly monster AI is powerful and flexible enough for monstrous combat between the master's allies and enemies, I need to give the master more granular control for when they summon multiple differing types of monsters. To encourage the master to have more investment in their minions, I've added a Find Familiar spell, which summons a unique creature that the Master can tailor over the course of their career - but if this creature dies, it is lost forever.

One thing I've enjoyed doing with various master spells is monster design: in particular the Animate Dead spell requires I come up with undead versions of various body parts and creature types. I'll say more about hacks shortly, but I've implemented this as a blend of hacks of various kinds, instead of a 'purer' convert a monster to undead function. The sorceror's Animate Object has been similarly entertaining.

Masters relish darkness instead of light, attacking with it in various ways, teleporting to and from it, and consequently have a temporary infravision spell which allows them to detect warm blooded monsters in the darkness - I should also add a Night Sight spell which provides further visual acuity at a higher level. High level healing is acquired by draining the life from living enemies (or allies), which simultaneously feeds the Master, and mana can be acquired by sacrificing hit points in return - since Masters need mana to pay off summoning debt, it could be overpowered letting this be more readily recovered. Item identification provides a general hint as to whether an item is beneficial, and what approximate effect it has.

Sorcerors are a mix of traps, charm spells, mental attacks and shape-changing: charms being more effective than the master's abilities in summoning, and shape-changing very much a work in progress. I've probably gone overboard in terms of making shape shifting unfriendly for the player to use as it forces them to discard equipment in various inventory slots. I suspect I'll move back to the Oangband/Sangband style solution of making shape-shifting just affect player attributes. Sorcerors are almost as flexible as wizards in the ways they can escape, perhaps more so, but lack a pure 'get away and stay away' single turn spell. They are superior to other classes in their item identification magics, and instead a source of sustenance, they can readily slow their metabolism to prolong the effects of food they have consumed. Sorcerors lack any ready source of light, healing or mana however, so will be forced to scrounge for other methods of illuminating the dungeon and recovering from wounds and spellcasting.

Finally thaumaturgists are attack, attack, attack, with a mainline in randomly assigned elemental types (to be implemented) and a sideline in acid and fire magics. They can usefully renew their torch flame to allow unlimited light and step into flames to teleport and escape but otherwise lack any utility spells.

After spending fifteen parts discussing various design decisions to try to come up with a consistent and systematic method, I've yet to find a solution. In particular, my answers are variations on two themes. The first is a refutation of the argument I made in part one, that 'As a game designer, [...] flavour is all important, but ultimately distracting'. Designing classes is almost all about flavour and style: do these abilities fit a consistent theme, do they complement each other, and so on? We can take on principles of good design, and the importance of the language and grammar of design will be increasingly a requirement as our games continue to increase in complexity. But ultimately, we want to present the player with interesting choices, a set of hills or valleys in the possibility space of the game, and to avoid overwhelming the player with too much choice, we have to highlight certain highs and lows, while ignoring others.

The second theme is the importance of exceptions. As a programmer, your intuition is ultimately to try to re-use your code where ever possible. But as a game designer, of the magic systems, you want to ensure that each ability uses at least some unique code path. That is, each ability in your game must in some way be a hack. It can be a small hack (fire burns, cold freezes) or a large hack (the recent implementation of a Find Familiar spell required a complete monster progression system to be interesting), but it should ensure that each ability is different, and therefore affects the game play in some unique way. Extend the ability idea as far as you can (cold freezes water, allowing you to cross rivers and block swimming monsters from attacking you) and then push yourself a little to see where it takes you. Don't obsess with trying to make the code clean and regular: it's the abilities that the player has that keep them empowered and playing, and suspension of disbelief should trump any reduction in code complexity.

Normally I finish these design articles with a set of principles, but here I only have practise. It has taken me close to 7 months to list these practises and there are many more devils in the detail that only a close inspection of the code and asking me questions will do justice to (and please, ask me on the blog rather than via email so that the questions and answers are shared for all). I'm not throwing my hands up in the air: but this type of design requires iteration and playing, and decisions, and your decisions will not be the same as mine.

(You'll want to continue reading the follow article series Designing a Magic System Redux, where I address issues, such as status effects, magic items and summoning which I haven't discussed so far).

Designing a Magic System - Part Fourteen (Classes)

(You'll probably want to read parts one, two, three, four, five, six, seven, eight, nine, ten, eleven, twelve and thirteen).

In part eleven, I suggested that a class-based system was the most appropriate mechanism for provide alternative spell types. In Unangband I cheat this slightly, and term the choices between different spellbooks schools. When you choose a school, you are actually choosing which spell book you start with, and which spell books are stocked in the shops. Each school has 4 spell books in increasing order of difficulty, which you can learn spells from, and these shape the starting experience as a player.

What experience should different classes provide? This is as much about the significance of the choice of class in the game. In a multi-player game choosing a class is as much about complementing the choices of the team you are on (or all choosing Pyro and spamming the opposition with flamethrowers in Team Fortress 2); in a single player game with multiple avatars, it is about wish fulfillment - what kind of person are you to lead others; in a single player game, each class must be capable of surviving the game on their own. It is a delicate balancing act to ensure that class is not necessarily a proxy choice for difficulty level - although many standard class choices end up having different difficulty curves throughout the game. I believe classes should instead be a choice about playing style.

Roguelikes are uniquely replayable, and class choice can be as much about playing particularly challenging games. On one hand, harder class choices should not be made available to starting players; on the other hand, harder class choices are required to learn and understand various advanced strategies of play. In Angband and variants, mages typically have a hard start and mid game, warriors have a harder mid game, and priests have an easy mid game and potentially hard end game due to their lack of damage output. As further anecdotal evidence, you may want to refer to analysis of the character dumps on the Angband.oook.cz landder.

But I don't want to link spell choices to this implicit difficulty curve - and I have worked to ensure that the start game for mages is easier through increasing mana availability (although at the same time harder, because I have removed the link between mana gained and spells learned - these are now controlled by separate attributes, rather than Intelligence being a catch all for mages and Wisdom being the equivalent for priests). So to me, the playing style argument is the most compelling.

But what do I mean by playing style? Well in Angband, consider the difference in play mechanics between a mage, a warrior and a priest. The warrior is best bumping into monsters one at a time at melee distance, and built to endure frequent mistakes (the worst of which is holding down a direction key and filling the keyboard buffer); the priest is a weak warrior mage, with a ready supply of resets which makes their gameplay style very forgiving; the mage is a glass battleship, and plays more like a game of chess, where each choice has much greater impact and many more choices are available.

The function of schools in Unangband is primarily to facilitate spell choices, and secondarily to encourage different playing styles for mage-like classes. The schools I ended up creating are:

The school of Wizardry contains the most flexible spell selection for defense and a broad and powerful range of direct offensive spells. Wizardry has few weaknesses: no reliable method of
satisfying a wizard's hunger and few spells that can be used to attack an enemy without putting the wizard in harm's way. Wizards should be thoughtful in offense and quick to escape or evade an enemy that exhausts the resources at their disposal.

Aspiring Wizards start with the book of Cantrips.

The school of Druidry contains a wide variety of different spells, include a good low level offense, but is hampered by difficult to use defensive spells and offensive magic that takes a while to get
going and may leave the Druid in close proximity to harm should they fail to work. A Druid operates best when he is able to prepare the ground upon which he fights, and works best in open spaces: conjuring trees, calling forth lightning and fire and so on. This is also the Druid's weakness: he must operate in the open, and takes a while to prepare his magic, which means he can be overwhelmed before his magic can be used.

Novice Druids start with the book of Hedges.

The school of Mastery contains some useful low-level magics, but at higher levels is heavily reliant on the ability to summon and control minions for the great part of both offense and defense. This is a double-edged sword: while the minions are more than capable of providing the Master protection and dealing out damage, he has a heavy investment in them, and will have to pay a 'mana debt' or 'blood debt' should they be destroyed. This reliance on minions means that the tables can turn very quickly on the Master and get out of control.

Wouldbe Masters start with the book of Curses.

The school of Sorcery is both deceptively weak and strong. A Sorcerer lacks the immediate damage dealing capacity of the Wizard and the long term damage capability of the Druid, and does not have the same range of minions as the Master. The Sorcerer's spells and minions are useful in preparing the ground like the Druid, in particular with a range of traps and mimics, and enraging and drawing in the enemy. But his abilities to ensorcle perhaps any enemy, will give him opportunities and gambits far greater than the Master is capable of.

Neophyte Sorcerers start with the book of Glamours.

The school of Thaumaturgy contains the widest range of direct offensive spells, to allow a thaumaturgist to find and exploit the weakness of any opposition. The Thaumaturgical energies at his disposal randomly vary from individual to individual, and as a result, the exact spell selection will vary. The weakness of the Thaumaturgist is a distinct lack of flexibility in defense: with limited and hard to use escapes and utility magics.

Latent Thaumaturges start with the book of Fireworks.

In addition, there is a school for each semi-spell class, that is the Ranger, Artisan and Rogue classes who don't have access to attack magic, but do use a variety of utility spells. The Rangers prefer the Statecraft school, starting with the book of Trailcraft, Artisans prefer the Science school, starting with the book of Trades and Rogues prefer the Spellstealing school, starting with the book of Tricks.

The emphasis for Wizards and Thaumaturges is on spells that deliver damage to line of sight targets only, with the Wizard having the capability of evading or redirecting opponents that get too close, while the Thaumaturge tries to overwhelm them with greater variety of attacks. For Druids, Masters and Sorcers, the emphasis is on indirect damage, through devastating attack spells which take a while to take full effect for the Druid, through pets for the Master and through a combination of traps and usurping enemy assets for the Sorcerer. Indirect damage is lower risk and to compensate, these classes should require more complex set ups to get this damage delivered.

With these thematic ideas in place, and the base framework of spell choices to build it on, it becomes a matter of building the individual spell books for each class to implement these ideas. The spell books as they currently are designed are shown below:

Wizard	Druid	Master	Sorcerer	Thuamaturge
Detect Monsters Wizard Lock Light Area Magic Missile Phase Door Torch Cure Light Wounds Find Hidden Traps/Doors Stinking Cloud Confuse Monster	Detect Life Dryad's Embrace Lightning Spark Moonlight Sting Find Water Purify Self Warp Wood DUST OF SNEEZING	Darkness Chill Detect Evil Shadowstep Sting Blood Binding Infravision Detect Traps Stinking Cloud Find Familiar	Detect Minds Wizard Lock Flee Mind Thrust Temporary Displacement Ignore Pain Infravision Detect Doors/Stairs Ego Whip Force Bolt	Wizard Lock Acid Splash Firewalk Flee Torch Ignore Pain Infravision Thaumaturgic Missile Find Flame Fire Blast
Teleport Self Spear of Light Polymorph Other Trap/Door Dest-ruction Detect Power Fire Bolt Frost Bolt Gauge Magic Lightning Beam Minor Acid Ball Slow Poison Wizard Light Wonder	Sleep Monster TANGLEROOT CALL LIGHTNING Dryad's Tryst Ent's Song Satisfy Hunger Sleep Monsters Turn Stone to Mud Freeze Minor Frost Ball IGNITE BLAZE Snuff Small Life	Poison Missile Curse Monster Animate Dead Sticks to Snakes Change into Bat Slip into Shadows Sense Magic Air Spirit Curse Monsters Fire Spirit Darkness Bolt Fear Turn Undead Summon Lemure Create Golem	ACID TRAP FIRE TRAP FROST TRAP LIGHTNING TRAP Animate Object Change into Mouse CYROKINESIS Enrage Monster Probability Travel Value Magic Rune of Escape Slow Metabolism Gust of Wind PYROKINESIS Spider's Web	Thaumaturgic Minor Bolt Blind Monster ACID TRAP FIRE TRAP Phlogiston Minor Acid Ball Smoke and Mirrors Thaumaturgic Minor Beam Wonder Minor Fire Ball Thaumaturgic Bolt
Minor Lightning Ball Dispel Magic Acid Bolt Lightning Beam II Slow Monster Frost Bolt II Concentration Cone of Cold Frost Ball Recharge Item I	EARTHQUAKE Ent's Seeds Runic Magic MIASMA Ent's Draught Change into Goat	Earth Spirit Water Spirit Wizard Eye Sense Invisible Unseen Servant Dark Rituals Animate Elements Summon Insects Vampiric Drain	Charm Bird or Mammal Change into Cat Charm Person Confusion Charm Insect Charm Reptile Invisibility Mind over Body Mind's Eye Psychic Blast Psychometry	Alt Thaumaturgic Beam Thaumaturgic Beam Acid Ball Alt Thaumaturgic Minor Ball PYROTECHNICS Thaumaturgic Ball Thaumaturgic Minor Ball
Mass Sleep Teleport Other Haste Self Identify Wonder II CHAIN LIGHTNING Fire Ball Fire Swarm Melting Ray	Dryad's Kiss CREEPING DEATH BLIZZARD Mana Pool THUNDERHEAD Tree of Life TSUNAMI TWISTER VOLCANO	Swallowed by Shadow Bind Demon Mass Curse Darkness Ball Summon Spirit Phantasmal Force Banish Evil Release Curse Path of Blood	Domination Thrust Away Psychic Crown Change into Serpent Change into Wolf Charm Monster	Flame's Reach Test Magic Wonder II Arc of Thaumaturgy Fire Ball Thaumaturgic Ball II Thaumaturgic Bolt II Thaumaturgic Bolt III Thaumaturgic Major Ball Thaumaturgic Major Ball II

Key: Spell choices, where an equivalent spell exists for each class in italic

Summoning spells underlined

Direct damage spells in bold

INDIRECT DAMAGE IN CAPS

What is obvious from the above chart, is that the desire to use classes to keep equivalent spell choices separate is in conflict with trying to use classes to keep a consistent playing style. For instance, the thematic linking between Druids and frost spells, and Thuamaturgist and fire and acid spells encouraged me initially to spread the summon elemental spirit spells out to these classes. This of course runs counter to the reasoning that Masters should be the summoning class. But if all elementals are summoned by Masters, then I end up in the same design problem that I highlighted by making all elemental bolts available to the same spell caster.

Even with these constraints in place, I keep redesigning the spell layout for each school. Since designing the first version of chart, I've changed my mind again and moved all the summon elemental spells back to the Master class. I worry that I'll be perpetually rearranging the chairs on this game design Titanic, unable to get off and actually release a final version of the game.

In part fifteen, I'll discuss more design decisions that I made to come up with this list and try to point to a better solution.