Reply to thread

Message: <blockquote data-quote="Crazy Jerome" data-source="post: 5986136" data-attributes="member: 54877">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.</blockquote>

Verification