[MUD-Dev] The grass is always greener in the other field
Thu Dec 16 16:27:01 New Zealand Daylight Time 1999
On Thu, 16 Dec 1999 15:55:14 -0800 (PST), Matthew Mihaly wrote:
))On Thu, 16 Dec 1999, Cynbe ru Taren wrote:
))> "quite impossible" is fightin' words, podnuh!
))> I'd guess careful analysis would show that 90% of the state stored
))> could be aggregated and shared, assuming implementation sort of typical
))> of the current server genre.
))> 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.
))> Slightly slower, sure -- nothing buys you nothing in engineering.
))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
))them? (I didn't use the example of weapons and armour, as presumably they
))fall into the 10% that your 90% excluded, as they have multiple stats that
))can and will likely be different for most instances of the armour or
It just depends on how much information there is (to go with this example)
about each vial, and how much varies. If the information about a vial includes
its location, its contents, its decay counter, its weight, and (say) its color, and
all of those could vary pretty dramatically, with several hundred different values
for each of those data items, then it wouldn't do you any good to store a sort
of generic vial and keep track only of the variations from the generic.
On the other hand, if there is a high degree of similarity in the data values
representing these vials, then aggregation could work. So let's say that of
these 6000 vials, there are really only four colors, and five contents, and all
have the same weight. Twenty 'prototype' vials could then be stored, and then
for each prototype a list of locations and decay counters (only) would need to
be stored. Twenty lists of 300, with half the data held constant in each list of
300, this beats 6000 lists of one, with all data varying at will, so to speak.
It's more or less what the database people are referring to when they speak of
data normalization (feel free to jump in to refine, you database people).
Only very good knowledge of the data can tell for sure if this will help or not.
Ilya, Game Commandos http://www.gamecommandos.com
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev