A few weeks ago, I decided that, since I was starting a new D&D campaign, I might as well redo the entire equipment system in Dungeons & Dragons. Remember that? Well, I told you I was redoing the armor table. But I didn’t stop there. I redid armor and weapons, and I even changed the way the game handles spellcasting focuses. And that’s how a simple campaign ended up with a 60 page Player’s Guide. Seriously. And if you support me on Patreon at the Frienemy level and have access to my Secret Stash, you got to see just how bonkers I am. I shared the whole document in there.
All the rest of you know is that I was rewriting the armor system. And when we last talked about it, I had built an armor table that seemed really good. Except that it was utter crap. I pronounced it kludge. That’s the word for a solution that is too complicated for the problem it’s solving. Remember this table? Or something that looked like it?
Yeah. It’s ugly as hell, isn’t it? Imagine recording all of that on your character sheet. Unless the character sheet has spaces for all of those particular skills, that would all be a b$&*% to record, wouldn’t it? Okay, as we’ll soon see, that’s not the best measure. But it’s a good measure. Anyway.
When it comes to designing stuff, there’s more to it than just, well, designing stuff. There’s also testing stuff. And I’m doing that right now in my home game. I’ll let you know how it goes unless I forget. Which I will. Because I always do. But beyond designing stuff and testing stuff, there’s also cleaning stuff up. Because – and this is true of everything – the first draft of anything is s$&%.
In this second and final part of my two-part series on overcomplicating the armor system for reasons that seemed good when they were in my head, we’re going to clean up and finalize the design. And we’re going to focus on two things: elegance and extensibility. So, let’s clean up our s$%&!
Extensive, Elegant S$&%
I have talked numerous times about the twin game design concepts of complexity and depth. Complexity refers to how many things a player has to learn or know or remember to play your game or use your system. To choose a really easy and obvious example: in Dungeons & Dragons (5E) the fighter class is less complex than the wizard class. To play a fighter, you don’t need to keep track of as much s$&% as you do to play a wizard. Fighters have a very small number of simple abilities. Even that fighter with the stupid pile of dice and the weird abilities that are powered by dice is simpler than the wizard with his spell preparation, pile of spells to choose from, shorter pile of spells to prepare from, and short list of spells to cast using spell slots of various levels or using the ritual casting option if the spell allows. Wizard players have to know more, remember more, and keep track of more than fighter players do. In general, complexity makes your game harder to learn and more challenging to play. Higher complexity games demand more brain power and record keeping and have a steeper learning curve.
Depth refers to how many different ways the game can go depending on the decisions the players make. Chess is a deep game. There’s a lot of ways the game can go. Especially compared to a game like Candy Land. All games of Candy Land pretty much look the same. And Dungeons & Dragons is way deeper than Chess because it is so open-ended compared to Chess. Depth is what keeps a game interesting and exciting and what makes it worth playing over and over. Games lacking in Depth, like Tic-Tac-Toe, get boring quick.
So, you want depth, but you want to avoid complexity. And that’s a problem because, in general, complexity helps CREATE depth. Chess is deeper than Candy Land partly because the game is more complex. But it’s not always a one-to-one trade. Sometimes, you can get a lot of depth from a small amount of complexity. Consider Go. Or Othello, which is what they called Go when I was a kid, and my dad taught it to me. Othello was advertised with the tagline “a minute to learn, a lifetime to master” because the rules themselves were simple, but the game itself involved complex strategies. Which is why it lasted so long.
And that’s where elegance comes in. A game element – say a specific rule or system – is elegant when the element adds depth to the game without adding much complexity. A mechanic can be elegant for a lot of reasons. It can be simply because the rule is simple. Or it can be because the system is useful for lots of different things. When they brought out D&D 3E, they introduced the d20 Core Mechanic. That was a rule which said, “whenever a creature tries to do something, the player or GM rolls 1d20 and adds an ability modifier and then compares the result to a fixed difficulty number.” Previously, D&D had had different rules for attack rolls, saving throws, non-weapon proficiencies (if you were using them), reaction rolls, morale rolls, surprise, initiative, bending doors and lifting gates, and surviving resurrection. The d20 Core Mechanic was elegant because it worked for lots of different things. And because it didn’t require a whole lot of brain space. Though it could get complex when there were a lot of modifiers.
The d20 Core Mechanic was also extensible. A mechanic is extensible when new stuff can be added to it easily to make it do new things. You could extend the d20 Core Mechanic by adding a new ability score to cover a whole range of new actions. Or by adding new modifiers for different situations. You could require multiple rolls before the success was really a success. Or the actual result on the die could mean something special in some cases. Or the difference between the result and the target number could be assigned a meaning. Right? D&D has used all of those options in different places in its rules.
A mechanic doesn’t HAVE TO be elegant. It doesn’t HAVE TO be extensible. But both of those are good things. Elegant mechanics add depth – making the game more fun – without adding much complexity – making the game harder to play. And extensible mechanics can do more than the one thing you designed them to do. Which means you get a lot more out of them. It means that the design work you put in now will allow you to design more stuff in the future more easily.
When a mechanic is both reasonably elegant and reasonable extensible, I call it a LOADED mechanic. It’s a mechanic that you can get a lot out of. Loaded here means that has a lot on it, like a fully-loaded pizza. It does mean the mechanic will accidentally kill people if you point it in the wrong direction, like a loaded gun.
And just like pizzas are always better when they are fully-loaded, mechanics are always better when fully-loaded. So after I’ve got a working first draft of a mechanic, I always try to load it up and see how much it can carry. It doesn’t always work. But I do try.
The Problem with that Crappy Armor Table I Made
So, what’s the problem with that crappy armor table I made? Well, frankly, the problem isn’t really with MY table, it’s with WotC’s. When they created their armor table, they decided that there were four basic properties that every suit of armor had. First, armor could be Light, Medium, or Heavy. And that means two things. But only one of those things actually matters. The thing that matters is how it interacts with proficiencies. That is, if armor is Heavy armor, you have to be proficient with Heavy Armors to wear it without penalty. Now, the weight class of the armor also determines whether you add your full Dexterity modifier to your Armor Class, whether you add your Dexterity modifier to your Armor Class up to a maximum of +2, or whether you don’t add your Dexterity modifier at all. But that is also part of the second basic property, the armor’s Armor Class. Simply put, they didn’t want to make you remember general rules for how your Dexterity modifier adds to your Armor Class based on the weight class of your armor and instead just listed it right in the table. That’s nice of them. But it also means that, in theory, I could design a suit of heavy armor that allows a character to add their full Dexterity modifier if I (a) didn’t notice the pattern or (b) didn’t care. And that’s fine. But it means that weight class doesn’t mean anything except what proficiency you need to wear the armor.
Third, some armors require the wearer to have a minimum Strength score to wear that armor without penalty. Which, honestly, seems like a waste. But what do I know? I’m just a blogger. Not a genius game designer like the folks at WotC.
Fourth, some armors impose a penalty on attempts to move around sneakily.
Now, the design is elegant enough. It’s not particularly complicated to understand that, to wear heavy armor, you need proficiency with Heavy Armors, and it’s not complicated to compare your Strength score to the minimum Strength score listed on the table. And to make note that you have Disadvantage on Dexterity (Stealth) checks when wearing certain suits of armor. It would be nice if the character sheet had some specific places to record this s$&%, but you can’t have everything can you. You wouldn’t want to add a couple of extra blanks to the character sheet. That would be so f$&%ing complex. It’s easier just to remember this s$&%. Or, more likely, to forget about it. As many players likely do.
But, where this design really fails is in extensibility. It’s easy enough to create a new suit of armor. I could create a suit of lightweight Heavy Armor, for example, that has no minimum Strength and imposes no penalty on Stealth just by adding a line to the table. But what if I want to add different game effects to armor. I’d have to add a bunch of extra columns to the table! And that’s precisely what I did. Hell, that’s all I did. Apart from coming up with a progression system for armor, that is.
Consider, alternatively, if I wanted to add a new mundane weapon. Say, a mancatcher. That’s a polearm that’s designed to ensnare or restrain someone. I’d just have to invent a keyword like Ensnaring and then write up the specific rule chunk for it to go alongside the rules for Finesse and Versatile and Reach. And then, if I ever wanted to add another weapon that could do the same thing, I could just add it to the table with the Ensnaring keyword.
By the way, I also did exactly THAT for my campaign. It allowed me to take that stupid “Special” keyword off the net. For whatever reason, there are exactly TWO weapons in the PHB that have the “Special” keyword instead of just having keywords that describe their traits. Why? Who the f$&% knows?
The weapon table is much more extensible than the armor table because the properties for the weapons are self-contained rules chunks contained in keywords.
And the solution, after that, is simple. Most of the columns on my table are about imposing Disadvantage on particular skills. I can get rid of all of those columns – INCLUDING STEALTH – by inventing a single trait. Say, “Impeding.” And then, just like the “Versatile” weapon trait, added a parenthetical note to define the effect. And that would look like this:
Impeding (Skill). While wearing this armor, you have disadvantage on ability checks related to the listed skill.
And now the armor table looks a lot cleaner. And all you have to record on the character sheet is the trait. Or you can just star the skill in question. Or whatever. I don’t know. It’s not like the designers figured out how to record Stealth disadvantage anyway. So why should I do any better?
And frankly, the Cuttable and Layered traits can go the same way.
Cuttable. The armor is held together with cords or straps that are easy to cut. As an action, you can use a knife or light slashing weapon to cut the armor off. Once cut, the armor cannot be worn until it is repaired at nominal expense or with smith’s tools or leatherworker’s tools.
Layer (Under/Over). You can simultaneously wear a suit of armor with the Layer (Under) trait and the Layer (Over) trait at the same time. You only benefit from the Armor Class of one of the suits of armor, but you benefit from and suffer from the traits of both types of armor.
And now we’re down to just one column. The swimming thing. See, swimming doesn’t just roll into the Impeding trait. Because swimming is a specific application of the Athletics skill. So it would need its own mechanics. And technically, it would need two traits: one to impose disadvantage on Strength (Athletics) checks related to swimming and one to make swimming completely impossible. Is that really worth it? Do I need that amount of nuance? Frankly, I don’t. It’s enough to have armor that drags you down to the bottom of the briny deep and to allow the Impeding (Athletics) mechanic to cover the rest. After much struggling, I invented the keyword “Leaden” for armor that drags you down to the depths.
Leaden. You cannot swim while wearing this armor and sink in the water. If you have a swimming speed, it is reduced to 0.
Admittedly, by economizing like that, some of the armor becomes a bit undifferentiated. Two of the Rank 0 light armor entries are identical. Either, I can delete one or I can differentiate them some other way. Maybe one is a quilted gambeson that will get waterlogged quickly and drag someone into the depths as surely as a waterlogged blanket wrapped around them might. That might make the armor itself useless as a Layer (Under) option. But, as I mentioned last time, it’s okay to leave some holes and garbage on the table. You never know when it might be useful later. Especially because you can build things out further.
Extending the Extension
Realistically, I COULD stop with that table. Fill in the names, fill in the weights, figure out some f$&%ing wealth and cost progression because WotC’s designers couldn’t be bothered. But the thing about a loaded system – and this trait system IS a loaded system – is that you quickly start to see other possibilities.
First, my final table doesn’t matter much. I mean, it matters for MY campaign. But my campaign is about seafaring and swashbuckling, and swimming and mobility issues are big. But your campaign might not be about seafaring and swashbuckling. Imagine a game that combines D&D action and courtly intrigue. You might have social penalties if you show up to court wearing peasant armor. Or if you’re in a highly lawful setting, wearing heavy armor might draw attention from the law. You could invent traits to describe those things and build your own armor table just the way I’ve built mine. Don’t worry, I will show you my final armor system for my game. You can take it if you want. But, by all means, use your own.
Second, though, my final table is just the tip of the iceberg even in my own campaign. Because I realized something else: the ranking system combined with the Armor Class increases and the various negative traits creates a progression that isn’t much different than a magic item progression. After all, what’s the difference between trading up from Bronze Plate (AC 16) to Steel Plate (AC 17) to Adamantine Plate (AC 18) and trading from Bronze Plate to Bronze Plate +1 to Bronze Plate +2? Mechanically, it’s all the same.
Consider too that, once you have a trait like Impeding (Skill), you could also have a trait like Enhancing (Skill). A suit of blackened leather armor with padding in all of the joints might have a trait like Enhancing (Stealth). And that would be worth bumping up the armor a rank as surely as a +1 to AC is worth bumping up the rank. You could have armor that resists certain types of damage, like red dragon hide that resists fire. Or you could have armor that is vulnerable to certain types of damage. Like bronze armor being particularly vulnerable to lightning damage. And those properties could be mundane, or with the addition of a Magic trait, they could be due to enchantments. And with the addition of an Attunement trait, you can have magic armor that requires attunement to work.
In short, you could roll mundane and magic armor into one system and have an easy way to compare normal armor and magic armor, allow players to buy and sell and craft magic armor, and so on. And if you want to build a crafting system, you also now have a space to stick modifiers for the quality of the work. You could have a Masterwork trait, for example.
And that’s precisely what I did. I created my armor table, but I also created a few extra traits that I could use to layer on magical effects. That way, I could easily create something like a +1 Elven Gambeson that grants advantage on Dexterity (Stealth) checks with the Magic, Exceptional (+1), and Enhances (Stealth) traits. And I would know that armor was roughly equivalent in terms of power to a mundane jerkin made of perfectly normal manta skin.
In the end, this is what my table of commonly available armors looked like:
And if you want to see the list of keywords and the descriptions of the armors, here’s an excerpt from my campaign guide describing armor in detail.
Picture something equally awesome for weapons and for spellcasting focusses.
Cost and Wealth Progression
As for pricing this s$&%? F$&% if I know. I’m still working it out. And you can pretty much just make up whatever the hell you want because D&D has no good, consistent standard or pricing model. I’ll come back to the question when I’ve figured out what the hell to do about it. In the meanwhile, as near as I can tell, Rank 0 equipment should be under 50 gp and should be available as starting equipment. Rank 1 equipment should be available at 5th level or higher. Rank 2 equipment should be available at 11th level or higher. And Rank 3 equipment should be available at 17th level or higher. But, personally, I feel those cutoffs are too high.
I’ll let you know what I figure out.