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

[cg at ami-cg.GraySage.Edmonton.AB.CA]

[Matthew Mihaly:]

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

Well, in my system, an object takes a fixed overhead of 12 bytes, plus
8 bytes for each attribute that differs from what it gets from its
inheritance chain. So, if your vials differ only in their decay counters
(all else, like appearance, behaviour, etc. comes via inheritance), then
thats (12 + 8) * 6000 = 120K bytes. Quite a bit, yes, but perhaps it is
a lot less than other schemes would use?

If this were done using the C++ style inheritance of structure (rather than
of values), then each vial could easily be over 100 bytes of space. So,
I'm curious as to what kind of representation UO does here.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/



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