[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