Resets and repops

Nathan Yospe yospe at hawaii.edu
Sat Mar 22 10:26:12 CET 1997


On Fri, 21 Mar 1997, Adam Wiggins wrote:

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

Scry as in "look for"?

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

Not really. Remember, I built this system base up, so... scry:
Search in an outwardly extending pattern for anything matching the name
"archmage"... at each possible result, generate a proxy (which triggers as
a Player, bringing the Area in question up to date and to full activity.)
The proxy is then traced outward to track down the new location of the
Archmage. If the Archmage has been destroyed (a very rare event) the
scryer is notified that a trace of an archmage was found, but the trail
has gone cold, and the scrying continues outward. The Area in question
goes back to sleep.

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

Viewing a location, in any form, is "present" as far as my system is
concerned. Even in an indirect form, which usually involves a Transmitter
object.

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

Actually, Object display is static. The issue here is the "player added"
routine for the Location. Whenever a Player requests info from an Area, in
any form, it takes the form of adding the Player, by proxy at the least,
to the Location, for whatever duration, then extracting the Player later.
If I wanted to keep everything alive, I could put a null Player container
in every room in the game, or even define the Location default with player
present flags... but, I think of this as equivalent to a haunted house.
You ever run a really good haunted house? The secret is, have everything
ready for the people coming through, and give them some background noises,
but don't have the scenes all running when they are empty. This just tires
out your actors and gains nothing. Same with my MUD. Its all about how
convinced the Players are, after all. And Shrodingers can could have
remained undefined until opening time, instead of trying to calculate
every milisecond whether the isotope decayed and released the poison. The
end result is the same to the outside observer.

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

Bot contains a Transmitter (counts as an Active object) which relays info
to a reciever object of some kind. As I said before,
Item::display(Character& viewer) has nothing to do with the activity of
the Location. The threads were woken up and updated by the entry of the
Bot, which, in the Doorway::transmit(Physical& thing) routine, the only
way to get something in or out of a Room or other Location, (yes, goto or
transfer or teleport or whatever creates a temp Doorway object) verified
that it contained an Active component.

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

On the other hand, there is no problem whatsoever on a pop-on-presense
method. *grin* seriously, its just a matter of moving a lot of stuff, like
relocation, a little higher up the conceptual heirarchy.

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

Ah.

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

*smirk* I did write an area that had a certain species being generated
like clones on an assembly line. _Very_ like clones... that's exactly what
they were. I guess its nice having things like that... things are a little
too turbid in my world to notice, though. There are few stores, and many,
many battlefields.

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

Er.. the second case. Seperate game worlds. Yes, a tad messy, but no one
is going to design a complex Area if its gonna get turned into a crater by
the first hotshot Character to visit it... unless it can also get turned
into a crater by the second, third, and so forth. This lets a Player feel
like he's accomplished a permanent thing (until he gets to be a builder of
high enough skill to catch on) without making the builder feel like his
beautiful Area has been trashed.

: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. That hardly sounds complicated, just drop it onto my memory base..

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

Sounds like you have a similar memory base to my own...

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

Though I dislike that "male human" bit. I tend to go for a more natural
sounding presentation.

> remember bob 
The last time you saw your friend Bob, he was running headlong toward an
enemy encampment, firing bursts of plasma wildly and screaming his head
off. Bob's like that. Somehow, he's always managed to survive. Except..
that was almost a month ago, and you haven't seen him... 

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

Hey! I liiike that! Mind if I steal the idea?

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

*grin* Never thought of scrambled names...

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

*grin* well, I keep trying for those. Sooner or later, one of these Turing
AIs is gonna pull it off.

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

*nod* Implementation as opposed to hacking.

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

Yeah, I like that too.

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

Well, we've had a couple of nice discussions pop up from time to time. I
try to fan the flames whenever one of them comes up... potential recruit
screening for here, for one thing. *grin*

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            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




More information about the mud-dev-archive mailing list