🚀 go-pugleaf

In article <1992Nov12.004009.1@wharton.upenn.edu> millerl@wharton.upenn.edu writes:
>In article <BxL2xB.HJt@knot.ccs.queensu.ca>, dalamb@qucis.queensu.ca (David Lamb) writes:
>> ... make the system modular (I'm actually trying to apply
>> some ideas from software engineering, where modularity of systems is
>> important for flexibility and ease of change).
>
>How do you pick the modules to use? Seems to me that determines a lot of the
>flavor of the rpg right there. For instance, the following picks tell a lot
>about what the system is trying to do.
>
>character background
>character quantization
>the roll (or not)
>simple skill use
>opposed skills
>interpersonal conflict: combat; repartee; and mystic duels
>mystic abilities: magic; miracles; psychic powers.
>super abilities
>foe quantization
>foe lists
>adventure design hints
>

Gosh, how I wished I had more time to participate in this discussion!
Anyway, here's my (admittedly rather theoretical) response.

I think what you have here is what we call a "functional
decomposition": basically, divide things up more-or-less according to
the "functions" one needs to perform.  Now, there's nothing fundamentally
wrong with that.  However, I was thinking of applying ideas from
"information hiding decomposition" : identify design decisions likely
to change, and "hide" those decisions in a module;  carefully
design an "interface" to the module that "preserves information
hiding" - in this case, that lets you write other, separate, sections
of the game manuals without having to depend on details "hidden" in
the module.

Character creation is already like that, I think.  C.c. is a process
that comes up with a character sheet - prose, drawings, and game
statistics describing the character.  The rest of the game manual
shouldn't need to talk about how this stuff got onto the character
sheet (whether by "random rolls" or by "building with points" or by
"writing down whatever you please").

To take a much tinier example: I wanted to make sure that I could
change my mind about the combat damage scheme, while retaining some
sort of coordination between "amount of damage caused" and "amount of
damaged healed".  So weapons all had a "damage number" and the Healing
skill (and medical technology) all had "healing numbers".  The game
presumed both used the same basic mechanism for deciding what those
numbers meant.  In one version, you indexed into a table that told you
what dice to roll to damage (or heal).  Were I to double all the
numbers in the table, or switch from dice rolling to absolute
calculation (e.g. "hit points are damage number times 5"), neither the
description of weapons nor the description of healing skills would
need to change.

To take another example: The prose describing each skill says what the
skill means, and under what circumstance one uses it.  It speaks of
skill resolution in abstract terms (success, failure, exceptional/
critical success, exceptional/ critical failure).  A separate section
on general mechanics for skill resolution describes how you tell if
something succeeded or failed or "criticaled". (for all skills).
Furthermore, the description of a skill *DOES NOT* discuss whether
it's a specialization of some more general skill.  That's reserved for
a separate appendix, table, skill web chart, or whatever.  So one
separates the question of "how does one use the `Sword'" skill from
whether it defaults to some generic Dexterity or Weapon Use or
Slashing Weapon Use skill.

I hope this provokes some thought.