Resets and repops

[claw at null.net]

On 22/03/97 at 12:20 PM, cg at ami-cg.GraySage.Edmonton.AB.CA (Chris
Gray) said: >But isn't it a bit unrealistic to be able to do that? I
was thinking >about this stuff this morning, and it occurs to me that
one of the >things I would want to do is to be careful about
identification. In >my system all database entries have a unique ID. I
would use that as >a handle for things. You can put a name for it into
your private >symbol table. Then, you can refer to it, unambiguously,
by that name. >So, the 'scry' for me, would end up not using 'elven
archwizard', but >some made-up name by which this player refers to the
NPC. Such a name >can only be made when you have some other
unambiguous way of >referencing the archwizard, such as by being in
the same room as him >and doing the naming. So, having this link to
the elven archwizard >can be considered enough to keep that NPC
active. If you don't have >some kind of unambiguous reference like
that, then the above command >seems to me to require some sort of scan
of the entire world, in >order to find something that meets that
description. Now, you may >want to allow that, but for most uses, I
think an unambiguous >reference would be preferable.

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.

Consider the scenario I posted a while ago concerning the Orcs, the
breeder Orcs, the variant production of breeder/worker/fighter/noble
Orcs by the breeders dependant on population density, mortality rate,
and invasion status, and more importantly, the competition by the
noble Orcs to become King Orc (with the guarantee that there is only
ever one KO).

Thusly: The "King Orc" as a tag always uniquely identifies a single
Orc, or is unable to indentify any Orc (ie the KO is recently killed
and the nobles are fighting for kingship).  Given even a loosely
educated player, they will know of the existance of a "King Orc", even
if they have never met the chap.  As such, doing a "scry king orc" or
similar becomes a reasonable command.  They know he exists, they don't
know where, but they hope they can locate him on the basis of his
uniqueness.

The problem this presents to a MUD server is whether or not you
maintain a global namespace for such tags (especially such fluid
tags), and if not, how you proceed with the search.  (What if the KO
is located in a hidden/unknowable location?)  

>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.

>ChrisL, what have you observed on this?

Cache size is critical.  My attempt in general is to make the cache
large enough that I can keep the entire working set of the MUD at any
instant in memory -- where working set is defined as comprised of any
object which has been accessed within the last 20 seconds or so (it
gets better when you can start hitting multiple minutes).

Yup, its memory expensive -- but its cheaper than everything in-RAM. 
Yup, it looks like I will be going back to a three level cache.  

>If a system is 100% in-memory, then links from one entity to another
>can be just pointers, but with a disk-based system that's harder. 

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.

This is one of the reasons there was so much interest on the list last
year in persistant stores, and specifically Texas with its Pointer
Swizzling, and Object Store (commercial, rather similar in principle
to Texas).  It is an area I intend to revisit.  I still have a very
ugly nagging feeling that all the work I've been putting into the DB
layer lately (adding native transactions and rollbacks) will be wasted
once I find or write a decent persistant store and see how much better
a solution that is.

>Do
>any of you convert DB-refs to pointers on the fly when objects are
>loaded? 

Not quite.  I have a layer that sits immediately over the DB cache and
handles all the tracking of the requested objects, interested party
lists etc.  That layer attempts to short-circuit references between
objects which are already in cache, but frankly, the current short
circuit is more expensive than the lookup would be.

>The world complexities we've been talking about would seem to require
>100's or 1000's of active NPC's. 

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.  

>Also, the code being discussed is a
>lot more complex than what I'm currently running. Is my system just
>hopelessly slow, or is there something wrong with my assumptions
>here?

>I guess I can barely imaging this kind of thing working with a 100%
>in-memory system, running 100% native code (i.e. very little
>scripting or whatever you want to call it). 

That's exactly what MOO and almost all Tiny-* MUDs do, and some of
them have databases measuring up in the scores of Megs.  (Have a look
at the last LambdaMOO dump some time)

>Mine is 0% true in-memory
>and 100% scripting (fairly efficient scripting language, however), so
>maybe this is why I'm slow. Comments?

Without running a profiler over the code, I can't really comment. 
However I would immediately suspect your cache management along with
any blocking you do on disk IO.

>:Amusing.  Could even toss player notes onto a given memory, thus: :
>:> note silke this asshole tried to steal my hat!
...
>...Is it
>realistic to provide this kind of aid in the game? Handy, yes. This
>is one of the reasons why I would like to go to a 100% 3D graphic
>game. You can then avoid a lot of the stuff that is needed in text
>games and simply leave things like noticing, remembering, etc. up to
>the human player. You don't have to come up with text descriptions
>dependent on the local conditions -
>you just display the world according to those local conditions, and
>the visual acuity of the player if you want, and let the player sort
>it all out. Much more realistic. Is it playable, though?

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.

cf Meridian59 and its name tag haloes for all the characters.  Its a
*LOT* cheaper than having 500 unique bodies.

>I *really* like it when unexpected, but consistent, things happen. Too
>bad that in my simple system, it has only sorta happened once. Sniff!

Yeah, but this is a funny world we've got here, where ideas and
potential often count for more than what's actually done with them. 
Set up a system where your players *can* do some neat things, and lord
knows they may well just stick to endlessly killing fidos.  Set up the
system so tht nothing is flexible, and some user will come along and
figure out how to program it...

Them's the breaks.

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...