In
Software Architecture, there's a certain principle known as coupling.
Coupling is basically how much one thing in a system knows about and
depends on another separate thing in that system. A system that is
tightly coupled, i.e.
lots of things in the system depend on lots of other things, is much
harder to modify than a system that is loosely coupled
(a system where most of the things in that system don't depend on
other things to work properly). I'm not going to leave you with just
vaguely worded abstractions, though. I'll give some specific
examples of system.
A
good example of a tightly coupled system is the Third-and-a-half
edition of Dungeons and Dragons. At least, 3.5 is tightly coupled
relative to our example of a loosely coupled system. How do we know
it's tightly coupled? Let's say, we find Attacks of Opportunity (a
favorite target) overly complicated as is, but want to keep the
in-combat punishment mechanic. We then replace the current attack of
opportunity rule with a new rule "Whenever a creature exits the
threatened space of an enemy or attempts to cast a spell next to an
enemy, that enemy deals one attack's worth of damage to that
creature".
Fairly
simple change, right? Except now with this change, we have to also
change or remove combat reflexes, which stated that creatures could
get up to their dexterity modifier in attacks of opportunity a round
(normally a creature was allowed only one, but we've ironed out this
complexity with our houserule). We also have to change Charge, Bull
Rush, Sunder, and a whole heaping amount of other codified actions
that referenced Attacks of Opportunity. This isn't mentioning the
amount of unexpected interactions that will change as a result of
modifying this rule, like giant creatures with massive amounts of
reach no longer beating attackers to death long before they get near,
and it also isn't mentioning all of the other feats and special edge
case rules from outside the core ruleset that depend on attacks of
opportunity remaining exactly as they are. There's a whole bunch of
unexpected changes we have to worry about as a result of changing
this one rule. 3.5 D&D is a tightly coupled system,
at least when changing Attacks of Opportunity.
Note,
I'm picking on one specific rule; one often held up as the shining
example of overcomplexity by detractors. Many other rules in 3.5 D&D
could be modified without having the level of cascading failure
Attacks of Opportunity has. Compared to many other systems, 3.5
appears fairly loosely coupled.
Other tightly coupled systems include, but are not limited to: Burning Wheel, Don't Rest Your Head, D&D 4E, HERO 5E
Other tightly coupled systems include, but are not limited to: Burning Wheel, Don't Rest Your Head, D&D 4E, HERO 5E
My
example for a loosely coupled system would be Moldvay's version of
Basic Dungeons & Dragons, A.K.A. B/X D&D. Why is Moldvay D&D
loosely coupled? Because very few, if any, rules changes result in
the kind of cascading unexpected changes that happen when changing
Attacks of Opportunity in 3.5. We could perform an extreme change,
such as switching from hit points to a wound tracking system as found
in the World of Darkness games, but the only interconnected systems
to hit points are hit dice and damage; since all weapon damage is
assumed to be d6's (when not using the optional variable weapon
damage table) and spells only deal damage or do healing at rates of
d6 or d6+1, the changes are fairly easy to predict and implement.
Hit dice as a system is so tightly interconnected with hit points it would be
very difficult not to think of both when making this change.
If
the most interconnected set of rules is a cluster of three things
(hit dice, hit points, and damage), this is a pretty strong argument
for B/X D&D being loosely coupled.
Other
examples of loosely coupled systems: FUDGE, Wild Talents 2E, Really
any Old-style D&D or retroclone or hack
This
blog is all about advising you, the GM or referee or whatever you
call yourself, in choosing a system and modifying it to suit you and
your group's needs. Loosely coupled systems are easier to do this
with, because modifying any given rule is unlikely to complicate
things or cause problems; at least, modifying that rule won't do so
in an unexpected way. More tightly coupled systems you can still
certainly houserule, but you have to be more cautious when doing so.
I'd recommend using a more loosely coupled system as your base if you
can help it, or judiciously and thoughtfully implementing houserules
if you can't. That's not to say that all your houserules shouldn't
be carefully thought out, just that it's significantly easier to beat
a loosely coupled system into shape with new rules than it is a more
tightly coupled system.
Alright,
is that good? Let me know if there's any confusion.
