[MUD-Dev] Introduction Systems

John W Pierce jwp at r2systems.com
Mon Mar 12 01:53:04 CET 2001


Ben Chambers:

> File storage is done using ASCII.

Why? I know of no compelling technical reason for doing that. To use the
example given:

>    ID            Linked Name
>    001            Ben
>    002            Kwon
>    003            John
>    004            Mark
>    005            Sue

If IDs are sequential numbers, then an easy way to store
"introductions" is as a bit map. If Mark knows Kwon and Sue, but not
Ben and John, then Mark's "Known characters" bit map starts off as

	001011...

That is, Mark knows the characters whose IDs are 2, 4 (himself) and 5,
and does not know the characters whose IDs are 1 and 3. A lookup table
maps those IDs to names when it's necessary to do so - there's no
reason to store that map in more than one place.

If there are 2048 in-game characters, then you need 2048 bits per
character to specify all possible "known character" relationships;
that's half a megabyte for "known character storage", which doesn't
seem excessive. I also can't think of any compelling reason to stuff
that information in each "character file" (assuming that "character
file" means maintaining "persistent" information about individual
characters in individual files for each character). It's easier to
store that information separately and have functions that care ask
runtime global storage whether Ben knows Sue. Or stuff an individual
character's bitmap into their runtime character object when that's
generated, which is probably theoretically preferable in some computer
science sense, but keeping it globally gives better performance and
generally works better in practice. For one thing, if you need to
change the size of the bit map because the 2049th character was
created, it's a lot easier to do that with a global store than with
individual bit maps in the character objects.

-- John W Pierce, R2 Systems, San Diego
   jwp at r2systems.com


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



More information about the mud-dev-archive mailing list