[MUD-Dev] The grass is always greener in the other field

Scatter scatter at thevortex.com
Fri Dec 17 10:19:08 New Zealand Daylight Time 1999

Matthew Mihaly <diablo at best.com> wrote:
>Cynbe ru Taren wrote:
>> E.g., if some values frequently default to the same value, but may
>> -sometimes- be changed, space can be saved by, instead of the typical
>> strategy of using a structure field per object initialized to the
>> default value (wastefully storing the default value many times),
>> instead storing the default value once and using a hash table
>> to record which objects have non-default values for the field.
>Well, I'm not entirely sure I understand what you are talking about, as
>I'm not much of a techie, but from my meager understanding, I still don't
>understand how knowing which objects have non-default values will help
>with the problem as I stated it. For instance, there are about 6000 vials
>in Achaea currently. When you buy one, it will last 250 half-months
>(that's about 130 rl days). So, you've got 6000 vials, with their decay
>counter set at between 1 and 250. How can you aggregate these, unless they
>have the same decay times, without losing the information specific to

I use a system of place-holder objects for this kind of situation. It's
fairly simplistic, but it is yielding great savings in RAM and disk-space

In LPC, objects are cloned from a base (template) object. A normal object 
has a large set of attributes and a set of methods that manipulate them. A 
place-holder object has the same set of methods, but as few attributes as
possible. One of the attributes is a reference to base object, and the methods
that simply query other attributes just retrieve that attribute from the 
base object, thus retrieving the default value.

In the simplest case, the place-holder has only one attribute - the
base object reference. Since only attributes are saved, not the methods,
this is a massive space saving over saving all fifty odd attributes for
the object. This kind of place-holder can also be trivially aggregated
for saving, reducing the space needed even further.

In the case of things like your vials, or weapons and armour where every
object instance has a different 'condition' attribute, the place-holder
object would contain two attributes - the condition and the base object
reference. Still two attributes vs. fifty is a large saving, and place-holders
whose attributes match can still be aggregated for saving.

When changes are made to an individual object by something in the game
and an attribute not contained within the place-holder is changed, the
place-holder is transparently replaced with a 'real' copy of the object.

This means that for things like coins where thousands of them exist
with no changes to the default attribute values, all of them are represented
by tiny place-holder objects with only a couple of attributes. The
few that have had changes made to them, spells cast on them etc. are
'real' objects that save all their attributes, thus retaining their

Scatter ///\oo/\\\

MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list