[MUD-Dev] Rooms, 3D arrays, etc.

[clawrenc at cup.hp.com]

In <9705311659.83c1 at ami-cg.GraySage.Edmonton.AB.CA>, on 06/01/97 
   at 10:05 AM, cg at ami-cg.GraySage.Edmonton.AB.CA (Chris Gray) said:

>[Chris L:]

>:>What I haven't quite figured out is how to be able to repeatably
>:>generate the height for any given co-ordinates within the world.
>:
>:If you use fixed seeds which _are_ stored in the DB, then shouldn't
>:the algorithm repeat when you interpolate between your fixed and known
>:seeds?

>If interpolation here means to follow the fractal rules in order to
>generate down to the level of detail needed, then yes, it *should* be
>possible. I think perhaps my problem (it was a while ago that I last
>played with this) may have been simple grunge programming problems.

Correct.

>It occurs to me now that the *order* in which points are computed is
>very important. The goal is to minimize the number of seeds that must
>be stored, but still be able to compute down to some point without
>having to compute hundreds of other points on the way. The problem is
>the random number generator requiring that each generated number be
>used in exactly the same way in order to reproduce the terrain
>correctly.

Not only that, but you will get into side effect problems where
generating the sequence to derive from A from B results in a certain
value at B, but conversely generating the sequence from C to get B
gets a different value.  This can get *really* hairy to track down and
provably ensure will not happen.

>To clarify a bit, I don't think you can do this by using *just* the
>co-ordinates as the seed, else you will get patterns in your terrain.
>Hmm, is that what Miro's code example is doing - working hard to
>remove any patterns that would show up, so that just the coordinates
>can be used?

I haven't looked at his code in enough detail to say, tho I suspect
so.  Miro?  

>A conceptual problem I have is that if each level of the hierarchy
>is, say, 16 x 16, then you only have 8 bits as your seed. That would
>seem to restrict you to 256 possible outcomes, which is not random
>enough. Hmm (thinking on the fly here), possibly the top level could
>have fully stored seeds (that's only 256 of them), and all other
>levels could use all bits at their level and all higher levels. That
>gives 16 bits as the seed for each square in the second hierarchy
>level. Oh yes, and you can merge in the stored seed, too - that ought
>to be satisfactory.

Bingo.  For each coordinate, however far down the tree it is, take the
entire set of key values from that location on up to the rood node and
from that assemble one very large and detailed key value (ie longer
bit streams).  Look at it this way:

  At the highest level the height variation is minimal.  When you are
dealing with (say) 512x512 kilometer squares, the average height
difference of any sqare as compared to another other adjacent square
is likely to be minimal and easily quantifiable in a small ranged
value.

  Conversely when you get down much smaller, say down to meters, the
averge height variation can be *huge*.  cf The top and bottom of the
Grand Canyon.  

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...