[MUD-Dev] Re: let's call it a spellcraft

[Jon Leonard]

On Fri, Sep 25, 1998 at 10:59:44AM -0500, Michael.Willey at abnamro.com wrote:
>      ____________________Reply Separator____________________
>      Subject:  [MUD-Dev] Re: let's call it a spellcraft
>      Author:   mud-dev at kanga.nu (James Wilson <jwilson at rochester.rr.com>)
>      Date:          9/24/98 11:32 PM
> 
> ---------------------------------
> >Perhaps the following is obvious to you, but I had to
> >do a bit of math to see how different these are:
> >
> >if the cost of moving from p pips to p+1 pips is about
> >e^p experience points, then if you define p (x) :=
> >attribute pips when experience is x you can get a good
> >simulation of the derivative with p' (x) = e^(-x) so
> >p (x) = C - e^(-x) (where C is some constant). As
> >x->infinity, e^(-x)->0, so p(x)->C. Thus p(x) is
> >asymptotic to the horizontal line C.
> >
> >Translation: difficulty proportional to e^(current
> >stat) implies that there is an upper bound on the stat
> >value.

The math doesn't work out that way.  Just because p'(x) has limit 0
as x goes to infinity doesn't mean that p(x) has a constant limit.
The alternative is a function that grows without bound, albiet slowly.
Log is of course such a function.  (For any C, log of e^(c+1) is larger...)

> Hmm.  I'm not seeing that, probably because we're not
> tracking your x value.  Instead of an experience cost,
> skill advancement is based on use so that the base chance
> to advance from p to p+1 is 1 in e^p per use, modified
> as appropriate.  There are no experience points, so x
> is worked out of the equation.  There doesn't appear to
> be an upper bound here, although advancement becomes
> incredibly slow very quickly and eventually also bumps
> up against maxint.

This has a very similar average behaviour.  It grows without bound,
assuming infinite prescision arithmatic.  It just takes a very long time
to get reasonably large.

> However, if I'm missing something in the math here,
> please feel free to thump me over the head with it before
> I implement this.

The math isn't my main reason for following up, though.  The more
interesting question this raises is what kind of function should relate
experience to skill level.  I'm dubious about e^x as a level->experience
function.  It seems to me that it would result in most players quickly
reaching a competent level, and there only being 3 or 4 levels achieved
beyond that.  My memory of a game with the easier 2^x being frustrating
because later levels were too far apart agrees...  At some point a token
advancement will require more work than you've put in so far, total.

I haven't done any experimentation, but I was planning on using a system
where experience to the 2/3 power yields the skill (mixed with a skill
web, but that's an orthogonal issue).  What function do people think is
appropriate?  Some mix of taking time to develop skills, and being
continually rewarding to players (support players who like to see numbers
go up, even if it doesn't mean much), possibly with some sort of cap is
best, I think.

The implementation for nearly any such function can be fairly simple.
Store the current skill level, the current experience, and cache the
experience needed for the next skill level.  Recalculate it when the
skill goes up, and if it's been un-cached for some reason.  You may
need to store skill as something longer than a 32-bit integer, of course.

Jon Leonard