The rules presented in a game aren't always homogenous. Sometimes there are whole chapters dealing with things that were supposedly already dealt with in previous chapters. We've already seen rules for conflict resolution -- why are there more rules on combat? We've already seen rules for magic, why do psionics need different ones? The pattern is creating "sub-systems", exceptions from the regular rules, a game within a game.

There are many various places where sub-systems exist, which can be generally classified using wh questions: what is being done? Who is doing it, either out of the game or in the game? What is used to do it? And also why, where and when is it being done, either in game or out of game.

Sub-systems carry an inherit downside -- they make the rules more complex. But sometimes their advantages are worth the additional complexity. It is also worth noting that many of the considerations and options presented here are relevant for adding special mechanical elements for specific situations, even if those elements aren't full fledged sub-systems.

The subject of sub-systems is huge, and thus deserves more than a single article. In this article we'll begin the discussion of sub-systems by discussing conflicts, or distinction based on what is being done.

Conflicts

Probably the first thing you thought of when we mentioned sub-systems were special mechanics for combat. Such sub-systems are created based on the type of conflict at hand.

To discuss this, let's first take a step back. One of the basic elements of a role-playing game -- and indeed, any dramatic story -- is a conflict, which happens when two sides want opposing things. Two people want to kill each other, a thief wants to sneak past a guard while the guard wants to see everybody going through the gate, an ambassador wants to convince the king to send his troops to war while the king doesn't want to do that. For the sake of this discussion, the environment can be considered as a side in a conflict -- you want to get through the mountain pass but the snowfall doesn't want you to; you want to disarm a trap while the trap wants to kill you.

Conflicts are usually the place where the core mechanics of the game come into action -- specifically, conflicts where the success of both sides is theoretically allowed within the game (that is, holds potential entertainment value).

Usually, the core mechanic of the game deals with simple resolution at the conflict level -- the end goals of all sides are made clear, and then the dice are rolled to determine what goals succeed and what fail.

However, sometimes we want to delve more deeply into certain types of conflicts. Combat, social interaction, car chases, spaceship battles, hacking -- those are all examples of potential types of conflicts.

First we'll talk about why we want to expand conflicts and then we'll talk about how it can be done.

Expanding Conflicts: Why and Why Not

There are several possible reasons why we may want to expand conflicts, and here are some of them.

Screen Time

One of the main reasons for expanding conflicts is to give them more screen time. When a conflict is expanded, it takes more time to resolve it, which means a larger portion of the game revolves around this conflict. It also means more thought is put into describing what's happening during the conflict.

Giving certain conflicts more screen time also means that these expanded conflicts will receive more focus. Expanding a certain type of conflicts is a sign for the players and the GM that these conflicts are important to the game and should be paid attention to. Thus, Star Wars games might include a sub-system for spaceship fights, espionage games might include a sub-system for car chases, etc.

In this regard, it is important to note that providing a sub-system for combat has the same effect. When a game provides an entire sub-system for combat, it emphasises it and puts a lot of focus on it. If you do not wish your game to prominently feature combat, there is no reason why you should have your game include a sub-system for it. Remember that when combat is detailed and distinguished from other sorts of conflicts, players are likely to create characters that are effective at combat, and will then likely try to get into combat, since this is what their characters are good at. If you don't want your game to focus on combat, don't include a detailed system for combat.

Variety

Expanding the conflict allows the game designer to provide with many various options on what to do in the conflict and how to handle it. These may be tactical options, designed to provide with tactical variety, or these may be narrative options, designed to provide with a variety of ways to describe what's happening during the conflict and make it more colourful.

In theory, narrative variety doesn't necessitate the expansion of conflicts -- after all, all of those various descriptions are available even if the conflict is resolved with a single roll. However, it's usually harder for players to repeatedly come up with different interesting descriptions for doing the same small and simple mechanical thing. When many narrative options are laid out in front of the player at the mechanical level, it is more likely that conflicts of this type will feature many interesting descriptions.

As an example of narrative variety, we can look at schticks in Feng Shui. Schticks are special maneuvers in combat that provide with various mechanical options. They provide some tactical variety as well, but the focus of the game is not the tactics but the stylish Hong Kong action, and those maneuvers provide with ripe ground for descriptions of such action. Fury in Dread: The First Book of Pandemonium serve a similar purpose, providing with a bunch of special moves and maneuvers available during combat, designed to support the splatterpunk style of the game.

Additionally, expanding conflicts often allows for more granularity in the conflict's results: rather than just success or failure, many different shades and variations are available.

Tension

When a conflict is expanded, it takes more time and complexity to determine whether one's goals are met or not, and subsequently it is harder for the players to predict what the result of the conflict is going to be -- and uncertainty creates tension.

Creating a Narrative Framework

If you wish to describe the conflict as an entire scene with many interesting things happening, it may be difficult to do without a mechanical support. Not that it's impossible, of course, but it is often easier to do when there's a mechanical "skeleton" at the base.

For instance, a single persuasion roll can be played as a long scene of back-and-forth dialogue, but it may be easier to narrate such a scene when there is a mechanical base supporting prolonged back-and-forth dialogue.

The Downsides of Expanding Conflicts

Other than the added complexity, which is an inherent downside shared by all sub-systems, distinguishing different types of combat has the added downside that some players may be left "out of the loop" during parts of the game. Earlier editions of Shadowrun are notorious for having large chunks of the game be a one-on-one between the GM and the team hacker (called Decker in the game), with the rest of the players sitting around and constructing dice towers (and with the amounts of dice it had, those were pretty high towers, too).

There isn't a hard and fast solution to this problem -- different designs call for different solutions. It's just something you need to remember when you decide to create a sub-system for certain types of conflicts.

Expanding Conflicts: How

So, now that we've discussed the various considerations pertaining to expanding conflicts, let's look at how it can be done.

There are two approaches to expanding conflicts -- switching to task resolution or staying at the conflict level.

Switching to Task Resolution

This is the approach most often encountered in games. What exactly does switching to task resolution mean? A task is a single, specific action done within the larger framework of a conflict. Success or failure at a given task doesn't necessarily mean anything about the success or failure at the conflict at large, although usually succeeding at tasks related to the conflict makes succeeding at it more likely and failing at tasks related to the conflict makes succeeding at it less likely. For instance, a conflict may deal with getting rid of an evil wizard. Hitting him with a sword will probably bring one closer to this goal, but if the wounded wizard manages to escape, it didn't really matter and the conflict is still lost.

Switching to task resolution shifts some of the decision regarding the ultimate success or failure of the conflict into the hands of the GM -- it is often possible for the GM to describe the conflict as successful or unsuccessful regardless of the task results, although this isn't usually too big a concern.

Another important thing that switching to task resolution does is shifting the attention of the players from what is done to how it is done. Thus, it moves the focus away from the conflict at hand, which somewhat loosens the narrative framework -- so if one of the main reasons you want to expand the conflict is in order to provide for such a framework, you may instead wish to go for the second approach.

The benefit of task resolution is that it's very easy to create lots of various options. Tasks can also be split into smaller and smaller tasks, and thus it's really quite easy to provide with a variety of interesting options and choices.

Staying at the Conflict Level

The second approach to expanding conflicts is to keep things at the conflict level but elaborate the resolution. The benefit is that sticking to the conflict level makes it easier to mechanically enforce a certain narrative framework and keep the focus on the conflict. It also removes the GM's ability to play around with the conflict's results, which exists when working at the task level.

The downside of this approach, however, is that it's usually much harder to provide with a variety of options, and also that working on the conflict level often means that the mechanics work on a "meta-game" level, not directly representing actions within the game, which may create a sense of distance and possibly harm immersion.

One example of expanded conflicts is skill challenges in D&D 4th edition, where players describe the actions of their characters and roll the appropriate skills, and the success or failure at the conflict as a whole is determined by whether the players manage to gain a given number of successes in their skill rolls before gaining another given number of failures.

Another example is the conflict resolution mechanic in Dogs in the Vineyard. Without going into too much detail, the players begin the conflict by rolling a pool of dice based on the abilities used in the conflict, and the results of these rolls are then used in a mini-game. It also does an excellent job of creating a narrative framework and enforcing one of the main elements of the game: escalation. It is possible to escalate the conflict and add more dice to the mini-game by bringing in other abilities -- such as switching from mere arguing to a fistfight, and then escalating more by pulling out a gun -- but this may also mean that the conflict might have dire consequences for the characters. The way the conflict resolution is structured helps put the emphasis on this escalation and make it narratively important.

It is worth noting that in Dogs in the Vineyard this is the only conflict resolution system, and thus not exactly an "expansion". However, the only conflicts that are resolved mechanically within the game are conflicts involving actual characters -- no conflicts between characters and the environment are resolved mechanically. In such conflicts, the players are simply granted whatever they want and the game moves on. This is because the only conflicts that are of any interest to the game are conflicts between actual characters. From this perspective, the conflict resolution system can actually be seen as an "expansion", as it is used only for a certain type of conflicts.

Going in Reverse

Until now we've talked about expanding certain types of conflicts into unique sub-systems, but there's also something to be said about going the other way -- uniting different sub-systems into a single, unified mechanic.

The benefit of this, of course, is that it makes the system clearer and less complex. Another benefit is that it can help deal with the problem of certain players having nothing to do during certain types of conflicts. Unified systems for conflict resolution usually make it easier for all players to have something to do during every conflict, or at least during most conflicts.

Thus, if you see that the game you're designing has different types of conflicts which share similar mechanics, you may consider uniting them into a single system.

This is also true for mechanical elements which aren't necessarily expansions of certain conflict types. An example of such unification can be seen in the transition between AD&D 2nd edition and D&D 3rd edition, where the rogue skills were merged into the standard way skills operate, and THAC0 and saving throws were merged with the standard way rolls are made. Another example can be found in the transition between the 1st and 2nd editions of Exalted, where various charms were united into "excellencies". Exalted also provides an example of a place were unification could have happened but didn't: the 2nd edition of Exalted provides rules for regular combat, for social combat and for mass combat, which share many similarities. All of these various sub-systems could've been easily united into a single conflict resolution system without losing much but making the rules simpler and more streamlined.

Summary

In this article we've begun discussing sub-systems by discussing conflicts. It is possible to create sub-systems for various types of conflicts in order to give those conflicts more screen time, provide with a variety of options, create tension and create a solid narrative framework.

The two approaches to expanding conflicts are switching to task resolution or staying at the conflict level. Switching to task resolution is better suited for providing with a variety of options but it's not too good for enforcing a narrative framework, and also gives the GM the power to play around with conflict results regardless of the players' actions. Staying at the conflict level is not well suited for option variety but is the better option for creating a narrative framework.

When expanding conflicts, it is important to avoid a situation where certain players will have nothing to do during certain conflicts. It is also important to remember that when you expand a certain type of conflict -- such as combat -- it will signal the players and the GM that this type of combat is important to your game and should feature prominently.

Finally, it is sometimes good to consider uniting various mechanical elements together, if the distinction adds little value to the game, as such unification usually makes the game simpler and more streamlined.