Modularity
Modularity is the hot word right now, what with the D&D Next announcement. I’ll be interested in what that actually means for D&D next as the word has pretty specific meaning to me.
The difference between a modular system and a customizable system is the interface. With a modular system you can swap out two similar modules without changing anything else in the system because they present the same interface. A customizable system is any system where it’s easy to see where to modify to change it to meet your needs. All modular systems are customizable, but not vice versa.
Let’s use a concrete example: we want to use Mutants and Mastermind-ish combat with D&D 3.5. This is an awesome idea, Mutants and Masterminds has some pretty sweet stuff for combat. Unfortunately Mutants and Masterminds requires a damage saving throw which is nowhere in the D&D classes, so we have to make it up. There are guidelines we can use—maybe something related to fortitude modified by HP—but it’s up for us to figure out. That’s not a modular system: to swap out to damage saves we had to make changes elsewhere in the system.
Even if Mutants and Masterminds had provided a conversion from D&D classes to damage saves it still wouldn’t be modular. One side of the system (in this case, the Mutants and Masterminds combat rules) needs to have inside knowledge of the other system to make it work. If the conversion from D&D to Mutants and Masterminds relies on Fortitude save as a base but I’m using a set of alternate classes that have Old School saves (like v. Poison, v. Magic) I stil have work to do.
That’s why I’d classify d20 as customizable but not modular. A modular design is one where each module can act with limited knowledge of another.
A modular approach would be one where there’s a defined pattern to what character classes must have to be part of the modular system and that information is general enough to be consumed by other systems. Maybe each class has an all-purpose HP stat, where HP can be consumed in different ways by different subsystems. Instead of HP being a specific stat used by a specific subsystem, HP is now a general number which indicates endurance to damage and can be used by any number of subsystems.
The key difference here is that each subsystem is designed with what it consumes and creates explicitly decided as part of the system design.
The reason d20 isn’t modular is because there aren’t clear lines between the subsystems. What one designer thinks of as part of the class system another designer thinks is part of the combat system. That’s exactly what’s going on the in example above: one designer thinks they can change the saves without modifying anything else, but another designer relies on those saves in a different way.
A truly modular system would be one where the class subsystem says “HP is a measure of how much damage you can take” but no more than that. It can’t say that you lose HP as you take damage because taking damage is part of the combat subsystem, which may be entirely different. Some combat systems might use HP as a number you decrease as you take damage, some might use it as a save you make, some might make it the point at which you switch to a different mode of play (there’s no death).
The advantage here isn’t that it makes any one example work better, it’s that it makes designers better able to work together. Any module that adheres to the module interfaces can be swapped in or out seamlessly.
This kind of thing works very well in software design, it’s a key point in object-oriented programming in particular. That’s where my definition of “interface” comes from, more or less. The idea is that pieces of the program can declare what common uses they are good for, therefore allowing them to be used anywhere you need a thing that does that. You might have one storage scheme that uses one huge file and one that uses a database, but they can present the same interface so you can swap between them. They both say they’re good for storing things, they support that interface, so you can use them both interchangeably for that use.
I’m not entirely sure this is practical in a game. I can’t think of a game that’s modular in that sense and scale that currently exists. There are lots of base systems that are customizable (d20, FATE, &etc.), and some even have semi-modular components. Semi-modular would be something like d20 feats: you can make your own feats easily and they just fall into the feat space. But they’re not truly modular because they can (and often do) depend on outside systems. Some feats immediately become useless once you don’t have a grid for combat, for example. It’s not that there can’t be feats that only function when another module is in place, it’s that they should be clearly modularized too.
So maybe this is something that the D&D Next design team has tackled. From their character descriptions it sounds like it, at least to a degree. Monte has mentioned one person playing a character with just a few things written down while another has a full set of feats and powers, presumably this means that there are modules that take the core character definition and use it as input to a more specific system, say feats or whatever. I’ll be interested to see how this works out for the D&D design team, it;s a big problem but they seem to have some good plans of attack.
The Mutants & Masterminds combat problem reminds me of switching from DirectX to OpenGL. Modules with different interfaces. Work must be done.
Battle mat vs. no battle mat is really thorny, like you point out with feats – although I’ve heard them say they’re embracing previous editions, my prediction is they’ll still require a battle mat – leaving Moldvay’s Basic D&D under-served.
Exactly! Even with similar root concepts, you have to adapt to the interface, so DirectX and OpenGL aren’t modular. Of course you can customize your app to either one, but you can’t just swap them out. I hope to see D&D actually be as modular as it sounds, but I’m skeptical.