Resets and repops

[claw at null.net]

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
  Newspapers
  OBE (Out of Body Experience)
  Scrying
  High altitude overview (for those with 3D)
  Indirect viewing ("typical" magic eye objects, or your
clairvoyance).
  Remotely controlled/possessed mobiles.
  Demon riders on mobiles.
  'Bots.

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.  

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

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


-- The event that is logged is actually a fairly simple:  

1) At XXX time check conditions if the new state is
allowable/logically consistant.  

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

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

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.

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.

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.

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

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:

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

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.

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

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

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.  

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

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.

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.

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...