Simplistic or Complete (and why we can't have both)

[Pickles JG]

I think simplistic is the wrong term to use. Ideally the game would be simple while still having the maximum power to "describe" the world.
That description could be as a simulation, to generate stories or to create good "gaming" decision points. A sophisticated system would do a lot of the work for you while remaining simple to use.

I am not holding my breath.

Hmm maybe you are contrasting simplistic (roll >10 & you succeed in what you are trying) with comprehensive (a rule (& several modifiers) for everything).

 

[Pickles JG]

There are many dividing points in-and-amongst gamers of all editions: linear campaigns versus open campaigns; dynamic campaigns versus static campaigns; defined fluff versus mutable fluff; characters builds versus organic growth; and on and on and on and on and on. We could have a whole thread devoted to coming up with everything that diveds gamer "A" from gamer "B"!

I thought about doing such a thread a while ago as there seemed to be a bunch of issues that people had very strong opinions on & could not both exist at the same game table. What I, & others, saw as the irreconcilable divides.

For all the wizards flim flam about unification if you are playing 5e with different modules on either side of one of these divides then you are not unified other than to the WOTC sales department.

 

[thecasualoblivion]

I'm not really buying simple core modular complexity, as in my opinion it favors those who want it simple. Complexity ends up clunky thanks to being bolted on after the fact, as opposed to a robust core skeleton built to manage complexity and carry it well.

 

[Crazy Jerome]

Abstractions are not simple, and are thus not diametrically opposed to complexity. Models tend towards more or less simplicity or complexity. Rather, abstractions are a way of handling complexity in a (game) model to make it manageable. The opposite of "abstract" is "concrete"--that is, specific and detailed.

If we want optional modules that we can easily swap in and out while making most everything else work, then the complexity of the model is less important than "couplings"--that is, the spots where one module interacts with another. Using abstractions tends to reduce complexity, but in a system with swappable modules, it becomes also important to use the correct abstractions, and to cut them off at well-defined and consistent points. D&D has always been pretty nifty at reducing complexity with its abstractions, but not so hot at the other aspects.

This is important to the concern of this topic because a well-defined, consistent, properly formulated abstraction is capable of being successfully expressed at different levels of concreteness by modules.

For an easy example, let's assume after some thought and experiment that we learn that the proper abstraction for weapons is that they do a range of damage, have a few key types (e.g. slash, bash, etc.), and a few other things along those lines. We might find that for purposes of varying the concreteness in modules, we need to distinguish between short sword, long sword, and great sword. However, we discover we don't care about distinctions, always, between short sword and scimitar (or long sword and scimitar--it's not important here). Yet, some modules do get very specific, and do care.

The obvious answer, then, is that things outside the module specify either short sword or scimitar (the specifics), and it is up to those that want a simpler module to know that if they don't care about scimitars, that's a flavor thing that rolls up into the short sword stats in their weapon module. For simplicity of use and presentation, that might even be correct. But technically what we are really saying is that the link from character to weapon is something like "short sword (general)" or "short sword (scimitar)". That is, there is a level of concreteness that only some of the weapon modules care about, and this is specified for them to use where needed and ignore otherwise. The important thing here is that even if that link is collapsed into the specifics for ease of use by the players, the designers need to understand what is really being said. (Nor are these the only solutions. You could say that "shortsword" is always sufficient because you have some other cultural or training or similar component elsewhere on the character sheet that qualifies. But that's getting exotic.)

You get the same effect when talking about what hit points represent, the scope of classes and races, what the level of a spell means, etc. It's ok to collapse such distinctions for ease of use--if all the modular options you want to support can handle the collapse. However, it's not ok for someone writing (or changing) the system to collapse the distinctions, because they must keep the full range of modules in mind. And of course, sometimes you'll have a module that is simply too costly--passing around the information for it is to unwieldly compared to all the other modules that go in that spot. At that point, the correct answer is to widen the abstraction (pull back to encompass more) or split it into multiple abstractions. It's a symptom of a bad coupling problem. The blending of race and class in Basic is probably a good example.

 

[P1NBACK]

The blending of race and class in Basic is probably a good example.

Do you care to unpack this? How is this a good example?

 

[Jacob Marley]

I'm not really buying simple core modular complexity, as in my opinion it favors those who want it simple. Complexity ends up clunky thanks to being bolted on after the fact, as opposed to a robust core skeleton built to manage complexity and carry it well.

A "simple" core skeleton is not necessarily opposed to a "robust" core skeleton. For instance, I can take this -- which is a very simple mathematical core -- and build a very robust game that looks like this.

 

[Crazy Jerome]

Do you care to unpack this? How is this a good example?

Just in case, maybe "good example" wasn't the best abbreviated term there. I meant it is a good example of bad coupling, where the better answer was to split them.

As to why, it's not open and shut, but in general I would say that you can judge it by the results. Race and class mixed is an abstraction that you can't readily scale. Taking strictly, it means that adding specifics is clunky. If you want to have elven fighters, dwarven clerics, and halfling wizards, you have to add those. And in the naming conventions, you don't even have good things to call them that fit the pattern. Furthermore, the combined abstraction implies that all demi-humans are alike while humans are varied. Finally, related to the previous point, the combined abstraction is inconsistent in the level at which it abstracts. It's supposed to be a combined abstraction of race and class, but it really tells us little about human society.

All of those points have valid counter-arguments. In Basic, they are pretty strong. Because Basic mainly doesn't care about any of that stuff, but does care very much about keeping the "pick something and get on with it" at the forefront. You might say something like, "Class is an abstraction. Race is an abstraction. We combine them, because in Basic we don't care about the distinctions. It's just a stock to get started with."

That brings up what I was saying about collapsing. It's often ok to collapse. It's not ok to lose sight of what has been collapsed when a designers changes the rules. A DM or player at a table using Basic can say, legitmately, "Hey, we are using this highly abstract race/class combination. If we want a dwarven cleric, we'll just use a cleric, file off a few serial numbers, have her sport a beard, and call it good. The important thing is to take the stock and run with it." Or any number of similar tweaks.

OTOH, if a designer takes that attitude (whether official or someone else attempting clean design), then it's off. Because now you aren't just supporting "dwarven cleric." You are supporting every combo. It should become obvious immediately that the list is going to get very unwieldly. In other words, said designer is now changing the assumptions that led to the collapse in the first place. So it needs to be split out again. Meanwhile, your coupling problems have compounded astronomically. Whereas "wizards" or "elves" getting to use item or spell X was fine, with only "wizards" using item or spell Y in Basic, now that we've got halfing wizards and human fighter/wizards and tomorrow gnome and goblin wizards. Turns out that "wizard" is a label that has taken on increased importance when linking outside the race and class abstractions. Your new abstractions needs to recognize that fact.

If not, what you get are a host of overly complicated rules about swapping this feature for that racial ability, or this spell for access to that item, etc. And these rules are not easy to modify. Total them all up. Then split race and class out again, and you find that you've eliminated the need for 80% to 90% of them.

Finally, note that this "proper" coupling is always a concept that comes with a great big implied "If": If you are going to support a bunch of races taking a bunch of classes, you need to split the race and class abstraction. If you are going to add a skill system, you need to think about what are broad skills that anyone could theoretically do versus what are class abilities retained in the classes themselves, and then abstract the class and skill boundaries appropriately. If you are going to have a lot more "magic" types than arcane and divine, how do you set up the boundaries, and what does this imply about the magic abstractions?

All of these decisions have costs. In Basic, the cost of the race/class split could be too high for what you get in return. In AD&D, the cost of not splitting is too high for what this would do to the complexity of the rule set. For any given piece of complexity, you've always got the options of abstract it, drop the feature, shove it off to the side (for only it's biggest fans to handle), accept it as necessary, or try to finesse it. The best course for any given piece is necessarily affected by the choices made for the pieces around it.

That is probably more unpacking than you wanted, but I'll let it stand now that I've bothered to say it.

 

[Crazy Jerome]

Also in passing, 4E is very abstract. It's a highly abstract version of a lot of the same ground that 3E covers (albeit with notable missing pieces). What makes it seem less abstract is the long list of powers and items, and the fact that the abstractions are somewhat different than what went before.

The 4E "separate power list for every class" is another example of bad abstactions, specifically bad coupling between "class" and "power". The class abstraction in 4E is pretty decent, from the consideration of its design intent. The boundaries are fairly clear and consistent, even if not always to everyone's liking. (Some people don't like, for example, the restricted scope of fighters and rangers. But these are certainly consistent with the rest of the 4E design.)

But the powers, ye gods! I opened the PHB 1, saw that there were a separate list of powers for each class, and immediately said, "coupling error". A power is this thing that a character can do. Either it really is restricted to a class, in which case it's a class ability. Or it isn't, in which case it belongs on list arranged some other way (by keywords or power source or something). Even if you grant "separate power list for every class" as a "collapse" of the boundaries for ease of use, it doesn't fly given the scope of 4E's powers.

I'm fairly certain that all of the problems in the 3E skill system are a result of totally incoherent abstraction, though explaining my reasons there might be more difficult than anyone would care to read. Plus, with something that incoherent, you have to read between the lines on intent, not always easy or reliable.

 

[Remathilis]

I would say that, though the divide outlined in the OP is certainly present, since the OP lists both 3E and 4E as being on the complete, all encompassing side of the scale, and these are the two main sides in the edition wars (with props given to the OSR crowd), there must be a different divide. I would posit it as the Simulationists (3E) and the Gamists (4E).

4e is a relatively complete game, if not as simulationist as 3e. 4e rules are just as complex as 3e's due to the nature of powers and the dozens of powers it entails. Still, it gives very clear rules to handle nearly all situations (including a neat "make stuff up" table, divided up by level). In fact, it is probably the only Edition so far to have strong, concrete rules for hazard interaction and social interactions in the form of Skill Challenges.

Long and short of it, if it comes up in game, 4e has a rule for it.

 

[Li Shenron]

D&D Next has promised some ability to slide scale the particular simplicity/complexity of the rules, but at the heart of the game some things can't be dialed around

Which things can't be dialed around at all?

The whole purpose of 5e (from design POV, not the business POV) is exactly to be a dial-able game in many different aspects. Which aspects do you think can never be made dial-able?

and thus the decision must be made: do we as a community want a D&D that's simple, light, and abstract or one that's complete, heavier, and more iron-clad?

...

In the end, is it better to have rules that are more complete-but-complex (3e) or simplistic-but-abstract (basic)?

If you asked me 10 years ago when I had plenty of time to play and run a game of D&D, I would have answered that I wanted it complex.

Today I am still struggling to even setup a whole group for playtesting 5e, and I would answer that I want it simple.

I refuse to make a decision. No way is better than the other, if not only 2 people have different strokes but also I have different strokes at different times! If one RPG is complex and the other is simple, you just can't say the first is better or viceversa, at best you can say it's better for you and currently.

[not to mention that I have different complexity preferences for different aspects of the game!! compared to my previous 3ed games, I'd like to introduce more weapon and armor differentiations, but OTOH I'd also like to simplify combat actions]