[MUD-Dev] Re: Levels versus Skills, who uses them and when.
matt at ender.com
Thu Jan 14 20:36:54 New Zealand Daylight Time 1999
On Wed, 13 Jan 1999, Raph Koster wrote:
> Quest XP is a classic tactic. XP for merely visiting rooms (or for
> visiting specific rooms), which we always termed "explore XP" is a nice
> tactic too, until the rooms become known. [And yes, right here someone
> is going to say they implemented remembering every room visited, or
> every room remembering who visited it, and don't have that problem, and
> once again I'll shudder at the data storage their mud entails. Am I the
> only one who is paranoid about memory usage?]
We actually decided that the plain-jane experience gathering was pretty
bad, too, and decided we wanted exploration points as well. Our method was
to add a field to a room and to an area with an exploration value, for
starters. More difficult or tricky areas are more points for exploration,
with a value specific to a room overriding an area value (and the whole
default being 1). We have about 6k rooms, but we're growing fast. Still,
I did it in one fell swoop and allocated 8k per character (8192 bytes).
I used macros that directly reference memory to directly flip a given
bit positioned X bits from the start of that 8192 bytes (65536 bits).
This makes it unconscionably fast, and that's the end of the storage
requirements. I certainly don't bother compressing that in memory, but
when you start saving it all to disk, thousands of players worth of
8k can add up -- so you can link against zlib and compress that. Since
the vast, vast majority is big chunks of 0's (at least on my mud so far),
you get excellent compression. If you were truly memory paranoid, you
could throw in a few more pointers and a "size" field, and compress
the memory for rooms from areas outside their area, in memory. But that's
pretty paranoid indeed, to try to save ~7k/character.
Incidentally, we also use this for a great deal of permanent memory
features, allowing our builders to (as part of builder defined mob/obj
progs) set, clear, and check bits from another 8k (they get those bits
matching their vnums), which is "remembered" between sessions, they can
use for various purposes. Quest results, whether a player has assaulted
a certain race of mobiles, perhaps -- whatever strikes their fancy.
All in all, it makes for a memory efficient method, and also works
incredibly quickly (cpu usage of the macros being essentially nil).
More information about the MUD-Dev