A question I get asked a lot: why are the XML files so complicated?

why do I have to choose a

compendium, then load any add-ons, and then load a homebrew compendium on top of that if I
want to?

The answer is classes.

Most of the “things” in the files are discreet. A feat is a single item wrapped in <feat> tags.
Same for spells, backgrounds, items, monsters, etc. When a new feat gets published in, say,
Unearthed Arcana, I could make a file that contains only that feat and you could install it on top
of your compendium and call it a day. I could give you a file that’s just the feats from the
Player’s Handbook and another that’s just the feats from Unearthed Arcana and a third that’s
just the (currently hypothetical) feats from the published adventures and you could mix and
match as you choose. In fact, if there were no classes, I could do it exactly the way I want to,
and just present you a folder full of stuff named “PlayersHandbook.xml”, “VolosGuide.xml”,
“UnearthedArcana.xml”, etc., and you could make exactly the compendium you want.

A class, however, is different. Inside the <class> tags for a Fighter, you’ve got all the core rules
for a fighter from the PHB. You’ve also got the Battlemaster, the Purple Dragon Knight from
SCAG, the samurai from Unearthed Arcana, and the Gunslinger from the DM’s Guild. All of
these have to co-exist inside a single <class> tag labeled “fighter”.

Suddenly, it matters very much what order you load things.

If each file contained only the options that appeared in its source, somebody who loaded the
Player’s Handbook first and then the homebrew file would have only the gunslinger, while
somebody who loaded the same two files in the opposite order would have only the champion,
eldritch knight, and battlemaster. You can’t add-on subclasses; there’s only one fighter <class>.

Races are similar. The solution there was easy: wood elf and high elf are separate <race>
entries entirely. So why not do that with classes? I could. There could be a <class> called
“Fighter (Eldritch Knight)” and another called “Fighter (Cavalier)” and a third called “Fighter
(Gunslinger)”. But your character only ever gets one race, and they get it before you start
playing. Fighters get their archetype at third level. In other words, you’d have to have decided
in advance what archetype you’ll be taking at third level, or else I’d have to have a generic
“Fighter” class that you use for two levels and then delete.

There are other problems. There are a few dozen subraces. There are more than a hundred
subclasses, and that’s not counting any homebrew stuff. Worse, you’d get presented with that
giant list of subclasses not once when you make a character but every time you level up.

The app would let you multiclass gunslinger with battlemaster. That’s not good.

I’d also have to try to maintain each and every one more or less separately. Imagine errata
comes out that changes the wording of Action Surge. I’d rather update that once than fifteen
times, because sooner or later there are going to be errors and different subclasses of the same
class will have different base class features.

Right now, the way it works in my spreadsheets which build the XML is that most “things” exist
as a single row. (With complicated “things” like monsters, that single row might be built to
include a compilation of several rows from other sheets, but still…) Each row gets labeled with
a source; I can tell from that source whether that “thing” is a core item, an Unearthed Arcana
item, a modern Item, an Adventures item, or a homebrew item, and include or exclude it from
the appropriate compendium.

Classes are built differently. Each class feature is its own row, with its own source. My macros
can build a core fighter <class> that contains only the core features, skipping the Unearthed
Arcana and modern and homebrew stuff. All of the various versions of the fighter that appear in
the various files are built from the same rows in the spreadsheet, in other words. There’s just
one row for Action Surge, and it gets used over and over as appropriate.

If subclasses were their own “thing” — if I could write <subclass> and your new features when
you level up were a combination of whatever your <class> gave you and whatever your
<subclass> gave you — then all of this could be avoided. And I could very, very easily make a
separate file for each book, present them to you in one big folder, and you could load the ones
you wanted in whatever order you wanted to, with nothing overwriting anything else unless it
appeared in two places (like the Goliath). Moreover, I could use “optional class features” for
actual optional class features only, like Fighting Style, and the whole thing would be a lot
cleaner.

But subclasses are not their own “thing”.

The question, then, is how to balance choice against complexity. As I saw it, there were a few
different strata of what people might want. People who play by the strictest rules only want the
core stuff, so there’s core. People who want Unearthed Arcana options but aren’t playing a
modern campaign would probably just as soon not see Modern options, so that’s two more.

Homebrew adds another level of complexity. People who use it probably only want the stuff
they’re using. With new classes, races, items, etc., that’s easy — they can all be add-ons, and
you can choose what you want. With subclasses, well, we’re back to overwrite city. The answer
I came up with for now is an add-on (three add-ons, actually — Homebrew_Core,
Homebrew_Modern, and Homebrew_UA) that overwrite only the classes from a default
compendium. That means you get all of the homebrew subclasses I’ve added whether you
want them or not, but them’s the breaks. Again, I could make them separate classes (so
“Fighter” would include whatever your compendium had, and then “Fighter (Gunslinger)” would
include just the gunslinger. In fact, that’s how they used to be. What it meant in practice was
that the homebrew content never got updated and was rapidly orphaned to the island of misfit
XML. And so, I compromised on homebrew add-on class compendia.

This made it easy to maintain (when I run my macro, it rebuilds the homebrew compendia at the
same time that it rebuilds the main compendia). It’s a bit more complex and certainly a bit more
confusing — now it once again matters what order you import the files, and you have to reimport
the homebrew compendium every time you reimport your main compendium, so it’s a bit of a
hassle. But relatively few people use any of the homebrew content whatsoever, so I decided it
was OK to impose that complexity and hassle. If you want homebrew subclasses, it’s a bit of a
pain, but if you just want the main stuff, it’s relatively simple.

The other issue is content bloat. Thanks to the ability to search the compendium when adding
stuff to your character, this is basically a non-issue now, but once upon a time I didn’t want to
make everybody scroll through nine billion pages of items just because a couple people wanted
trade goods. My default was a streamlined list for everybody, and then add-ons for the people
who wanted more stuff. Now that compendium search exists, I think it’s better to include a more
complete list rather than a more navigable list, and so lots of the add-ons are getting folded
back into the main compendia. I’ll probably do more of this, with an eye towards making add-on
files only stuff that not everybody is going to allow in their campaigns (like futuristic items or
NPC races).

So, now that everybody is sound asleep, let me end by providing a TL;DR summary of the
actual file import process:

1. Start by choosing a compendium — Core, Unearthed Arcana, or Modern. Load it. Replace
duplicates if asked.
2. If you are most people, stop here. Congratulations! You’re done.
3. Need ray guns, muskets, trade goods, horse barding? Load other add-on files as you see
fit.
4. Need homebrew or third party stuff that’s not subclasses of existing classes? Check those
folders. Load whatever you want in whatever order you want.
5. Need homebrew subclasses for core classes? Load the homebrew compendium that
matches the compendium you loaded in Step 1. If you loaded Core.xml, choose
Homebrew_Core.xml. If you loaded CorePlusUnearthedArcana.xml, choose
Homebrew_UA.xml. If you loaded CorePlusUAWithModern.xml, load
Homebrew_Modern.xml. Replace duplicates!
6. If you loaded a file in step 5, always make #5 the last step. Always do it whenever you load
a new compendium.

It’s not ideal, I’ll grant you that. And if Lion’s Den ever gives us subclasses as a separate thing,
I’ll be on it like nobody’s business.

And of course, as always, if you run into weirdness or just need help, do feel free to ask me!
You can always reach me via email at dave dot rich at gmail dot com, or on Twitter
@FightClubXML.