[MUD-Dev] Optimized Object Storage

[J C Lawrence]

On Sat, 18 Dec 1999 05:30:28 +1300 
Ian Macintosh <iman at issystems.co.nz> wrote:

> The Subject line used to be "[MUD-Dev] The grass is always greener
> in the other field".  Time to change it I thought.

Explicitly not writing as list owner:

  Just as an observation and an FYI, the usual way to do such
subject renames is to put in the new subject followed by "(was: <old
subject>)".

    eg  Subject: Bubba
    becomes: Subject: Boffo (was: Bubba)

  Its not cast in stone, many people just replace the subject
silently or have some variation on the above, but it does add a
pleasant paper-trail feature which can be useful in resurrecting a
thread.

Still not writing as list owner:

> Firstly, my opinions.  Let's you know what probably influences me
> in certain directions.  I strongly dislike OOC solutions, or
> transparently artificial solutions.  Object decay fits both of
> those to my mind, so I dislike it.  That's the philosopical
> viewpoint.  

I'm curious as to what you think of my mana based decay strategies
as regards your artificiality concerns?  

  Loosely: All objects consume mana at some rate.  Magical or
magically enhanced objects consume mana at higher than normal rates.
(There are various flavours of mana, and objects require feeding of
different percentages of the different mana types, but this can be
ignored).  If an object is unable to satisfy its appetites they
decay at a rate proportional to their demand for mana.  Ergo, a
magical object with a high mana feed requirement will decay very
rapidly should it find itself starved, possibly falling to dust in a
matter of seconds for a very high mana object.

What's more amusing about this is that carrying many objects,
particularly several high magic objects, at the same time becomes an 
intense problem.  How to keep them all fed with mana at the same
time such that none of them decay?  The typical result is the rapid
destruction of all high magic objects once they are in proximity
(they starve each other).

--<cut>--
  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 prohibit all tree cutting.
--<cut>--

A few messages I ran across while digging the archives on this area
that you might find interesting:

  http://www.kanga.nu/archives/MUD-Dev-L/1997Q1/msg00158.html
  http://www.kanga.nu/archives/MUD-Dev-L/1997Q2/msg00095.html
  http://www.kanga.nu/archives/MUD-Dev-L/1997Q2/msg00431.html
  http://www.kanga.nu/archives/MUD-Dev-L/1997Q3/msg00480.html
  http://www.kanga.nu/archives/MUD-Dev-L/1998Q2/msg00479.html
  http://www.kanga.nu/archives/MUD-Dev-L/1998Q3/msg01325.html

(I've been pretty quiet this last year).  Also realise that I've
given up on the logging aspect until mass storage IO rates increase
by another two orders of magnitude.

  "Murkle is intended to serve worlds where the players can create
virtual realities, and then enforce those realities on each other."

> I recommend SQL, don't make a trillion small files in a directory.
> An OS *is not* optimised for that task.  SQL *is* optimised for
> that task.

Ahem.  This is a dangerous generality (I tend to work on OS'es for a
living).  This is a filesystem and IO question.  You are correct in
that many filesystems are not optimised for this, you are incorrect
in that some filesystems _are_ optimised for precisely this case.
On the IO subsystem end, the same rules and patterns hold true.

> I have thought of, but not yet implemented, a technique whereby I
> consolidate multiple identical storage-objects via a counter
> property.  The way I have considered doing this is by first
> writing a new storage-object into a to-do list, and later, when
> the system detects plenty spare CPU time available, iterate
> through the other objects in that location and consolidate.  That
> would then only need a small modification where there is a list of
> retrieval keys instead of a singular retrieval key.  Then 75
> 'small swords' would become massively efficient in terms of
> in-game memory.

You might like to hit the archives for things like "anonymous
aggregate objects" and the like.  This has been extensively
discussed here.  I still don't have a handle on this that I like,
especially one that incorporates some of the ideas on ur-objects tht
I'd like to try.

You might also like to look into the neighborhood concept that keeps
resurrecting itself on the list (another gorgeous idea that I just
can't seem to implement in a pleasing way) to see if you can't plug
that into your aggregate object system as well as your aggregate
object scanner (eg make aggregation detection a normal function of
neighborhood split/redefinition processing).

--
J C Lawrence                              Internet: claw at kanga.nu
----------(*)                            Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev