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

[Travis Casey]

I've been gone for a bit, first due to vacation, then due to a bout
with the flu.  Skill systems are a favorite topic of mine, though, so
I'm going to quickly hit some points on some of the posts.  Since I've
plowed through all the messages fairly quickly, my apologies if I'm
restating something someone else already said.

<EdNote: Welcome back!>

Also, to everyone waiting for the LPC command parser, I should be
sending it out tomorrow.  Thanks for your patience!

Friday, December 22, 2000, 6:15:19 AM, Gabriel <gjsfaun at hotmail.com> wrote:
> John Vanderbeck Wrote:

[snip some comments about use-based advancement systems]

> I don't really have a better system to provide. In the MUD I've been
> developing, I'm using a time based system - all characters get so
> many points over time to increase skills or attributes (no levels or
> classes).  Bonus points may be awarded through special events or
> quests (for especially good role-play for example, an administrator
> can award the player a few extra points). It doesn't matter if the
> character is logged in or not, so one of the main complaints may be
> that people create a character, then go off and play another game
> for a year, then come back and are not perceived to have "earned"
> the points they have accumilated for advancement. One of the reasons
> I'm interrested in other systems :).

> Some of the bonus' to the time-based system include not having to
> put in and update protective code, resources preserved by not having
> characters continuously logged in without a player behind the
> persona.

You could easily combine the two; have a time-based system to provide
a "baseline" for advancement, and have "extra" points given on the
basis of using skills.  To keep spamming of skills from having too
much of an effect, you could make the "extra" for usage be fairly
small compared to the baseline, and/or use a nonlinear scale for it.

To give a quick, illustrative example: suppose that you've determined
that an "average" player plays your mud about an hour a day, and does
one skill use every two minutes during that time.  The highest-usage
players, however, play some ten hours a day, and do one skill use
every thirty seconds.

Abbreviating "skill uses/day" to "su/d", we have:

  average:   30 su/d
  high:    1200 su/d

The ratio of su/d, then, is 40:1 for high:average.  The question,
then, is how much faster do you want the high-usage folks to advance
than the low-usage?  Let's say that you think three times as fast
would be OK.

Now, our formula is going to be:

  advancement points = x * log (su/d) + baseline

Just to pull a number out of the air, we'll give our average player
100 advancement points.  So, we have:

  100 = x * log (30) + baseline
  300 = x * log (1200) + baseline

Cranking some numbers, that gives us:

  x = 124.839
  baseline = -84.403

(both rounded to three decimal places).

We can automatically give everyone one free skill usage per day, so as
not to cause problems (since log(0) does not exist).  That would mean
that someone who's offline would actually lose skill points.  That may
or may not be desirable.  If it's not, the balance point is at 4.743,
so you could give everyone 5 "free" skill uses a day (which would give
a non-playing player about 3 skill points a day).

Someone who plays "normally" for two hours a day, then, will get 60
skill uses/day, for about 140 advancement points... noticeably faster
than average.

Of course, this isn't perfect (no system ever will be), but by making
returns diminish rapidly, it goes towards making spamming be more
effort than it's worth.  And, of course, it could be combined with
other measures to protect against skill spamming.

--
       |\      _,,,---,,_    Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)   


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