I have a general design philosophy of creating widely useful abilities. There are several reasons for this:
It tends to create simpler and more useful rules. When you aren’t trying to narrowly tailor a rule to model a very specific situation, you can usually leave a lot of the special case rules — the little nitpicky rules that make it difficult to remember or apply the rule on the fly — by the wayside.
It leads to emergent behavior in the system. This is where complex strategies and long-lasting appeal come from. Games like Candyland or Monopoly which can essentially only be played in one way successfully (“roll the dice” or “roll the dice and buy every piece of property you can”) are relatively boring games. Games like Chess or Go, on the other hand, have only a handful of rules, but those rules lead to emergent behaviors that lead to complex and varied strategies.
It usually empowers the players. Some designers tend to forget that roleplaying games are, fundamentally, about letting the players do really cool things. The definition of “really cool things” will depend on the game you’re playing and the genre you’re aiming for (in some cases “really cool things” will include “dying horribly at the hands of creatures from beyond time, space, and human ken”), but roleplaying games are still fundamentally about players doing things.
The problem with this design philosophy is that sometimes it will lead to an unbalanced rule. In the interests of keeping a new rule flexible and useful, the rule will end up being too useful. There are basically two forms of this:
An ability becomes so useful that every character ends up having it. This is generally undesirable because it reduces the complexity and variety of the game. When every character looks like a cookie-cutter copy of every other character the game has lost its dynamic quality.
An ability becomes so widely applicable that it is constantly being used. Since using any rule tends to take a certain amount of time, this tends to bog down gameplay in an undesirable way.
(There are exceptions to these rules, but they tend to be core components of the system. For example, saving throws are so useful that every character has them. Making a melee attack is so widely applicable that attack rolls are constantly being made. You’ll notice, however, that the basic rules for these widely useful and widely applicable abilities are as simple as they possibly can be: Roll a single die, add modifiers, compare to a difficulty class.)
The fact that my design philosophy can occasionally lead to problematically over-powered rules is not a problem. Or, rather, it’s not a problem as long as you have a chance to properly analyze and playtest the rules. (This is, sadly, not as common in the RPG industry as it should be. I remember one product I worked on with a dozen other writers. Towards the end of the design cycle, the editor asked the writers to submit a list of their playtesters so that they could be properly credited. I promptly sent in my list of a five playtesters. When the book was published there was a grand total of six playtesters listed.)
This is all one long prelude to saying: Upon playtesting and analysis, my initial “Thoughts on Tumbling” (posted March 28th) had two problems:
First, a stupid mistake. In translating my thoughts on tumbling from my house ruled version of D&D back to the normal version of the game I messed up some terminology. I said “swift action” when I should have said “immediate action”.
Second, the ability to use tumbling to negate any hit is too widely useful once you add in Combat Reflexes. Combat Reflexes basically becomes a must-have feat.
So, in fact, my mistake in using “swift action” instead of “immediate action” actually becomes prophetic in a sense: You should only be able to use tumbling to negate hits resulting from attacks of opportunity you provoke. (Which means that “swift action” is, in fact, the correct terminology.)
I have revised the essay as it appears on the Creations page, but I am leaving the original posting of the essay intact so that the two versions an be compared (if anyone should so desire).
