[MUD-Dev] Introduction Systems

[Travis Casey]

Sunday, March 11, 2001, 8:43:57 PM, Ben Chambers
<bjchambers at phoenixdsl.com> wrote:
>> From: "Ben Chambers" <bjchambers at phoenixdsl.com>

>>> of the ID number.  I mean, each file for each player storing each
>>> players name assosciated with their id number could become VERY
>>> large, VERY fast. Assuming you have 3 digit ID numbers, and have
>>> 999 people playing, with each name having an average length of 9
>>> letters, you then have to store 11,976,012 bytes of information.
>>> I think that 12

>> I imagine that you are exagerating in this, since the lowest binary
>> number capable of holding 999 is 11 bits with a max value of 1024,
>> and depending on encoding, standard ascii being 8 bits per char,
>> unicode I beleive uses 32 bits, 9*8 is 72bits giving a total of 83
>> for id and name, 32*9 is 288bits for a total of 299

> File storage is done using ASCII.

I think you mean "I'm assuming that file storage would be done using
ASCII."  And that's much of the problem here -- you're making
worst-case assumptions.  If you *don't* store the index number in
ASCII, then you could easily shave off a byte for each index entry,
*and* give yourself room for growth with 64K possible index values
instead of 1000.

> That means you have an 8 bit per character.

ASCII is only 7 bits per character, not 8.  Thus, you're assuming
ASCII encoded with one character per byte.  (Which, I will admit, is
the most common way to do it, but it's not the *only* way.)

You're also assuming that no compression techniques are being used.
ASCII has 128 different characters, but 33 of those are control
characters, 32 are non-alphanumerics, and 26 are uppercase versions of
characters that already exist in the encoding.  You can basically rule
out the use of the 33 control characters, which allows you to use
those to encode common combinations of characters, or for other
special purposes to compress data.

> 999 would require 24 bits or 3 bytes.  Then you have to store for
> each of those numbers, a name, which with an average length of 4
> would take 4 bytes.  That is twelve bytes for each character.  Then
> you have to record that for each character.  I.E.

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

> Now, Ben's character file, stores that for him.  He would have a
> character file that is 33 bytes.  Then Kwon has a 33 byte file.
> John has a 33 byte file, Mark... etc.  For a total right there, of
> .165 K.  But this goes exponentially.  For an average length of
> name, N, and players P.  The storage required is P * ( P * (N + 3))
> bytes.

You're assuming here that every player knows every other player.  This
is unlikely on a mud of any real size.

> Now, for 999 characters, with average name length 6, you would have
> a required storage of 999 * 999 * 9 or: 8.98 MB.  With the 10 in my
> earlier example, it would have been 999 * 999 * 13, or 12.9 MB.
> This is of course for total character files, but it s till is too
> much.

This is far from the only way to store this data -- other ways may
cost less space, and may even work better for a given method of
working things.

For example, let's say that characters introduce themselves to each
other.  The name you introduce yourself to someone with is recorded as
the name they know you by.  In a setup like this, chances are that any
given character will have no more than three or four names they're
known by.  Thus, instead of storing the name, you could keep an "alias
list" for each character.  Everyone who knows them, then, has their ID
number stored, plus another number which indicates which of their
aliases they know that person by.

You could, say, use a 24-bit number for character ID (giving about
16.7 million character IDs), and an 8-bit number for the index into
the list of that character's aliases (allowing a character to have up
to 256 aliases, which is more than anyone's likely to actually want).

This gives 4 bytes per "association", plus the storage required for
the list of names.  Assuming that each player has an average of, say,
three aliases of 10 characters each, and assuming you're using
byte-encoded ASCIIZ strings for the list, that gives a total storage
usage of:

  P * K * 4 + P * 33 bytes

where P is the number of characters on the mud, and K is the average
number of characters that each knows.  To use your 999 and 999 example
above, the total storage use would then be 4,024,971 bytes.  This
method, however, scales much more nicely than what you were proposing.
At P=10,000 and K=5,000, your method would require about 500 MB, while
the method I've just given would require only 202 MB.

--
       |\      _,,,---,,_    Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)   


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