Resets and repops

[Nathan Yospe]

On Wed, 19 Mar 1997 claw at null.net wrote:

:On 18/03/97 at 10:00 AM, Adam Wiggins <nightfall at inficad.com> said:
:><Chris Gray:>
:>> [Much good example deleted - the famous 23rd platoon bites it.]
:
:>> ...When I came upon similar situations, where
:>> I wanted to replenish some monsters or prizes, what I did was to simply
:>> store the time that the last set had been "used up". Then, if a player
:>> character (I explicitly chose to not have NPC's trigger such things)
:>> enters the area, and the time is sufficiently later, then I will 
:>> regenerate the stuff just before the player enters the location. So, 
:>> there are small resets, but nothing global, and only when "needed". I 
:>> like this way of doing it.
:
:>Not bad; my only problem with this is that if there's any sort of
:>mechanisms by which the player can learn about their world without
:>actually going places, this starts to break down.  The most obvious
:>example is the spell locate object.  
:
:Other good candidates:
:
:  Built in rumour systems
Macroscopic approximation, if you must have it. This allows a rumor to
traverse a dead area with no CPU burn, and when a Player finally
encounters the Rumor, he/she will have no clue whether it propogated live
or not. 
:  Newspapers
Er... how does this differ from rumors?
:  OBE (Out of Body Experience)
OBE would, by definition, have a manifest Player controlled bodyless
Character. Sounds perfectly susceptible to the normal rules to me.
:  Scrying
Again, this would create a local Player controlled bodyless Character
manifestation, and adhere to the rules.
:  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.
:  Indirect viewing ("typical" magic eye objects, or your clairvoyance).
Again, creates a manifest bodyless Player controlled Character object.
:  Remotely controlled/possessed mobiles.
Sounds like a Player controlled Character to me.
:  Demon riders on mobiles.
Demon as in AI? Those behave as if they were Players, so ammounts to
posession.
:  'Bots.
Player controlled.

:This is of course all pretty well MUDLib stuff, but I think it should
:be accounted for.  I'm a big fan of automated rumour systems with
:built-in local reactions to parsed rumours for one.  

I don't mind any of this stuff, but not a thing above has violated my
system, and I think all of it could be implemented in Physmud++ without a
recompile.

:>But I guess I like to avoid
:>doing things this way (that is, triggered by players) because it's
:>pretty tricky to avoid slip-ups like I describe above.  Using the
:>brute force method tends to be easier all around and works more
:>consistantly.  Having said that...
:
:It also allows having your server run simulations.

Well, that's true... except that I allowed simulations by creating a class
of AIs that counted as Players.

:>This is one of my main problems with repops.  (Hey, guys, it's been
:>29 minutes since we left zone X, which means it's gonna pop in the
:>next minute)
:
:While this area was been gutted when I reworked my object model a
:while ago (again), the way it is supposed to work for me:

:-- When an object changes state such that a new state should be
:achieved some time in the future, then that object logs an event to
:that effect.  (Standard example: mobile is killed, and needs to be
:replaced in some form)

Agreed.

:-- The event that is logged is actually a fairly simple:  
:
:1) At XXX time check conditions if the new state is
:allowable/logically consistant.  

Ah. Not bad. Often, the logged event is to create a new instance at a
future date, but with a few distinct and unique characteristics. For
example, were I to implement a fantasy, and desire the new shopkeeper to
replace the old scenario, I would have a generic shopkeeper, and a set of
pick and choose features, which would be applied to the generic shopkeeper
randomly by his predecessor upon death, and scheduled for an appearance at
some later date.

:2) If so, log a new event which attempts to create that state.  Give
:this second event a low order probability of execution (this means
:that exactly when the event will ripen is uncertain, possibly within
:seconds or as long as months from then).

Umm. I can schedule randomly on the scheduler's (Event generator's) end,
but my Event execution code is hardlined. Hmmm.

:Its this randomity factor
:that prevents the known repop times.  Instead its now: Whoozis will
:start thinking about repopping in 15 minutes, with a 0.5% probability
:of actually repopping in any given minute after the 15 minutes are up
:(so could be right on 15 minutes, or could be 6 days from now).

I can see how this would be nice. Damnit, now you got me thinking of
scrapping my Event system and rewriting. Don't do that! *grin*

:3) If no, and if the re-instatement is still "possible", relog the
:same event as in #1 but for a yet future time.

I do have "delay" scheduling.

:The clever stuff comes of course in the recreating of the state, which
:is where I finally followed ChrisG's tack <nod> and split my object
:model into class objects (which must be unique, and may inherit from
:multiple parents), and instances (which must inherit from a single
:class object, and need not be unique).  FWIW the driving gain for
:moving to this split was standardised ctors and dtors for object
:instantiation.

My OLC object vs instance model.... and there are other advantages...
modification of an OLC object, however, under my system, does not change
any of the instances... quite. Lazy copy model, which means somewhere out
there will be floating a copy of the original characteristics, until the
last copy of them is destroyed... so if you modify, say, an OLC version's
description, the String will cut loose and bindto one of the instances...
if that instance dies, it will bind to another, and so forth. Certainly
saves on the String overheads. I'm working on a global String gathering
and compression system now... I've got the fundament, and figure I might
be able to save a good 35% on memory usage if I implement it properly,
with no penalty on speed. OLC objects, incidentally, have only
read/write/edit properties and dead data. Instances are live.

:Getting back to recreating the state and taking the resurrected mobile
:example, the secondary event would create a new instance of the base
:<whatever> mobile type.  The type's ctor would initialise it
:appropriately, and (one hopes) would appropriately randomise the
:attributes so as to be different from the dearly departed.  A nice
:side effect of the naming schema (user assigned names) and objectID
:handling (all instances have guaranteed unique never-reassigned
:ObjectID's) is that any user-assigned names given to the dead mobile
:will still be orphaned, and not refer to the new instance.

I don't care for name assignment so much... name recognition, however... a
new instance would not be recognized (dead pointer, garbage collection
deletes the sucker.)

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

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

:Aside:  
:
:At the moment I've been intending to make the TrashCollectors (cf
:earlier discussion with ChrisG on removing waste objects) do this as a
:side effect of their normal rounds.  The base purpose of the TC's are
:to accellerate object decomposition, and provide an amusing (cheap)
:target and toy for users.
:
:Essentially the TC's would wander the land in slightly overwhelming
:numbers, finding and collecting any loose odd objects that happen to
:be laying about (eg torches, dropped EQ, weapons, newly programmed and
:abandoned user objects etc).  How the TC's handle that junk comes in a
:number of flavours:

So far sounds like Midgaard janitors.

:-- If the object is small they pick it up and continue on. -- If a
:larger object they englobe the object and decay it and any carried
:objects at an accellerated pace.  Once the object(s) have destructed,
:the TC will move on, having grown slightly.  This process produces
:considerable mana. -- If the object is too large to englobe, it will
:suck its own thumb and grow until it is large enough to englobe the
:object(s).  Once the object(s) have destructed, the TC will split into
:multiple new TC's .  This process consumes considerable mana.  Should
:there be insufficient local mana, the TC consumes the mana, dies, and
:scatters a spore for each unborn TC.   -- If the object is a TC
:corpse, the TC will eat it and grow by a factor smaller than the size
:of the TC eaten.  There is no net mana change. -- If the object is
:another TC, a small percentage of the time one TC will eat the other,
:and both will die, producing four TC spores in the process. -- If the
:object is in some way special/wanted the TC picks up the object, drops
:anything else it is carrying, and attempts to convey it back to a
:(special characteristic specific) dumping group.  (This makes TC's
:preferred hunting targets for players)  A carrying TC will produce
:significant mana in each room it passes thru. -- The TC will spoof the
:object found, and disappear.  The action of the spoof is to speed the
:delay of the object, and to drop a TC spore (that will grown into a
:new TC) into a percentage of rooms it passes thru which don't contain
:TC's or TC spores.  In the mean time the base object continues to
:behave as normal until it destructs.  There is no net mana effect. --
:If the object is a TC spore, the TC will eat the spore and increment
:the count of the number of spores it will release when it dies.

Intersting. Extremely complex. Very interesting. Can't imagine how hard to
program that's gonna be.

:Once a TC has grown past a specified size, or if it successfully
:consumes more than X objects, it will split into two otherwise
:identical TC's.  A TC in normal operation (moving, whatever),
:continually and slowly produces mana.  However, very high mana levels
:are quickly fatal to TC's _unless_ they find an object to englobe.

:TC's have a set (short) lifespan.  They are born from spores, grow on
:objects found, move quickly, and produce spores when they die.
:
:As far as resets are concerned, should a TC find an object with a
:reset() method, with a set RESET_ME flag, the TC will call the reset()
:method a percentage of the time (percentage depending on age of
:requested reset, plus object-specific fudge factor).
:
:A TC spore will consume all mana in its area.  The rate of development
:of a TC spore is porportional to the rate of mana consumption.  Should
:their be no mana, the spore will lay dormant.

Hmmm. Wierd world you have going here. *grin*

:>> In all things, though, you have to balance the benefit actually seen by
:>> the players against the implementation effort. If the players can't really
:>> tell the difference, then I'd say don't bother. However, if you do
:>> everything gradually, so that rumours float around, news articles appear
:>> in local papers, troop movements can be observed, both directly and
:>> indirectly, then I'd say go for it. But then, if all of that stuff is
:>> there, you obviously already have a very detailed MUD!
:
:This way to do this is to implement base systems which automagically
:generate rumours/news events etc, which are then carried about and
:reacted to by mobiles, and communicated to players etc.  Once you have
:a base, automatic rumour system (one that requires no supporting code
:in other objects) most of the rest should pretty well come for free.

I've created a class derived from my Communication class that essentially
does this. It spawns, splits, mutates, decays and jumps from Character to
Character. When it jumps to a PC, it causes the previous holder to tell
the rumor to the PC. It cannot live on non sapients, and certain
personalities will also kill it. PCs can spread rumors by typing "tell
<name> about <something from the rumor key>" IE, if the PC had recieved
the rumor with the message 'The ugly old man tells you, "Hey, buddy, did
you hear about the king's daughter and the horse trainer?"', you can later
type "tell uffoogu about the king's daughter" and it will autotell the
rumor for you.

:>...Dwarven guards, when they get disarmed
:>or their left vambrace chewed up, have to go down to the armory and
:>get fitted for a new one.  Of course, things in the armory don't just
:>appear there - they are made by the dwarven smiths.  Naturally _they_
:>can't just make weapons and armor from thin air, they need the ore
:>brought up to them from the mines.  The miners of course, need
:>tools...etc etc. 
:
: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.

:eg  Mana comes in two forms, +ve and -ve.  Mana is required to do
:magic (sign dependant on magic used).  Magical objects have a mana
:sign (-ve or +ve), and consume mana of that sign, thus slowing or
:stopping their decay.  Magical objects react to opposite sign mana by
:accellerating their decay.  Should a magical object find no mana to
:consume they decay VERY quickly (no mana is worse than bad mana). 
:TC's and a few other objects produce mana (always in matched +ve and
:-ve pairs) at various rates.  Mana flows like a liquid thru rooms and
:spaces, attempting to have no two locations adjacent with different
:mana levels.  

Cool!

:What's this mean?  Magical objects have a definite life span.  Don't
:feed them enough mana and they destruct.  The more magical objects you
:have together, the more quickly your local area becomes mana depleted
:(mana flows slowly) and the more quickly they decay.  Get sufficient
:highly powered magical objects together and they'll all destruct
:within seconds.  Keep only one or a few magical objects, and they'll
:survive on the local mana.  Want lots of magical items?  Better keep
:them all right beside a major mana producer (eg a farm of TC's you
:continuously feed trash).  

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

:Magic fights also become travelling affairs.  No-one can afford to
:stand still -- they run out of mana.  Then again, manage to locate
:yourself by a major mana producer, and you have a huge advantage.
:
:You sure as heck won't find any super powered over-armed magical users
:or mobiles wandering about -- they may have the Spear of Icy Death,
:the Greaves Of Incredible Footwork, the Magical Nose Ring Of Killer
:Snot, and the Goggles Of All Making All Tits Bigger, but unless they
:work their butts off keeping them fed enough mana, six steps later
:they'll all turn to dust.

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!

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

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