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

[John Buehler]

Adam M writes:
> John Buehler wrote:
>> Adam M writes:

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

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

> A nice idea. Did you invent it yourself, or follow a text on
> compression? From an entropy / information-coding perspective, I
> think it's a fairly standard form of compression.

This is adapted from a fractal terrain program that I've been
working on.  In order to communicate the terrain to the client I
could either pump the polygons over, pump a height map over, or pump
a number of control values that let the client do the computation
itself.  And yes, it's clearly a compression technique.

>> This approach removes hand-design of objects from the artists.
>> With this approach, they only control the general parameters of
>> objects.

> ..because surely you could just say "well I just need a bit of
> code in the object-properties editor that regenerates seeds until
> it finds one that reproduces this particular set of atts". So I
> may have misunderstood you...

I was trying to suggest that very thing in my mention of a computed
database table.  I didn't want to go into excessive details because
such posts are usually glossed over :) A computed database table
would conceptually hold all members of the class.  As a result, a
SQL SELECT-like mechanism could be used to locate members of
interest.  Which is what you're talking about.

> I presume you would just allow both? Artists generate an item, and
> the editor fits a seed to the specified values, and then says "and
> I've auto-generated the following values for the attributes you
> haven't specified...if you don't like any of them, override them
> and I'll try to find a new seed that will fit the
> slightly-more-precise new criteria".

I don't start with the assumption that individual items are
interesting from a design standpoint - which is the current means of
doing artwork for a game.  A class, or family, of items is what's
interesting when you look at creating a truly massive world.  The
swords of Gondor look a certain way.  But if you hand create the
canonical sword and equip all 1000 warriors of Gondor with that
sword, it looks silly.  But you can't realistically hand-create 1000
swords that follow the Gondor look and feel.

So you've described a kind of 'assist' for the artists, assuming the
current approach to artwork.  What I want is for the artists to
define the limits of the look and feel, and then the programmers
capture that look and feel in a class algorithm.  When somebody who
is hand-building a quest or is hand-composing the belongings of a
major venue character (a small return on labor, by the way), doing
the SQL SELECT-like search through particular classes would be used
to locate items appropriate to the quest or the individual.

So if the quest has to end up with a ruby ring of considerable
value, the 'Ornate Rings of the Western Continent' family of items
might be searched for all those rings that come up with perfect
rubies between 1 and 2 karats and which are mounted in a precious
metal.  Note that I have it in mind to be able to show them the
actual ruby through the use of the same technique.  Every gemstone
can be absolutely unique and can be rendered to the player.  That
rendition will aid in the player's attachment to each item.  If they
spot a cat's eye agate that they particularly like, they'll hang
onto it and it will have extra value to that player.

It is assumed that the VAST majority of items will be randomly
selected from a class - purely because there are way too many items
to be created.  Want 20 house guards for Lord Boffo?  Blasting out
20 sets of 'House Boffo' equipment should be very easy given
families of items (think simple macroing of existing families for
something like that).

Note that the technique applies to an arbitrary design domain.  Do
you constantly have to create fully equipped soldiers for the evil
empire?  Apply this technique to manufacture your soldiers according
to the look and feel that you're trying to develop.  I'm sure many
of us applied this technique way back in the D&D days to crank out
lots of orcs or gnolls or what-have-you.  The computer only lets
this technique be pursued a bit more powerfully.

Another use is actually designing the physical attributes of a
character.  The canonical appearance might be a skinny or heavy man
(an example of a couple of families or classes), but if you look
closely using the game interface, you can zoom right into the face
and have it rendered according to the algorithm that controls facial
structure.  Heavy features, light features, sharp features, wide
faces, narrow faces, scars, missing teeth, and so on.

It just goes on and on as a stock way of manufacturing many objects
that are variations on a theme.  Most of the time, we don't care
about the variations, and we can just say that 20 elves need to go
'here' and blammo you have your elves.  Each is unique, but the data
to make them unique can be perhaps a few dozen bytes, producing a
massively detailed character.

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