Resets and repops

[Adam Wiggins]

[Chris G:]
> 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

Hmmm.  So that means that any object which has ever been seen by any
player who is currently online is always treated as active?
Seems to me that this rather kills the whole optimization you were
trying to achieve in the first place, if you've got a fair number (50 -100)
of players and a medium sized world.

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

Yes, but the case I was thinking of is more like when you're trying to
find a general thing.  For instance, frequently muds will have mages have
to either seek out spellbooks or new guildmasters/teachers to learn spells
from.  Frequently mages also have locate object or locate person spells,
in which case I _want_ to find something I haven't seen before, ie
cast 'locate person' mage or cast 'locate object' book.
Obviously this isn't a huge concern but it is still there; chances are
you're going to want to be able to do something like this at some point.

> 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

Ugh!  No kidding.  Wow.  Maybe I'm spoiled; our machine has 256 megs of
RAM, and I don't think we've ever broken 20 megs.  (Of course, we're still
low on good, complex areas...the complexity of building for us has
scared of quite a few of our builders...)
When we first started on the project I over-optimized because I thought
it was going to be running on my home computer with 8 megs of RAM (a clunker,
even back then), or at least hiding in a corner on one of the university's
computers in which case we'd want as small of a footprint as possible.
Now we find that most of our stuff is ridiculously small, and in fact
in some cases I wish I had forgone the optimization and gone for a slightly
more striaghtfoward (read: robust) system.

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

I find that with enough RAM, your processor speed is irrelevant.
Most of our mobiles do "burst" processing.  Although they _do_ consider
their options every second, most of the time this consists of "no change,
keep doing what I'm doing."  Only very rarely (in terms of mud cycles)
do they actually _do_ something.  That is, a mobile sees that it's 5pm
(quittin' time!) and executes the section of its script which says hang
up my apron, walk outside, lock the door, find the easiest path to the
nearby tavern, go there, order a meal.  Once that is done, they then spend
a while sitting there eating the meal, which is essentially like doing
nothing.  I guess if we had tons of really complex scripts constantly running,
we could get into trouble, but even then I doubt it.  Since they 'figure
out', in one moment, what they're going to be doing for the next n RL minutes,
and then store it, there's no processor usage inbetween, only lookups.
(Ie, it computes the path to take, stores it, and only checks back into its
stored path to figure out where to go next.)  The other thing that hoses this,
of course, is things changing.  A mobile getting attacked suddenly
tends to cause a lot of processor usage (compared to the normal schedule)
by that mobile; or if they are walking through a series of shifting passages
that causes them to have to recompute their path every step.
However...we're basically counting on most stuff not working like this.
The hobbit groccer just doesn't suck down a lot of processor time, regardless
of what's going on.  The shapeshifting demon traveling through the elemental
plane of illusion may take more time, but we don't desire having a lot of
these sorts of critters.

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

Absoultely agreed.  To me, however, it's not worth doing unless you can
do it perfectly.  Sort of like, it's not worth trying to do Lord of the Rings
as a live-action movie unless you can make it really great.  If it's
only gonna be so-so, this is actually _worse_ than just leaving it as a
piece of literature which the readers can simply envision in their own
minds.  By the same token I wouldn't want to do a mud that looked like
most graphical muds do right now: sort of a pastiche of horrible art stuck
together with some text to try to give substance to the game world.  Better
just leave it to the player's imagination to paint a beautiful picture of
a given location.
The style of play I've always envisioned would be along the lines of
Tomb Raider in viewpoint - that is, a chase camera of your character in a
real 3D environment.  Now you can _totaly_ ditch the RPG abstractions of
hitroll or parry roll; instead you just have the character swing as best
he can, and you actually figure out the parry based on a 3D intersection
of the polygon's in the player's weapon and the polygons in the target's
weapon as she parries.
However, this isn't going to happen anytime soon, so I'll just stick with
text, thank you.  Not to mention I have to do deal with these headaches all
day long (manipulating graphics, that is)...it's so nice to be able to come
home and just do ch->message("You parry the blow.");.

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

Well, it tends to happen more when you get real players.  They think of
things immediately that you would never have.  The first time I remember
this happening was when we brought a couple of our friends on to do some
alphatesting on the combat system.  One of them (being a bit perverted)
saw a hobbit boy and typed, "remove pants boy".  Of course, the boy was naked
anyhow (hadn't gotten around to making gear load on things yet), but he
got a message like, "The little boy slaps your hand away" or "squeals in
outrage" or something.  The guy goes, "Woah!  You guys thought of
_everything_!"  I was just as confused as he was until I remembed that it
checked to see if the character was allowing body contact from non-trusted
characters before it even checked whether he was actually wearing anything.