Resets and repops

[Nathan Yospe]

On Sat, 22 Mar 1997, Chris Gray wrote:

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

I've had situations of both... sending a probe to deliver a message to
Mike the mechanic, for example, is simple... if you happen to know where
Mike's garage is. Of course, there is no guarantee that Mike will be at
work. On the other hand, sending a probe to search the entire galaxy for
Mike... well, you better not expect instant results, and you might have
the probe, going by description alone as it is, making a mistake
(actually, I don't think I would ever allow such a mechanism. Local
searches, yes, but galaxy wide?) On the other hand.. the two are totally
different concepts codewise. Linking to a specific Character, whatever the
type, is simple, if you are familiar with the Character. Linking with an
unknown Character, on the other hand, is a matter of searching through
your storage mechanism, whatever it is. Then again, I've never used a disk
based system. Sleeping threads, and all associated memory, tend to get
swapped out by most flavors of UNIX very quickly. There never seemed much
point, overall, in disk based storage in the face of that. Especially with
such a heavy duty memory manager to worry about... swapping out chunks of
that would be a nightmare, if done by hand.

:[Just scribbles note about this down - added to stack of such.]
:
:Here's a general question for you guys who advise doing everything for
:"real": Do you have evidence that doing this is going to be practical
:in a large-ish MUD in the next few years? 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. ChrisL, what have you observed on this? 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. Do any of you convert DB-refs
:to pointers on the fly when objects are loaded? That would require keeping
:track of where all the pointers are, and also would require conditional
:code of some kind whenever a pointer is followed. In my testing, I've
:found that I can run 50-100 NPC's moving every couple of seconds, on this
:roughly 15 MIP machine. The world complexities we've been talking about
:would seem to require 100's or 1000's of active NPC's. 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?

Well, I've gotten the impression that your system was pretty slow, but...
for myself, I dunno about the others... notice how much effort I put into
making the sucker sleep when not needed. This is not a requirement,
particularly... I'm maybe 90% native code, at a guess, and 100% in
memory... but I like the room to expand, and the scripted (well, semi
scripted... the pointer tabled code segment may grow in time...)

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

You mentioned before slow hardware, I think? Though, having seen many LP
drivers, disk and in memory, drag their creeping little feet and consume
mass resources... and they are supposedly bytecode interpreters... well, I
can't see a scripted language doing too well... I'm biased, though. I've
gone through a great deal of trouble trying to construct a highly flexible
native code base.

::Amusing.  Could even toss player notes onto a given memory, thus:
::
::> note silke this asshole tried to steal my hat!
::
::And later...
::Silke has arrived from the north.
::> ponder
::> recall Silke
::You seem to remember thinking, 'This asshole tried to steal my hat!'
::> growl
::
::Hmmm.	Dang, that could be useful in real life:
::
::A tall man approaches you.
::A tall man says, "Adam!  How's it going?  Been a long time!"
::> say uhh....
::> recall man
::You think really hard, trying to remember anything you can about the tall man.
::Hmmm, you think his name might be "Phil."
::> ' how's it going phil
::Phil says, "Uh, it's 'Bill'."
::> doh
::> name phil bill
::You will now call him 'Bill'.
:
:This is actually rather telling. This *would* be very useful in real life.
:Politicians have assistants whose job is to provide this information -
:prepping the big-wig on whoever they are going to meet, just before the
:meeting. Such things as tidbits about whatever the big-wig learned on
:previous meetings, what was discussed, etc. For normal folks, however,
:we have to rely on our fallible memories. 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?

*grin* From time to time, I tell myself that, once I finish Physmud++,
with all of its PD design characteristics, flexibility, and text based
language management, not to mention having already cracked the threaded
server/router/world and freeze/unfreeze threads, and hopefully eventually
the disk swapping system (I suspect world structures are gonna undergo a
compression and direct binary dump, with periodic tape backups of the
whole mess. Still working out error protection.) GURU (my graphical
project) should be a breeze when I get back to it.

::Yeah, that's what's cool about a system like this - players, being as
::clever as they are, will come up with tricks along these lines that you never
::thought of when programming it, but still working perfectly within the system
::(because it is all consistant).  Not to mention I love concepts which
::are neither good nor bad...they just _are_.  What you want to make of
::them is up to you as the player.
:
:I *really* like it when unexpected, but consistent, things happen. Too
:bad that in my simple system, it has only sorta happened once. Sniff!

I've had it happen a few times... not as many as I'd hoped, but then I've
never had Singularity 2 up more than two hours so far.


   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu