I’m sure by now you’ve heard the news. Beyoncé Knowles has given birth to a new edition of Dungeons and Dragons, and the Internets are ablaze. The epic ears of the Wizards of the Coast are now listening to user feedback more than ever before, and in their direction everyone’s hopes and dreams for their favorite game have been launched. The system is rumored to be many things, two of the most common of these being “just another money grab” and “modular”. As my experiences with the R&D team over the past couple years have not included any signs of them being were-packrats who hunt shinies when the moon is full, I can only speculate about the game’s modularity. As it happens, that is the thing that gives me the most hope and the most worry about the upcoming changes to D&D.
Recycle, Reduce, Revenant
When the day-star shines, I am a computer programmer. People of my class are usually pretty familiar with the concept of modularity. Those of us who are not tend to either be unemployed or promoted to management positions. I love writing modular code, and there is a very specific reason why: I am incredibly lazy. I want to write something I can reuse a bunch of times in a bunch of different situations. I want other code I write (or *gasp* code someone else writes!) to be able to use this thing I made without having to modify anything. I hate redoing things for no reason. It’s why I don’t much care for MMO’s.
If I want to stick the same menu at the top of every webpage I write, I’ll write the menu code once and put it in a reusable module. Of course, to do this, you need to make your code ready to use modules, and that means you’re probably going to have to lay down some ground rules. These would include things like knowing what to give the module to make it do things, and knowing what to expect the module to give back when it’s done. It probably also should include some means of keeping the module from accidentally blowing everything up if you get back something completely unexpected from it. It’s kind of like loaning a car to your teenage son, and when he brings it back it’s full of zombies. He is SO GROUNDED.
One major advantage of writing code in this way is that it’s possible (although frequently not easy) to pop off an existing module and put something entirely different in its place. It likely will do similar things, and it may work much better for whatever purpose you had in mind. However, changes to the programs that used the old module might need to get made in order to accommodate the new module’s use. It might expect different things from you, or give you different stuff back. This time, the car might come back full of zombie mermaids. Where the hell does your son go at night?
This Is Not Computer Science 101 What Are You Doing
Nobody’s really quite sure what specific parts of the The Next Version of D&D are going to be modular, but a lot of the above principles will still apply regardless of whether we’re talking about computer programs or game rules.
There’s probably going to be a barebones set of rules for the new game. It may be completely playable all on its own, but I suspect that we’ll start by using a recommended set of starter modules for various game functions. One of the major questions for me in all this is how deep this particular rabbit hole goes. “Modular” could mean literally anything.
Will they have a combat system that uses a battlemat that you can swap out for one that doesn’t?
Will there be 4e style magic, Vancian magic, and a mana point based system?
Another interesting question: does every player follow the same rules, or can individual players choose what style of [your module here] they want to use for their PC?
Whatever it is they let us fiddle with, though — there is a price…..
The Price Of Flexibility
I’ve been on several projects in which people want an incredibly wide range of deliverables. As I have gained XP in coding (and scar tissue), I have learned that building a degree of flexibility into one’s code is a very smart move that tends to save one’s butt.
However, as the complexity of a project grows, so does the amount of time it takes to develop it. I’d love to shoot for the moon and be able to tweak every little thing, but I’d like to play this game before 2050. That’s not the worst part, though.
The other problem with a complex project is the number of things that can go wrong with it — especially if you’re going to be swapping out major portions of functionality. One would think just getting something up and functional is the hard part, but the real work comes in squishing all the little bugs. So often, problems will appear sporadically and be difficult to track. This is one major reason why a nonzero quantity of my hair is now grey.
I absolutely love the concept of The Next D&D letting us swap out things we don’t like and maybe putting stuff we do in. It concerns me that every feature they do this with will have to first be designed to work with every other iteration and combination of other modules, and then it’s time to find all those little bugs. However, as I spend a large part of my day finding and squishing bugs, I know it can be done. I also know that bugs don’t always bring the entire system down, and may just be temporarily annoying. (Why the hell is that text blue?? It’s not supposed to be blue!)
One very encouraging part of all this to me is the fact that we’re probably looking at a nice large open playtest. As the Open Source community is fond of repeating, “given enough eyeballs, all bugs are shallow.” I’m not sure I completely buy into that statement, but I do think having an army of gamers reporting in to WotC to tell them what worked, what didn’t, what was fun and awesome, and what ruined the evening BEFORE the game is launched is an extremely good idea.
Of course, then we start to run into the problem where no matter how flexible a system is, it still can’t satisfy everyone. But that is another story.