[MUD-Dev] 3D engines for MUDs

[Chris Gray]

[Niklas Elmqvist:]

[snippage]

:Anyway, using this scheme, we get a nifty way of viewing and designing
:the macro-geography of our world (by first generating the world
:map and then possibly tweaking it a little with some kind of editor), as
:well as blending together the boundaries of adjacent submaps.

You're on track with me here. However, as I previously mentioned (which
was the trigger for my current sidetrack into bytecode), you don't need
to actually store any height maps anywhere. If you are carefull with how
you do your pseudo-random numbers, basing them only on a single fixed
seed and the co-ordinates, you can, at will, generate reproducible heights
for any part of your map. This is the full map of your world (about
16 million squared in my case, at least tentatively).

The key question I'll be looking at soon (hah!) is how to effectively
store the exceptions. A builder asks for an image of the height-map for
the area he is messing with, and decides to fiddle it a bit, by raising
or lowering some key points. You need to store those changes in such a
way that you don't need tons of storage, but also so that retrieval based
on the co-ordinates is fast. One possibility I've been thinking about is
to artificially introduce actual stored maps for levels in the hierarchy
where changes have been made. I want those small enough to not be too
large, yet large enough to make them worthwhile, storage-wise. I've
tentatively chosen 16 x 16. So, if a huge part of the world gets modified
by a builder, then perhaps the top 16 x 16 map actually exists, and contains
the generated height values as well as the explicitly modified ones. Each
element of the array can also contain a different seed to use for the
detail beneath it, thus allowing a builder to experiment to find a "good"
seed for that sub-area, without changing the global seed used for the rest.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA