Re: Was: Mob Experience: Mob Experience

From: Jeremy Elson (jelson@blaze.cs.jhu.edu)
Date: 04/24/96


> > Well, I just wanted to make a note/recommendation... Make a formula for 
> > EVERY class, so different classes can be set up to require different 
> > ammounts of XP for the levels... I think the current XP tables reflect 
> > this.. and if they don't they should *grin*

> > Well, risking getting flamed I only have this comment:
> > 
> > Making things easier, doesnt guarantee they become better ...

> That's true.  However, making something complex usually means it gets 
> worse.  Simplify, simplify.  The easier you make something, the less 
> versatile and ultimately useful it will be.  You have to try to make it 
> as easy as you can while still keeping all of its functionality.
> 
> This is usually a personal decision.  Do you think it's worth sacrificing 
> some control over user's levels for making it hundreds of times easier to 
> add new levels, change ease-of-level-transition, and so on.  I happen to 
> think it's worth it.  Also makes it a little easier on the users.

I guess I should clarify the formula-based experience thing.  When I said
I wanted to change to "formula-based" I probably should have said
"function-based" instead.  Meaning, instead of having a huge array full of
experience and title tables, there will instead be a function call that
requests the exp or title of a particular class and level.

That function can work however you want it to work.  If you want to stay
with table-based experience, you could write the function this way:

get_exp(int class, int level)
{
  switch(class) {
  case CLASS_WARRIOR:
     switch (level) {
     case 1: return 500;
     case 2: return 1000;
     case 3: return 2000;
     case 4: return 4000;
     case 5: return 1000000;
     }
  }

....etc, etc.

This system sacrifices *0* flexibility (there is *nothing* you can't do with
that function that you can do with an array.)  Quite the contrary, it *adds*
flexibility, because you can make it formula-based if you want, or
partially formula-based and partially table-based, or whatever.

The reason I'm switching over to using a function is so that implementors can
simply add new levels by changing the LVL_xxx constants -- the experience
"tables" will automatically be filled in with sane values by some sort of
formula in the get_exp function, instead of simply crashing the MUD as it
would with the array.


I think that a lot of people don't realize that most of the changes I make
to Circle these days are only to make the code base more flexible and to
reduce interdependencies in the code for the purpose of making changes 
easier.  For example, a couple of patchlevels back (9, I think), I changed
the way minimum spell levels are assigned to the various classes.  It used
to be that if you added 10 additional classes, suddenly every single spello()
line in spell_parser.c had to be changed to accept 10 more arguments!!!  Even
if the new classes were not spell-casting classes!!  This was a totally dumb
system because the unsuspecting imp who "simply" wants to add a new class
suddenly has a hell of a lot of typing to do.  And he'll probably either write
to me or to this mailing list asking for help -- which is something that
*nobody* feels like dealing with.

So, based on the posts I see on this list and the FAQ's that constantly
threaten to overflow my mailbox, I change the code so that common tasks
are easier.  The entire "class.c" file is another example: an attempt to
make it easier to change the code by concentrating everything in the same
place that has to be changed together.  The 'configure' script (which I
think is mega-cool :-) ) is, admittedly, also nothing but a way to prevent
my e-mailbox from getting cluttered: I used to constantly be flooded with
people asking the same questions over and over again (e.g.: When I compile
it says socket, bzero, and other functions are undefined.  When I compile
it says crypt() is undefined.  When I compile it says that xxxx header file
is missing.  When I compile it says that there is no prototype for yyyy.).
Now that configure takes care of all of that stuff automatically (-lsocket,
-lnsl, NOCRYPT, etc.), those people don't write to me any more.


Okay, I'm rambling, so I'll stop.  But hopefully this has given you a better
idea as to why I do certain things in certain ways.

Regards,
Jeremy



This archive was generated by hypermail 2b30 : 12/18/00 PST