[MUD-Dev] Optimized Object Storage

[Ian Macintosh]

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

I'm not going to quote all the relevant parts or parties.  There are
too many :-)

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.  Now
to the technical.

I have implemented my solution in what is to me, a very simple way.  I
am sure I'll get corrected where necessary by ya'll were I'm wrong :-)
Please note that I'm using the LambdaMOO server and my own DB built
from scratch, so some concepts may not be as transportable to other
technologies.

There is a generic object, which contains the absolute minimum stats.
Description, type (class), size, weight, etc.  Your definition of
minimum might vary.  When an object gets dumped into a storage
location (correctly identifying a storage location is a small topic on
it's own), the full object is written to disk.  Use a suitable fast
and secure system for that.  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.

After successfully writing it to disk (use a transparent "write object
to disk" object method that can alter the storage location and method
transparent to the rest of the system), change the parent object to
the generic 'storage-object'.  That drops all unique info, and then
write the retrieval key data into that object.  To retrieve the
original item when a player 'touches' the object is trivial.  To
simplify my system somewhat, I keep original objects out of the game,
and all in-game objects are children of those 'master' objects.  No
in-game object ever has a child inheriting from it.

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.

While writing this, it crosses my mind that it would also be possible
to write the entire contents of a storage object to the SQL server,
and only retrieve this when required.  Using this on top of all the
other methods should lead to tremendous savings.

What do you think?

Regards,

Ian Macintosh.




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