Greetings. :)

clawrenc at clawrenc at
Thu Apr 10 15:19:30 New Zealand Standard Time 1997

In <199704090314.DAA675068 at>, on 04/08/97 
   at 01:44 PM, Shawn Halpenny <malachai at> said:

>On Apr 6,  8:23am, coder at wrote:

>> This is probably better understood from the inside oot, rather than trying
>> to look at the server side:
>>   Everything is an object.
>>   Objects are defined in a database.
>>   Objects have Unique IDs.

>I've been kicking this unique ID/object around as well, and was
>wondering about how you generate them?  

I use a 64bit value where 32bits are a simple record # (ala index #),
and the other 32bits are the time_t of the time the object was
created.  The full 64bit ObjectID is stored with each object, and is
used on object retrieval to ensure that the object retrieved
(retrieved by record #) was the one requested (ie not recycled).  This
allows record #'s to be recycled freely as long as no given record #
is used within one second of its deletion (which is pretty simple to

>I haven't been able to find
>any algorithms that would generate a unique ID given an object (or a
>request to do so) without having to search the list of ID's already

Many systems also have a high resolution timer which could be
profitably used.  However, I also wanted the ObjectID to also be
useful for locating the object on disk as a simple index, thus the
combo of the time_t and the record#.

>I don't know for sure if that last bit is possible, but I
>want things to still be speedy when the number of objects is large
>(2^31).  I had an idea to keep track of the next available ID, and
>each time an object was created, assign it that value, then bump the
>value.  Whenever an object is destroyed, keep track of the last 'n'
>(where n is something fairly small and manageable like 100) now-free
>IDs and if you wrap your next-ID counter, pull them out of the list
>of freed IDs.  If the list runs empty, you have to search, though.
>There's optimization to be done in that, but that's the gist.

I build a list of "free" record #'s at server load.  I then add record
#'s to it as I delete objects.  Requests for new objects are done by
pullin the top (oldest) record # off the list, checking to see if its
at least a second old, and then building an ObjectID from it with a
time_t.  Of course if there are no entries in the deleted list, then I
just increment the current highest record number.

>Now I really like that mana-flow idea.  It fits in with what I'm
>shooting for, I just haven't begun to think of how I wanted to do it.
>Is that a room-based value?  

A clipping:  

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

<<Note: See below for description of TC's>>

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

and for related fun:

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

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

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

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

and a simple dreamed up example of a mana fight:

  UggUgg slashes at you with his Sword of Instant Beheading 
  and minor discomfort!
  > cast soakhole on uggugg
  You cast the dreaded mana eater soakhole on UggUgg!
  UggUgg sneezes and buries your in green snot!
  Your armour suddenly dissappears!  
  Your spell of magical summon protection fails!
  Your spell of magical sight fails!
  UggUgg's Nose Ring of Killer Snot dissappears!
  UggUgg's Belt of Gas Containment dissappears!  Phew!
  UggUgg's dagger of wart removal dissappears!
  > cast create mana
  You create 5,000 units of mana!
  Your mana stores are now empty.
  >cast $my_protections
  You are now magically potected from summons.
  You can now see all magically hidden objects.
  UggUgg thows a blade of painful castration at you!
  > jump!
  You leap mightily.
  The blade misses!  You are still a baritone.
  > attack uggugg with spear
  You ram UggUgg through with the spear of Icy Death!
  UggUgg now has the flu and looks a bit watery about the eyes.
  UggUgg picks up a rock.
  UggUgg bases you with a rock!  Ouch!  That hurt!
  > throw TC at uggugg
  You throw the charmed trash collector at UggUgg.
  The TC englobes UggUgg!
  UggUgg gives you the Sword of Instant Beheading and minor 
  UggUgg gives you the Boots of Mighty Chilblains,
  UggUgg gives you the Goggles of Big Farts.
  UggUgg gives you Super Nose Hair Puller.
  The TC has eaten everything UggUgg was carrying!  Yech!
  UggUgg is naked!
  Your spell of magical summon protection fails!
  Your spell of magical sight fails!
  Your spell of magical tummy tuck fails!
  Your spell of power voice fails!
  Your spell of land control fails!
  Your spell of bowel control fails!  
  Your spell of toe cheese protection fails!
  > stat spells
  You have no spells.
  > stat mana
  There is no mana here.
  > strangle uggugg
  You wrap your hands about UggUgg's neck and begin to squeeze!
  UggUgg prays to the Great God GooGoo!
  GooGoo mana blesses the area!  
  There is a LOT of mana here!  You skin prickles!
  > i
  You have a mana shielding sack
  > l in sack
  There are 5,000,000 TC spores in the sack.
  >empty sack on UggUgg
  The spores eat all the mana!
  There are 5,000,000 TC's here!  Wow.
  All the mana is gone!  

The real weapons now are mana attacks.  But then woe be the chap who
sneaks in with a non-magical bodkin and pricks the battling mages in
the arse while they mana fight.  He might just win the war. --<cut>--

>  there is some amount of mana in a
>room and using mana while there causes that value to drop?  And when
>it drops, draw mana from adjacent rooms that handle it the same way,
>and so on?  A sort of chained, source-sink model, I suppose?  Do
>players have a mana count of their own as well, or some value
>measuring how adept they are at using the flow around them?

Mana flows like a very gas only slightly heavier than air and very
slowly.  The code here works very simply my having each location check
its own manay levels, and its neighbor's mana levels periodically, and
having them reconcile.  Players can (at great expense) carry collected
mana with them.   My handling of player abilities is a little unique,
but very losely, yes, there is a measurement of mana capability

J C Lawrence                           Internet: claw at
(Contractor)                           Internet: coder at
---------------(*)               Internet: clawrenc at
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...

More information about the MUD-Dev mailing list