[MUD-Dev] Playing catch-up with levels

cruise cruise at casual-tempest.net
Tue Apr 27 11:11:04 CEST 2004

John Buehler wrote:

> I used to be in the "use it or lose it" camp.  I even have a
> primitive skill system simulator lying around somewhere that
> includes an atrophy mechanism.  There are a few problems with such
> systems.

>   1. The automatic rebalancing of skills is defined by the
>   software, not the player.  If I do nothing but practice short
>   sword, all other skills will fall by the wayside.  But the
>   player might well have wanted to sacrifice the magical skills
>   that they had accumulated. Just as likely is the possibility
>   that the player wanted to switch from longsword to short sword.
>   And that leads into the second problem.

>   2. A player is obligated to keep using skills that they want
>   available, even if they're not interested in actively using
>   them.  A solution to this is "offline activities" where when the
>   player is away, the character makes sure that it practices
>   certain skills.  That's the same problem as setting up a set of
>   skills that the player wants to retain, and the level at which
>   they want to retain them.

Maybe I'm misunderstanding you, but I don't see this as a
problem. It's logical, surely, to expect a character to not be as
skilled at something they don't do very often? Naturally, for skills
which are occasional use skills by their nature, the decay rate is
tweaked appropriately.  Likewise, if I do nothing but practice
shortsword, again it's reasonable to assume everything else is
weaker. Naturally, this incrase and decrease is not linear - lower
levels increase quicker, higher levels degrade quicker - so it's
easy to pick up a skill to an adequate level and keep it there, but
to be absolutely king of the hill requires time and focus, as you'd

>   3. Not all skills are suited to "use it or lose it" approaches.
>   Skills that do not involve a physical object are going to have
>   to be dealt with in some way, and that will break the
>   "non-existent interface" model.  Players will have to understand
>   that the skill exists so that they can tell their character to
>   do it.  Of course, the game could just ensure that every skill
>   involves an object unique to that skill.  So ivory wands would
>   only cast one type of spell.  Ebony another, etc.

Not necessarily - simply moving increases the "hiking" skill (by
tiny amounts), so that movement slowly becomes more efficient. There
is no command or physical object to interact with, just an action
that improves an underlying skill. The skill won't be mentioned
anywhere. But those players who do a lot of exploring (a typical
"ranger" character), will be able to move much further for longer.

> "Use it or lose it" goes a certain distance and solves certain
> problems.  It's a good approach.  But I believe that there are
> other ways of solving the problems of a large skill system than
> "use it or lose it".  It may well be that "use it or lose it"
> could be a first-cut presentation of what I'm talking about, with
> other ways of presenting the more extensive capabilities.

I'm sure there are many, many solutions to such a problem. Why this
attracts me is because it so intuitive. It's how we expect things to
work from real-life.

> By the way, unless all skills have the same cost of learning,
> there is an element of "classness" to all skill systems.  My own
> skill systems tend to make magical skills more costly than mundane
> ones.  That's an element of "classness".

But are your magic skills proportionally more useful? Otherwise, as
someone else (sorry) mentioned before, no one will bother to learn
them once they work out that sword-fighting is quicker and easier to

I certainly do have skills with varying levels of difficulty - but
the harder skills are "better" (defined depending on the skill). So
you can chose to quickly master basic skills, or perhaps spend a bit
more time and end up with superior abilities.

[ cruise / casual-tempest.net / transference.org ]
   "quantam sufficit"
MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the mud-dev-archive mailing list