f you want to make a tabletop RPG designer happy, call that designer's game elegant. It's the highest praise you can give a game. It's like saying, "This game is a world-class athlete with a PhD in astrophysics and an impeccable sense of style." Elegance means that your game not only works, it works well.
Unfortunately, when it comes time to build a game, elegance is a slippery target. It isn't like cooking with salt or garlic, where one can simply add more or less to taste. Elegance is a byproduct of your approach to a work, your eye for design, and your decisions on when and how to build rules within the game. To make things even more complicated, you're more likely to introduce elegance to a game by removing something than by adding it.
Though elegance is a shifty goal, it is by no means impossible to achieve. My favorite tool in the quest for elegance is finesse. An approach that attempts to put a minimum amount of effort, tracking, and work into an RPG, design finesse relies on a few precepts:
- Remove problems by removing rules whenever possible.
- When facing many problems, solve them with a few big changes.
- Design rules that are invisible to players who don't need them.
- Go with the flow of the game, not against it.
Solve a Problem by Removing It
I love this solution to a problem. It's the experienced designer's way out of even the thorniest corner. If part of the game doesn't work, excise it. Delete! Eliminate! Doctor Who's Daleks would be great with this approach.
Though it's not always a practical solution, deleting a rule to solve the problems it causes can be a powerful tool. It forces you to question your assumptions and to focus on the truly critical parts of an RPG.
In the design of D&D Next, we made use of this approach very early on. The process of tracking and calculating Fortitude, Reflex, and Will saves added time to character creation and placed an extra layer of detail into every monster. Saving throws are obviously important to the game—but was the manner in which they had been previously implemented adding too much detail and complexity to the game?
Thinking about this complexity forced us to reconsider how we did things—so why not just use ability scores to make saving throws? This step removed jargon from the game and sped things up at the table. We kept saving throws, but we removed much of the complexity around them.
Putting everything on the table as potential fodder for the chopping block forces you to design toward efficiency and ease of use. It reminds you that complexity is a budget that you must spend on the parts of the game that offer the biggest rewards to DMs and players.
Understanding that budget plays a huge role in letting you make your cuts in the right places, and drove much of our huge playtest of D&D Next. The insight we gained from the playtest surveys helped to guide us as we decided what to cut, what to slim down, what to keep, and what to expand upon.
One Bullet, Many Targets
This edict requires you to keep a strong handle on the entirety of your RPG system. As playtest feedback comes in, it's easy to focus on individual elements and get straight to work. Stuff is broken, so you want to fix it. However, it's better to hold off and take a big-picture approach.
Let all that feedback come in, give it some time to accumulate, and then start working through it. To start with, don't even look at the specifics. Categorize the feedback into different topics. You might divide it up by class, race, or subsystem. If an issue touches on multiple areas of the game, flag it and categorize it in each area.
Many issues are simply details that need ironing out, or tactical errors (a spell does too much damage, a monster's special attack is missing a saving throw) that you can solve with a simple editing pass. However, when you see the big picture, you can see that what appeared to be individual issues are often subissues that combine to underline a single larger problem.
Your big issues—the ones that require fundamental system changes—will shine through in multiple points this way. As such, trying to fix all of those subissues individually simply papers over the actual, fundamental malfunction hiding deeper within the system.
During our very earliest tests of D&D Next, the advantage mechanic grew out of this imperative. In past editions, we've used tables big and small to capture all the +1 or –2 modifiers that can creep into the game. Advantage (along with its sinister twin, disadvantage) is easy to remember, simple to apply before or after a roll, and comprehensive enough to devour huge swaths of fiddly modifiers.
We went through a lot of arguments and ideas over how to implement a variety of penalties and bonuses in the game—along with calls to simply do away with the entire concept or approach it from a much more radical angle. In looking at the static that modifiers caused, it was clear that removing them from the game eliminated many issues. The game was faster, there were fewer exceptions to memorize, the DM had fewer things to track, and the game became much simpler to explain to beginners or players who didn't care much for memorizing complex rules.
This case also shows how one rule can indirectly lead to another. The action points of 3rd Edition and 4th Edition inspired the concept of advantage. Using an action point allows you to take an additional action. Most often, you might make an attack, miss, and then spend an action point to make that same attack again. Action points essentially allow a small-scale do-over, and that concept of a reroll as a bonus morphed into D&D Next's advantage mechanic.
In part 2 of this article, Mike continues with a discussion of opportunity attacks, and talks about how simplification and applying the rules of the real world guide the quest for finesse in the design of D&D Next.
Mike Mearls is the senior manager for the D&D research and design team. He has worked on the Ravenloft board game along with a number of supplements for the D&D RPG.