[MUD-Dev] Wilderness

Nathan F. Yospe yospe at kanga.nu
Wed Aug 1 20:46:21 CEST 2001


John Buehler <johnbue at msn.com> said:

> Algorithmic generation of terrain produces perfectly wonderful
> results.  You just have to work on the algorithm.  You don't stop
> with fractal generation.  You alter the algorithm in different areas
> and at different fractal levels.  You make the vegetation type
> dependent on latitudes, altitudes, inclines and general locations.
> The same with the wildlife.  Run a simulator to produce an
> expansionist empire that then collapses and leaves ruins here and
> there.  Run batch generators to produce individual features that fit
> into the world terrain matrix, like caves, ruins and such.  To be
> honest, I haven't figured out an efficient way to handle flowing
> water.  I think it'll boil down to a batch simulator.

Sorry for the second reply, but this has gotten me started again.  There
are those on this list who may remember me for exactly this kind of wild
design...  and even some who have accused me of blue-sky naivite.  Those
people might be interested to learn, should they still lurk, that I have
secured myself a decent living pulling off this very kind of wild sceme,
albeit in a slightly more practical industry, on a regular basis.  When,
and I do me when, not if, I return to the games industry, I will be with
no qualms able to make these claims once more...

Sorry for the rant, but I just dealt with a scoffer in person, and have, 
at the moment, no interest in dealing with any here...  I've proved that
I'm capable, talented, and *cough* Russ Taylor, if you're still lurking,
I'm not fading away.  I don't need to spend my life or energy proving to
someone with a bruised ego that I am capable of doing something that has
been marked impossible by conventional wisdom, just because he says that
it can't be done, and therefore I must be a lier and a charlatan, and my
demonstration must be cooked somehow...

*ahem*

Anyway...

So on to simulation, and preservation of information at much lower cost,
at least in storage, than should be possible.  Or, as Moose and Squirrel
so aptly put it, Here's something we hope you'll *really* like:

How can a huge number of players share a far huger world, composed of an
expanse of wilderness, bits of settlement, and a handful of centers of a
sort of massive civilization, without taking up more memory and disk per
player than a small, hand crafted world?

One of the tricks is having a two way replicable seed for generating the
landscapes, affects and applied changes to the landscape, and predicting
changes over a span of time reliably.  This can be paired with a rot and
decay scour on a periodic basis of the seed modifier values used to keep
player changes... in short, that house you built will, unattended, slide
into rot and be grown over in time, and require less and less storage in
the disk store.  This means the place will still be there when a player,
be it the same one, another one he told about it, or another one entire,
happens to venture into that little valley - but it might not have much,
if any, of the huge library it originally housed on its shelves left.  I
suppose some of the state would have to be stored on masses of CD-Rs, if
you wanted protection against bugs, power failures, or other scramblings
of the database, but that's an implementation detail I haven't gotten to
yet: how to backup a world state and restore it.

Most of the random generation leads to an intense fractal tree with last
minute instantiation of nodes, and no true leaves... which allows both a
huge amount of generated/stored data mingling, and a reasonable means to
avoid doing a bunch of work that will never be appreciated.  Create that
rose only if someone stops to smell it... until then, it's a featureless
rose.

Anyhow, I'm glad to see this old discussion back out on the list.

--
Nathan F. Yospe - Physicist, Artist, Programmer, Writer, JOAT with a SAK


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



More information about the mud-dev-archive mailing list