[MUD-Dev] Player malleable worlds (was expected value and standarddeviation)

[John Buehler]

Adam M writes:
> Corpheous Andrakin wrote:

> Well, from the network-performance perspective, there's no real
> difference between "lots of identical bags" and "any of 65536
> standard icons". An extra 2 bytes to describe which icon to use
> for the item isn't going to hurt your network protocol -
> especially since these are static items, and updates to position,
> state, etc need only be sent infrequently.

> Actually, have a look at runescape.com - they've always displayed
> everything you ever dropped. Looks ugly (you get huge
> epilepsy-inducing flickering piles of items, becuase the 3D engine
> had poor depth sorting), but the game was always designed to work
> on low-end dialup conenctions, and the items don't seem to have
> been a problem there.

> Or Diablo2 - I think they limit it to one byte (256 possible
> icons). So lots of swords look similar :). ACtually, they'll have
> more by now, what with the expansions adding whole new classes of
> item.

My current thought is to define object classes and derive the exact
properties of the members of the class based on a seed value.  A
simple use of the seed value is to prime a stable pseudo-random
number generator for the various parameters of the class member.
But the point here is that the network sees the class identifier and
the seed value of the member.  The client generates as much of the
member's data as is needed for the task at hand.

With this approach you get quick transmission of a member combined
with as much detail as you care to place into the member definition
algorithm.  Base display of a member can rely on a canonical
definition of the class (e.g. a standard sword graphic) combined
with as much of the member definition as you care to summon up.  For
example, if you just want the color of the member so the canonical
sword can at least be of the appropriate color, you get the color
from the algorithm and the remainder of the attributes from the
canonical member.

This approach removes hand-design of objects from the artists.  With
this approach, they only control the general parameters of objects.
But for an environment with a massive number of objects, you can't
hand create that many objects anyway.  It's possible to pick from
the massive number of (for example) swords simply by generating
piles and piles of them and picking the ones you want to reserve for
specific purposes (the picking can be accomplished algorithmically).

Lastly, if you have modifications that you want to make, there can
be exceptions that go along with the class identifier and the member
seed value.  Obviously not a technique that should be used
extensively because it erodes one of the original goals of the
approach, which is to get lots of detail from very little data.

And don't read too much into my reference to 'classes'.  I'm not
referring to object-oriented programming classes here.  I prefer to
implement using component technology :)

JB
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev