Design By Exception

'Skin Deep' by MichaelO

TheDaR here. The term "design by exception" is one I originally came across in RPG design several years ago.  The people using it meant it to mean the process of creating rules in a somewhat ad hoc fashion, starting from basic rules that were as simple as possible, and then layering any necessary rules to handle special cases on top of those basic rules.

The concept is not new, and has been used to varying degrees in both RPGs and wargames for many years.  What makes Design by Exception interesting is not that it exists, but the idea of using it as a deliberate part of the design process and game play space in order to produce a more interesting set of rules.

The Spectrum

Design by exception is one end of a spectrum of ways to design rules.  At the other end of that spectrum is what some people call "design by enumeration", or sometimes "complete" or "comprehensive" design.  The goal of this sort of design is the desire to have all the possible options explicitly laid out in the rules.  By having every rule completely explict, there can be no question as to how the rules interact.

Long time D&D players will probably recall that in the first edition of AD&D, every class had it's own set of tables for rolling to hit various Armor Class, their own set of tables for many different types of saving throws, and their own tables of experience progression, attack numbers and bonuses, and so forth.  In order to add a new class to AD&D, you had to produce all of those various tables.  Likewise, every weapon had it's own line in a large table,indicating what particular armor types it had bonuses and penalties against.  A new weapon, if you were using all of those rules (and many people did not simply due to the sheer hassle involved), adding a new weapon type required producing an equally full line to go in that table.  All in all, the first edition of AD&D is an example of trying to have as many rules explicitly spelled out as possible in the main body of those rules.

At the design by exception end of the spectrum lies Magic the Gathering, which is generally held to be the poster child for the concept.  Magic presents a very simple and straightforward set of basic rules, and then nearly every card provides its own exception or set of exceptions to the basic rules, very frequently in the form of keyword special abilities.  You can describe the rules for how a creature interacts with the Magic game state in probably no more than a half dozen total sentences.

With the base variations on power/toughness and summoning cost, there's only a few hundred possible combos, many of which are not that useful.  But add in a few dozens of keywords and one off special rules, and you can provide the literally thousands of variations on creatures that make Magic a rich gaming experience.  Creating a unique new creature is as simple as assign power and toughness and picking out a set of keywords or special rules to support the theme.  Nothing else in the game has to change in order to support the new creature.

Games like the current edition of Warhammer 40,000 lie in the middle of the spectrum.  Some aspects of their rules are described in a comprehensive manner, while others are done by exception/special rule.  For instance, weapon types are enumerated in their entirety.  There are only Pistol, Rapid Fire, Assault, Heavy, and Ordnance weapons.  Every weapon has to fit into one of those categories and the collection of rules they represent.  However, many weapons also have special rules which add special conditions to their usage, such as the Melta and Lance rules which alter how the weapons interact with units with Armor Values, and Poison, which changes how units with Toughness are dealt with.

Reference Examples

As mentioned above, Magic the Gathering is perhaps the ultimate example of how rules by exception can produce a successful game.  The basic rules are only about 10-15 pages of actual text to describe how a game is played.  Even the "Comprehensive" version of the rules, meant for professional judges and pro-level competitive tournaments, takes up about 80 pages to cover almost every possible interaction of basic game objects and state, plus another 60-ish pages that reiterate all the various special rules that have been on cards over the past 20 years, and another 30-40 pages covering a number of different variations on the game format for more than two players, tournament rules, casual format variations and so forth.  All that to cover 20 years and approximately 12,000 unique cards and their interactions..

Epic: Armageddon is another excellent example of how a system can be better defined by exception.  The basic rules are covered in less than 20 pages.  Another few pages define approximately 20 universal special rules that apply to units and another 15 or so that apply to weapons.  After that, another 20 pages that deal with all sorts of specialist units like aircraft, huge war engines, and space craft operations.   All told the entire contents of actual rules is under 50 pages.  The definition of a unit is a type, a speed, a number for defensive, offensive shooting, and offensive assault capability, a list of special shooting or melee attacks, and then between zero and a half dozen or so keywords like 'Skimmer, Scout' or 'Teleport, Reinforced Armor'.  A profile for a Epic: Armageddon unit takes up only a few lines of text total, but the game itself can cover the entire richness of the varying races of the Warhammer 40,000 universe.

Why Design by Exception?

One of the biggest advantages to the process of design by exception is that it will general produce a system where the basic rules are fairly simple, and the complexities are "hidden" in the various special rules that are layered over the top of those simple basic rules.  This allows new players to start picking up the game fairly quickly and lets experienced players play faster, having to internalize only a select few rules with fairly clear interactions.  As a side benefit, rules designed this way tend to be fairly compact, making them easier to write, edit, and publish.

As a designer, the primary advantage to using the exception model for design is the freedom from _analysis paralysis_. When building a rule set that tries to be comprehensive, it can be easy to get locked into loops where you have to define how many different sets of rules interact all at once.  Defining how movement rules might require knowing what types of terrain and what types of units you have, along with dealing with units of mixed types.  But designing each of those items might in turn open up further things which need definition.  It can quickly become overwhelming.  Instead, if you design by exception, you can simply define the basic rules for movement, and as you define unit types, if they need special handling for different terrain types, you can define those rules as necessary.  This sort of iterative approach to rules design can speed things up substantially.

Another benefit to the model of designing by exception is that adding new facets to your game design is generally less disruptive than in a comprehensive style of design.  For instance, for instance, adding a new unit type might require only one or two special rules for how the new type is different from other types, rather than revising several tables or sets of rules that deal with every possible unit type interaction.  Likewise, a unit that needs a new rule to make it work like the expectation of players is literally just adding that new rule to the unit.

Why Not Design by Exception?

Design by Exception is not some sort of universal panacea for rule design.

The biggest problem comes in dealing with interaction of potentially mutually exclusive special rules.  As your database of rules grows, it becomes ever harder to ensure that a new rule does not have a poor interaction with some previous rule.  This is one of the problems that a more comprehensive design faces constantly, but at least there it is usually very clear that the problem exists.  In a design by exception system, it can slip by the designer that his new rule does not play nicely with some other rule.  This can be mitigated by having a strong system for resolving poor rule interactions (Magic does this, defining a few _golden rules_ which govern how mutually exclusive rules interact and also issuing regular FAQ and rule updates to address these issues).

Another problem is rule proliferation.  With design by exception it becomes easy to simply produce a new special rule every time you encounter a new situation that needs resolving.  Before long, you have dozens or even hundreds of extra rules.  This makes the previous problem of rule interaction even more difficult, but worse, it also can make it hard for players to play quickly, as every action means resolving multiple special exception rules.   Most of this can be mitigated by keeping firm control of special rule proliferation, adding new special rules only when they're absolutely needed or revising existing rules to handle multiple situations better.

Some Best Practices for Designing By Exception

Here's a list of things to keep in mind as you go about using the principles of Design by Exception to write rules.

1. Exceptions are meant to keep your main rules simple and concise and keep special cases where they will matter, so don't go overboard.
2. Have a resolution process for rules that conflict or overlap.  It may be as simple as _the active player's rule wins_ or _cannot overrides must_, or be more complex, involving a known hierarchy of rules, but there has to be some way to figure out which one matters most if both contradict each other.
3. If you do it the same way more than once, you should consider make a unified special rule out of it.
4. If you do it the same way more than twice, you should almost certainly make a unified rule for it.
5. If you do it in a similar way more than once, try to find some way to encapsulate both use cases in one rule.  Think about what makes the two things similar and write a rule about the underlying similarity.
6. By counter example, don't try to make universal special rules out of something that only is relevant to one very specific interaction.  If only one unit in the game will ever have a rule, it doesn't need to be universal; that just litters up your main rules.
7. If you make a universal special rule, try to keep "special effects" out of it.  A rule that lets a model appear in an unusual place might represent teleporting for the original unit, but could also represent burrowing, dropping from aircraft or orbit, having laid in wait in careful ambush, or any number of other possible methods.  But if you call it **Teleport**, you might be less inclined to use that rule for alternate varitions that do the same thing.
8. If a single game object (model, unit, etc) needs more than a handful of exceptional rules, be wary.  Sometimes it's appropriate, but often times that means you're producing something that is too complicated for normal game play.
9. Be mindful of how many layers of rules you might be using.  More than 3 layers of modification should have you thinking about why you need so many levels of exceptions.  It may make sense, but there may also be a cleaner way to do it.
10. If you write a rule that has a conditional aspect make sure to specify what happens when the condition is and is not met.  This may sometimes also be of use for non-conditional rules that are expected to be overridden.
11. Keep exceptional rules as concise and straightforward possible.  Game complexity should come from the interaction of simple rules, not because the rules themselves are complicated.

How To: A Walkthrough

Here's an example of how a designer might use the idea of design by exception in order to produce movement rules for their war-game.

To start with, we need a very simple rule for movement.  *Each unit moves a distance equal to its speed stat in inches*.  That covers the basics.  It doesn't matter what the unit is, where it's going or anything.  Just one simple basic rule that covers that majority of the use cases for movement.

However, it doesn't cover one of the most common exceptional cases, which is what happens when a unit is moving through something other than simple clear terrain.  In order to deal with this, we're going to define certain areas on the table as having the **Difficult Terrain** special rule.  That rule reads *Any unit moving through an area labelled Difficult Terrain counts all distances moved as double*.  We don't actually have to go back and amend the basic movement rule; all the extra work is done by the Difficult Terrain rule.

Right away though, we can see that there are going to be some units which are not affected by difficult terrains.  Scout type units, units trained in moving through rough and broken terrain, units which hover, etc.  Again, rather than trying to amend the existing rule to exclude specific units, we add another new keyword rule.  We can call it **All-Terrain**.  And we define it thusly: *Any unit with All-Terrain may ignore the penalties associated with Difficult Terrain*.  Again, no other rule needs to change, and our scouting and hover units can be given the new All-Terrain rule and they now have the desired feature of not being affected by the Difficult Terrain, without modifying that rule or the basic movement rules.

Later on we're working on a set of army lists and we decide we're going to make a unit which is specialized at working in the jungle.   At first the thought is just to give them All-Terrain.  But jungle troops shouldn't get any advantage operating in urban rubble or deserts or lava flows.  One possibility is to just give them a new special rule; perhaps something like **Jungle Walkers** which lets them ignore the effects of any Difficult Terrain that's described as being jungles.  For a first pass that's probably fine.

But later on in the same list, we start building a unit which is specialized in arctic operations.  They need to move through ice and snow with ease, due to their training and gear.   Well, just like we did for Jungle Walkers, we could define a new **Snow Walkers** rule.  But that's the second time we've done that, and we can immediately see that in the future we might need to do other terrain types, like the already mentioned desert and urban rubble.  That's a good sign it's time to go back and rethink our special rule hierarchy.   Really, what all these various special rules are trying to achieve is limit the effect of our All-Terrain rule to only work in certain environments.  So we push the concept of limits right into the All-Terrain rule itself, changing it to read: *Any unit with All-Terrain may ignore the penalties associated with Difficult Terrain of the specified type, or all types if none are specified*.   Now we can have All-Terrain: Jungle, All-Terrain: Snow, All-Terrain: Desert, and any other type we come up with.  Those units which already have All-Terrain continue to function in the same way, ignoring every type of Difficult Terrain.

Now we have three total rules, the basic movement rule, a rule for defining areas of Difficult Terrain and the affect that has on movement, and the All-Terrain rule which lets units ignore Difficult Terrain of various types.  Three straightforward rules that cover almost every possible interaction of unit types and difficult terrain types.

-TheDaR