Efficiency

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Fri Mar 28 09:37:19 CET 1997


[Chris L:]
:There's a problem with this view:  Some names are unique (or at least
:very limited) due to their adjectival tags, not their nouns.  The
:"elven archwizard" can be such a case, especially if the game only
:allows one to exist at any moment.

The feeling I've gotten over the last few days on this is that a given
MUD might want to do both kinds. A specific reference to a specific NPC
can be useful, and fairly effective, but you have to have ways of handling
the NPC going away. Other situations really do call for scanning the
world looking for an NPC matching some criteria. I think it then becomes
a choice of the scenario designer as to whether or not that kind of
search is possible within the rules of their system (and within the
constraints of the server!)

:>I don't have a
:>gut feel for the speed of a 100% in-memory MUD, since mine has a disk
:>based DB with lots of caching, but what I've observed is that DB
:>access is the big bottleneck. 
:
:Ergo: You need a bigger cache.

Well, I ususally kind of cheat here. I have a separate cache for functions,
pre-expanded into their executable forms. This is limited only by the
server's goal of how much RAM it can use for them, and similar things. By
default it is 1000000000 bytes, i.e. unlimited, so functions are always
accessible. I use a 256 entry hash table hashed on the function ID (just
the 4-byte db-id, actually), backed by an LRU list, to find them. My
standard startup for the server also uses a 500K cache for the main db
(settable on the command line). I also often do "nasty" testing (remember
that my system has no memory-protection enabled) with the files in a
RAM disk, so there isn't any real disk I/O.

I decided the other day to actually try to measure what the system could
do, so I updated my "wanderers" and, and wrote a "spell" which would scan
the system and count up all the various kinds of active machines (NPC',s
watchers, etc.). I let loose two batches of 26 wanderers, which are
designed to emulate actual players, and let them trigger lots of monsters.
I was up to 180 total and response was still fine, but then the database
crapped out on me! Waaaaaah! So, on a modern PC, which is about 10 times
faster than this one, I guess I don't have to worry too much, and I'll
quit saying that doing things with extra NPC's is too slow!

:For me every object has a guaranteed unique ObjectID (guaranteed for
:the entire life of that database).  As such inter-object references
:merely become ObjectID's.  Reference speed is of course slower.

Same for me. I have another hash table (with no chaining) backed by an
LRU list, for finding db-id's in the cache.

:My original target was single digit millions of active objects, where
:an active object is defined as any object which has an ongoing event
:stream.  My current revised view is hundreds of thousands of active
:objects on a < US$3,000 machine.
:
:Note: I haven't even attempted anything over a thousand or so (almost
:all duplicate) on my already extremely over committed machine. 

Well, you may as well be ambitious - its more fun that way! With your
heavy threading, a big SMP may well be able to give you your goal. Have
you been able to try your server on any of the big systems you've worked
with in real life?

:The probme here is ensuring that all your character's graphics are
:reasonably unique.  Most 3D games build bodies from stock libraries
:(here a leg, there a leg, throw in an arm or two, a torso, one of
:three colours of hair etc) which leaves the resultant bodies all
:looking very much the same.

Maybe its because I'm more into questing that socializing on MUDs, but
I've always been more concerned with the MUD world than with the MUD
characters. I like the idea of a white speck on the horizon being all
you can see of a big white castle, and it getting more and more detailed
as you get closer to it. If the user doesn't notice it when they need
to, then it's their own fault. The thing is that neither the system nor
the scenario writer has to do anything special to get this effect - it
all comes out of doing general graphics. I've never wanted to go with
canned images - they are too limiting, too hungry for storage space, and
too much effort to get produced (I'm incapable of doing it myself). I'd
be happy with simple polygon graphics, without any textures, as long as
the system can show lots of them smoothly, and can include very distant
objects, such as the above-mentioned castle, and far-horizon scenery.

Creators would have to have some solid-editing capability in order to
be able to produce scenario stuff. The same facility could also be used
to allow editing of characters, and NPC's of all kinds. Players could
detail their faces as much as they want, and the automatic result would
be that recognition would work pretty much as in the real world. If a
player chooses to make their body look identical to the stock goblins,
then they would be pretty much indistinguishable from them. They could
also choose to add some little detail, say a mole or something, so that
their friends could recognize them, but perhaps not their enemies.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA



More information about the mud-dev-archive mailing list