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

[Ilya]

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

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
http://www.kanga.nu/lists/listinfo/mud-dev