> > 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