Resets and repops

[Adam Wiggins]

[Nathan Y, on not reseting areas until PCs enter]
> :  Scrying
> Again, this would create a local Player controlled bodyless Character
> manifestation, and adhere to the rules.

Well, the tricky part is:

> scry elven archwizard

When there is no such character in the game, since no PC has been by
to reset his area.  I guess this would require a bit of extra code
to quickly search places that _could_ be reset, given the entrance of a PC,
and if so does anything that would be reseting answer to their scry?
No big deal, but I find any time you find yourself implementing a system
that requires 'a bit of extra' code to make a given world-feature work,
probably means it's going to take more bits of extra code elsewhere, and
it's easier to just do it For Real(tm).  Of course if you've got
processor constraints then you have to make some concessions, I suppose.
Just pointing out the inherent difficulties in this sort of thing.

> :  High altitude overview (for those with 3D)
> Occupied Areas get slow refreshes even in unoccupied Rooms. Anything
> covered by line of sight from a Player is operating full speed.

Yeah, agreed.  When I mentioned the item-delay counter we have for
players 'interacting' with objects, viewing the object counts
as interaction.  Meaning if you stand on a hill and watch the sword
stuck in the ground off in the distance, it will never disappear as long
as you keep it in your sight.

> :  Remotely controlled/possessed mobiles.
> Sounds like a Player controlled Character to me.

I agree, although once again this is a gotcha to watch out for.  Hopefully
your object display routine (which updates the "viewed by PC" info) is
set up in such a way that viewing something remotely (through the eyes
of another).  That is...your display_obj routine has to be at the same
abstraction level as the "viewed by player" stuff, or otherwise how
will it know?

> :  'Bots.
> Player controlled.

Again, a gotcha.  What if the bot has no display unit, only reports through
the remote its current position, speed, and bearing, as well as the size
and proximety of nearby objects?  The display_obj routine above never
gets called; instead, it's a complex algorithm to diseminate the info
about local objects into basic information as reflected by the bot's
sensors, which is then pumped through a remote panel (which may or may
not be in the possesion of a player).
So, you'd have to have a pretty robust set of routines to be able to detect
that when a player is mind controlling a mobile 10 miles away, directing
it to a control panel from which it operates a bot located on a spaceship
orbiting the planet, you need to reset the stuff on the ship (since the
robot is viewing/manipulating it, which is sent through a convulted pipeline
to the remote control panel, which the mobile is viewing, which the character
can gain information about).  Far-fetched, yes, but doing it the brute-force
way still works just fine in this situation, whereas you'd have to be pretty
careful to make the above work with a pop-on-view method.

> :Thusly you could have a mobile ctor which creates a baby/child and
> :launches an event stream which slowly "grows" the mobile from infancy
> :to old age and decrepitude, with any deaths along the way just leading
> :to the (semi-) randomly timed creation of new infants to take up the
> :progression.
> 
> Hmmm. Never thought of the grow from an infant model... nah, too costly.
> I'll leave support, if anyone wants to do it with my code, but hardly
> needed for sci-fi.

Probably not really necessary or interesting for _any_ mud, but it does
solve some problems (like making 'resets' essentially unnecessary)
and brings in some interesting elements:

Ollihute the old human shopkeeper is here.

(next week)

A young, sandy-haired man is tending shop here.
You say, "Where's Ollihute?!"
A young, sandy-haired man introduces himself as Brendrik, son of Ollihute.
Brendrik says, "My father passed away this week.."

Just adds another layer of detail to absorb the player.  This isn't terribly
relevant to gameplay, but it certainly brings a sense of humanity to your
mobiles if they are generated like humans instead of like clones on
an assembly line.

> :Handling minor details like closing opened doors, re-locking chests,
> :and resetting traps and the like is similarly handled, with the
> :secondary event either doing it directly ("A sudden strangely cold
> :breeze slams the dtor shut"), to the animation and trekking of a
> :work-horse mobile to the door/trap/whatever to reset it "manually" (cf
> :MirrorWorlds "man in a white lab coat")..
> 
> Ugh. Lets just have it happen when no one is looking. Incidentally, I have

Agreed.

> explained my system to allow a Player to experience an Occurance, the
> results of which are permanent to that Player, and that Player alone,
> haven't I? Things like blowing up a complex or triggering a thermonuclear
> detonation can be coded to become a part of that Player's history, and
> that Area will forever after be a destroyed complex or glass lined crater
> to that Player's Characters... and anyone else that is introduced to the
> aftermath.

Eh...interesting.  You mean by this that they didn't actually blow it up,
just thought they did?  Or that you actually mean to maintain seperate
game-worlds this way?  Either way could get messy, but I do like
the idea, in the first case:

The ugly troll massacres Bob on the neck.
Bob slumps to the ground, spouting blood!
You scream, "Agggh!  Bob!!!"
The ugly troll turns toward you with a grin.
> flee

Later, you see:

Bob, who you thought was dead, is standing here.

It might be that it's Bob's specter/ghost returned from the grave, or that
he didn't actually die, or maybe that it's his son and just looks similar.
Hmmm.  Interesting to store this sort of data along with the memory;
we do this to a certain extent right now, in that we store your relationship
with that person and the last state you saw them in, thus if someone shows
up with their beard shaved off you might not recognize them (this is handy
for wanted people, especially with the 'disguise' skill), and also you can
do the 'recall' command which has the dual affect of showing you what
you know about them and how you feel about them, plus shuffling their
memory node to the top of your list to make you less likely to forget them
due to memory-cleaning:

> recall bob
You think back to your memories of Bob the male human.
He sure is a good friend.

Suppose it wouldn't be too hard to toss in a clause for death or POW, ie:

You will miss him, and cherish his memory.  R.I.P.
or
You wonder whatever happened to your good old pal Bob...

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

> :You get into coding a full economy -- a thing rife with positive and
> :negative feedback loops (cf Palace's early economy mishaps and happy
> :accidents).  Its something I don't think I'd even attempt.  What I
> :think would be easier, and provide a LOT more fun, is to implement
> :independant economies with their own internal methods of production
> :and consumption which are not dependant on other economies.
> 
> dangerous.

What are you guys, a bunch of pussies?  All this high talk of
advanced programming and no one even wants to tackle an economy.
Next you're gonna tell me that writing mob AI that makes NPCs indistinguishable
from players is too hard. :)

> I like this! Consistant laws! (Which means it can be implemented in
> Physmud++!!)

I like constant laws because they're...uh...constant.  Tends to make
it rather easy to say, "It's _always_ like this" as oposed to, "Well,
it's like this, except for these seven special cases..."

> Love your item names. Hmmm. A possibility: enchant an opponent's sword to
> destroy it? Or inconvenience the enemy, at the least. Or would it drain
> from you by proximity? That could be cool... an overenchanted sword that
> must feed off of magical prey constantly, or drain its owner dry. I can
> just see it.... here, unicorn, unicorn, unicorn.... my sword really wants
> to make your acquaintance!

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.

> :The nice thing about this sort of system is that it becomes self
> :balancing.  Opportunities for mana consumption exceed mana production,
> :so the system always runs starved (try to run it fat and you get
> :positive feedback).  While there can be synergy between the mana
> :economy and other economies, even positive and negative feedback
> :(again cf Palace and the guns and coins), you don't get the direct
> :causal dependancies where the stonemason can't build castles because
> :the lumberyard has no wood because the robbers robbed the bank so the
> :woodsman can't get paid for the trees he cut, and the elves can't sell
> :their silks anymore anyway (no money), and now pro0hibit all tree
> :cutting.
> 
> I have to say, you guys create universes every bit as cool as my own. And
> killer bases for those universes. No wonder the newsgroups have decayed so
> much... we keep sapping out the talent.

Ha...I still read and post to r.g.m.*, mostly because they have pretty
low traffic anyways (especially when you cut out the spam with a nice
killfile or a quick next-message-key finger), but I do get tired of the
"Are you out of your MIND?!?!?" and "Why would anyone want to play any
mud that isn't exactly like all the ones that are existing right now?
You ought to quit wasting your time and just code yet another druid
class, or maybe C00L ANS1 C0L0RZ."