I remember, as 3rd Edition D&D was in its last stages of development, I looked at the long list of modifiers based on situation that would appear in the Player’s Handbook. I thought it would be a lot to track, and so for DMs who didn’t want to worry about it (and also for situations not covered in that list), I put in the DMG the “DM’s Best Friend” rule, which was simply if things were in the PC’s favor, give them a +2 to their roll and if things were going against the PC, give them a -2 penalty. In 5th Edition, this became Advantage/Disadvantage. I think these are good rules.
They’re good because they keep the amount of rules clutter down. Rules clutter is when there are multiple rules of a game coming into play at once. It can be a real issue, even in what ought to be the simplest games. Lots of modifications to a character’s action, or to a character’s effects (such as damage inflicted, saving throws or resistance rolls, or what have you) can add up unexpectedly.
Consider that DM’s Best Friend rule. Okay, so you’re launching an attack with your bow and loosing an arrow at the dragon, and you’re up high on a ledge. That’s +2. But, it’s very foggy. That’s -2. Okay, so they cancel out, net +0, and you’re good to make a normal attack roll. But, you’re also surprising the dragon, so that’s +2. And your allies are distracting it. Is that +2, or are you at +4 now? However, the dragon sits behind cover, so that’s -2. Um, where were we?
That’s rules clutter. Even a simple rule, applied over and over, becomes clutter.
But rules clutter probably occurs most often when different rules come into play simultaneously. Even in a relatively simple game, scenario design can inadvertently make a lot of rules clutter.
Say there’s an encounter at the edge of the caldera of an erupting volcano. The scenario writer might say, “Okay, if you are taking actions there, the heat gives you a penalty.” Easy peasy.
But after doing a bit of research about volcanos, the scenario writer says, “What about the poisonous fumes?” Characters there need to make some kind of roll to not get poisoned by the gases, or choke on them, etc.
And that roll would then be modified because of the heat, right?
Then the scenario writer thinks, “Well, even if you move away from the edge of the caldera, there’s still a lot of heat and fumes, and whatnot, so you still have a penalty, just not as much. And the roll to resist the fumes is easier now. Hmm. Okay. So now we’re tracking position to determine the severity of the modifiers and the difficulty of the rolls.”
But, as the volcano causes the stone edge to melt and crumble, there’s a chance that someone on the edge also has a chance of falling in. So the scenario writer adds that if characters don’t make a successful roll, they tumble—maybe down into the lava itself. And that roll is modified by the heat.
This is getting to be a lot. Each particular part on its own isn’t at all onerous, but as a whole… it’s too much. What started as an interesting place to stage an exciting encounter has become a headache for the GM. And if you’re thinking all those mods and rolls aren’t too bad, remember that this is all on top of the game’s normal mechanics. That is to say, presumably characters still will be determining initiative, making skill checks, using special abilities, maybe attacking and defending, and so on.
What’s the real culprit here? It’s our old game design enemy, “realism.” Or, perhaps it would be better to say, “simulation.” Our scenario writer is trying to simulate a volcano. Now, if the game is already about intricate rules and attempts at accurate simulation, maybe what we’ve delineated here is appropriate for the game in question. But if it was for a simple game that had abstracted a lot of things for ease of play, well, now the scenario writer has inadvertently changed that paradigm.
In other words, it’s entirely possible to accidentally turn a simple game into a complex one by trying too hard to simulate something out of the ordinary in the game. Something out of the ordinary should be fun, cool, and memorable. It shouldn’t be a regrettable headache. The last thing we want is for the GM and the players to walk away saying, “Okay, from now on, we only stage encounters in boring places.”
Arguably, for a simple, somewhat abstracted (rather than simulation-heavy) game, the scenario writer should have stopped after, “If you’re right next to the edge, you take a penalty.”
But, you might ask, “Monte, don’t all those conditions just make the encounter dynamic?” To that, my response would be that in a simple, more abstracted game, an encounter shouldn’t be dynamic—the adventure should be. In other words, I’d tell the scenario writer, if appropriate, to have an encounter at the edge, where characters face the penalty from the heat, and then another encounter with dangerous fumes, and maybe another where the ground is crumbling beneath them. That way, the GM and players aren’t dealing with all this rules clutter at once, but one at a time. Each aspect gets more of the spotlight that way, and no one is referencing multiple rules during the same encounter. Taken as a whole, the multiple encounters will feel multifaceted and interesting, but won’t ever get too difficult to manage. On top of it all, you’ll likely move through those three encounters in about the time you would have spent on just the one.
Again, if complexity isn’t a bug, but a feature in the game in question, then design toward that. Every game is different, and each probably has its own sweet spot. It also depends on the intent of the encounter. If the whole thing is just about navigating the hazards of a volcano, that’s one thing. If the players are expected to have an elaborate battle with dangerous foes at that caldera’s edge, that’s another.
Complexity has its place, perhaps in almost any game. But the simpler the game, the more complexity will stand out. An encounter like the one described above in the context of a simple game has a giant exclamation point above it. If it’s the exciting climax of a campaign, maybe that’s appropriate. Otherwise, it’s too much.
Remember, too, that in game design, complexity is a currency, and you only have a limited amount to spend. You can’t just keep doling it out without limit in any game. You have to choose carefully when and where to apply it. Just like you don’t want your finances to be ruined by lots of small expenditures, don’t let multiple simple rules pile up to become an overly complex game.
Great post.
I get where this is coming from, but as a "predominently" GM, I always get a little irked at the blame all falling on the GM. Players love complexity when it comes to them getting to show off their deep game knowledge in days long character construction, or describing their character's actions in intricate rule and "realism" detail so they can show off their knowledge of sabre fencing or whatever. Players love complexity when it comes to their own solipsistic little world of character crunch.
I think a lot of complexity is in the character creation and development, to try to make them all feel less "samey" because their sheets all list different stats and skills and abilites and whatever... yet it sucks if surface differences all boil down to the same "samey" thing, which is "Here is how the Fighter gets +2 damage, and here is how the Thief gets +2 damage..." etc.
Even if the simulation comes down to a few bonuses or penalties... as a player I do want the GM to have actually THOUGHT about these things in depth. As a player, if I'm fighting on the edge of a volcano, I expect that my actions should reflect that, and I expect to be clever enough to try and take advantage (He's in plate, and I'm in leather... I'm going to maneuver to stay close to the edge and he should heat up and become incapacitated way before I do...") and the GM better have thought through how to rule on that. Simple rule implementation or not, I want to see the logical thought process on the part of the GM, otherwise, why bother putting us on the edge of a volcano in the first place?
The trap can be trying to mechanize every aspect of that logical thought process... which as you point out, isn't necessary.