[MUD-Dev] Moving away from the level based system

[Ron Moore]

On Sat, 23 Dec 2000 Corey Crawford wrote:

>Ok, so this would accomplish an objective of having a players skills
>go "stale" if they don't use them. It also curtails repetitive
>spamming of a skill, but I can envision people spamming their skills
>right before a fight to make sure their skill level is maxed.
>
>Correct me if I'm wrong, but it sounds to me like you have basically
>two ratings for a skill.. knowledge and actual skill level. According
>to you, the knowledge of the skill determines the "pool" size, I would
>call it the skill pool. Keeping the skill pool full allows you to use
>the full potential of your knowledge of the skill.

I was commenting earlier from a player's point of view on the
Dragonrealms system as I played it around 3-4 years ago.  It may have
changed significantly since then and I may be misstating the specific
implementation.  So treat my comments as an attempt at reverse
engineering with a few of my own mods;).  You'd have to tweak your
algorithms for how fast you want levels to increase and what weights you
want to add for little used skills, etc. so I won't use any actual
numbers.

1. Player uses skill/ spell A at modified level X while attempting a
task with modified level Y.  Chance of success is determined on a curve
with X = Y being 50%.  If X > Y, the task is relatively mundane and
cannot be learned from.  If X <= Y and player succeeds, i.e. unexpected
success, they gain a kernel of knowledge for their skill pools.

2. Players have a global pool and skill pools.  The global pool capacity
(total amount of new information the player can retain) is determined by
the player's intelligence.  Each skill has its own learning pool (how
much skill specific information can be retained) whose capacity is
relative to skill_level.  When a kernel is gained, check both pools.  If
either pool is full the information is lost, else add a kernel to both
pools.

3. Pools are drained one kernel at a time at a rate determined by the
player's wisdom (rate of comprehension).  At draining time, deduct one
kernel from each skill containing any, as well as a corresponding kernel
from the global pool.

4. To increase skill_level, the player has to acquire a sufficient
number of kernels.  The total number of kernels needed to advance a
level is a function of skill level and should increase geometrically,
perhaps on the order of the 1.5 power, to make each successive level
increase more difficult.  You don't actually have to store how many
kernels are collected so far, just track skill level to four decimal
places or so and increment the skill appropriately as each kernel is
added (skill = skill + 1/ kernels_to_level).

5. Atrophy could be a straight function of skill_level over time played,
modified by aging, infirmities, etc.

6. There could also be gains in skill heirarchies, depending how deeply
you want to carry out these functions.  i.e. Improving knife skill could
have some carryover effect on combat skill, one-handed weapons,
backstab, butchery...  For that matter, you could modify a kernel system
to work for attributes or mobile skills, as well.

>But this is still a problem when it comes to trade skills.. how do you
>prevent ANY type of trade skills (arrow fletching, cooking, whatever)
>from being macroed and/or spammed? The above system doesn't help that
>situation at all and may even promote it (since you have to be doing
>hard stuff to gain exp, then why not have your guy trying to do the
>hardest thing he knows how to do for 2-3 hours?). One of my thoughts
>was to make sure the process was a bit more complex than a simple
>command (a few at least) but these could still be macroed, and
>probably WOULD promote macroing because people are lazy ;)
>
>An example of this would be making a hammer.. you need wood (one
>process) then you would need iron (another process) then you'd have to
>shape the wood (another) and then shape/cure the iron/steel (another)
>and then finally put it all together (the last process). But this
>could be refined to the point where you get tons of wood
>(spammed/macroed) and tons of iron (spammed/macroed) then sat in a
>dark corner and spammed 'shape wood', 'shape iron', 'put it all
>together'.. and end up with 20 hammers.

Spamming a specific skill floods the skill pool and you stop gaining
kernels.  If you try to spam between several different skills, the
global pool fills up and you can't add any future knowledge until the
next drain.  The weakness in the DR system at the time was that the
global pool, if they used one, was not restrictive enough so players
just bounced around spamming different skills as each filled up.

The real work is to weight the uncommonly used skills (coder) and assign
task ratings (builder) responsibly.

Ron

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev