Player, "I move past the monster and rush the kobold."
GM, "You trigger an attack of opportunity." (first rule set)
Player, "I have a feat that makes me immune in this case." (second rules set - the exception)Another example:
"Scissors beats rock."If we go back before DnD3, we can probably find a couple examples of exceptions in rules, but most games focused on a smaller set of rules laying out what you can do, and left the exceptions up to the referee to work out. Take TSR's classic Star Frontiers or other boxed games, most of the rules in those games laid out basically what you can do, and there were hardly any exceptions to the rule - especially in the area of character design. You had our ability scores, your skill levels, and a set of rules telling you how to make rolls, shoot lasers, and use equipment. There were hardly any rules or feats built into character design laying out "this is a list of rules you can break" in any sense.
This isn't to say exceptions are bad. With this type of design, you can create a base set of rules defining how things in the world work, and leave it at that. The special exceptions are up to the players to keep track of, and the GM to remember to apply correctly. There in lies the problem with the design, if your design leans too heavily on the exceptions, you get too much of a good thing. If your game contains a list of 2000+ feats, most of which are exceptions or special cases, you quickly get tangled up in two lists of rules and lists of exceptions that sometimes apply themselves in chains of "whoops, my X feat allowed me to have an Y bonus in Z circumstance, but this other feat does that...."
Complexity is the enemy of good design. A lot of role playing games super-size themselves with expansion books, add-ons, and new material to the point of their own extinction. An exception-based game is especially vulnerable to this problem, as the list of exceptions grows, and the list of base rules grows for the new things handled, the morass of interactions grows and quickly becomes unmanageable.
Complexity needs to be managed over a product's life-cycle, and some rules designs are more prone to "load" breakage than others. Exception-based designs are not inferior, they do many things well, but you need to recognize the limitations of a rules design as well as their advantages when you use one to craft your game. Ask yourself, how many things are my players required to remember? Do these new exceptions complicate the game? Is there a way to combine things to make them simpler? Am I asking too much of the referee and players? Could this be handled in a better way?
Stop, think, and ask yourself - does this design make things better? Does more equal better? Can my design handle additional complexity?
No comments:
Post a Comment