[MUD-Dev] UI Issues: Anti-scripting techniques

[Travis Casey]

Brandon J. Rickman <ashes at pc4.zennet.com> wrote:
>On Sun, 5 Oct 1997, "Travis Casey" <efindel at polaris.net> wrote:
>>Well, one question is in how you divide up skills.  For example, one
>>could simply have a "cooking" skill, or you could divide it up into
>>"short-order cook", "baking", "barbecueing", "haute cuisine", etc.  Thus,
>
>If you talk to someone who has taken a baking class they will tell you
>that baking is an art, cooking is a science.
>
>This was just a one-off reply, but I started thinking about the idea of
>familiarity skills as a refinement to more general skills.  (This is, of
>course, nothing new, but I gotta keep that signal level up.)  Instead
>of having a million skills in bar-b-que, short-order, campfire, &c, these
>could be tracked as "familiarities" instead of skills.  This distinction
>makes more sense if you restrict the possible values of the familiarities,
>like bar-b-que could range from 0 to 7.  Byte-conscious programmers love
>this kind of thing.  The point is to make the general skills more adaptable
>without complicating the skill web.  A master chef with no campfire
>familiarity might have problems keeping ash out of the scrambled eggs,
>but they would taste better than expected.

Familiarities have been used in quite a few paper games, although paper
games usually implement them as a binary distinction -- you're either
familiar with X or you're not.  In this instance, all they really are
is a form of subskill that's ranked differently from "normal" skills.

>This is useful for hard-to-fathom skills like music.  Having a high
>music skill doesn't make one a virtuoso on all instruments.  But a
>good musician can pick up an instrument they have never played and
>quickly make some musical sounds with it.  Because of this fiddling, their
>familiarity with the instrument would go from 0 to 1.

This can also be done via related skills, skill trees, or other similar
mechanisms.

>And, of course, this gives some granularity to combat skills.  In
>Stonekeep (an essentially single player CRPG from 95(?)) this added some
>hidden refinement to combat as your character developed a familiarity
>"skill" with each different weapon used.  Even if your combat skills
>didn't increase you would fight more effectively with the same weapon
>after some time.
>
>Old hat?

Somewhat.  There are a number of paper RPGs with the concept, going back
as far as the late '70's, if I recall correctly.  However, I haven't
seen any muds using it (I'm sure there's one or two out there, though,
so let's not start an "X mud already has that" thread, ok?), so it doesn't
seem to be a common concept in muds yet.

Personally, I prefer to use skill trees, etc. for muds -- the main reason
that familiarities are used in paper RPGs is so there are fewer numbers to
keep track of.  Computers, however, are *very* good at keeping track of
numbers, so that's not a problem on a mud... especially since numbers can
be hidden from the players if we want.
--
      |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
     |,4-  ) )-,_..;\ (  `'-'        rec.games.design FAQ:
    '---''(_/--'  `-'\_)      http://www.io.com/~efindel/design.html