[MUD-DEV] Ideas for dynamically generated worlds
Cynbe ru Taren
cynbe at muq.org
Fri Dec 17 12:12:18 New Zealand Daylight Time 1999
I've been collecting ideas of my own along these lines for some
years. Here are some of them. Reader should pick out anything
locally useful and discard the rest. :)
* In general, these ideas are easier to handle in 3D graphics
worlds than in text worlds.
Why?
Because as a many posters have implicitly noted in various
ways, dynamic world generation tends to generate huge amounts
of detail when left to itself.
In a 3D graphics world, this is ok: Rendering down to the pixel
level is visually acceptable, and cutting back to some fixed
angular level of resolutions is acceptable and easy to implement.
By contrast, text descriptions must discard orders of magnitude
more information, pruning down to the absolute bare essentials
of a scene in very intelligent fashion.
In short, the 3D graphics version can be handled by brute force,
but the text version requires "intelligence", and current computing
technology is much better at brute force than "intelligence" -- as
witness Deep Blue's design.
* Pushing dynamic world generation very far takes one beyond well
established programming paradigms in pretty short order, at least
if you think hard about it and try to generate really good
solutions.
Whether this is good or bad is of course purely in the eye of the
beholder! :) I think it is great -- I like each new project to
teach me something new about programming.
In particular, conventional programming uses very minimal context
at each step and proceeds by Boolean decisions. In my explorations
at least, dynamic world generation builds and uses large amounts of
information expressing the current context -- geometry, culture,
language, whatever you're interested in -- and has to sum it in
ways much more sophisticated than the conditional Boolean expreesions
typical of contemporary programming: The resulting mechanisms have
much more the flavor of quantum mechanical summing of probability
waves followed by collapse to a particular output at some point by
picking a specific outcome based on the final probability function.
* For many sorts of geometry, I believe "fractal" (I use the term loosely
here) distortions of regular constructions turn out in my opinion
to be more practical than straightforward fractal constructions.
Example: You can specify a fractal road network, but given a point
in space, it will become very expensive to find out whether there
are any roads in the scene.
Instead, you can start with a construction placing roads
where-ever max(sin(ax),sin(by)) > 0.99, say: This gives you a
rectangular grid of roads of finite width with the advantage that
you can tell for any point about how close it is to the nearest
road, and in what direction, just by looking at the field value
and gradient before the max() is applied.
Now, you can distort this regular construction in fractal fashion
by using something like Perlin's classic noise() function to do a
space-to-space remapping.
The result should look pretty fractal, but possess various nice
properties: In particular, finding whether there is a road at a
given point in a scene is now a constant-time operation -- just
invert the noise() mapping and apply the above function.
Obviously, this can be elaborated to include major and minor
road networks and towns at road intersections and non-rectangular
base geometries and such to taste.
Example: A good river network is hard to do. You will usually
want the rivers stay close to the surrounding terrain, flow
downhill, not start or stop mysteriously, and flow to the ocean,
by and large. (Any or all of these constraints can of course be
violated for creative reasons -- rivers in the sky or whatever.)
Doing this efficiently from first principles is hard.
But it is relatively easy to construct a canonical regular
river basin following emperically established river statistics:
A very simple try may have a radial geometry consisting of a number
of rings, each containing twice as many radial river segments as
the previous one, running in a strict pattern of one bifurcation
per ring, joining at ring edges. This will again allow one to
map a given (x,y) to the closest river in constant time using a
little polar geometry.
Again, using a noise function to remap this basis geometry
irregularly onto the actual world geometry may give a reasonably
realistic result while remaining efficient to generate.
Example: An island will usually want to have a port by the ocean,
paths or roads following the coast much of the way, and likely a
central peak or two.
Doing all this with straight conventional fractals will be an
expensive pain: Just determining whether something is an island
or not will require tracing the complete coastline, likely, ditto
laying out the coastal roads and locating an appropriate harbor
shaped piece of coast outline for the port.
Instead, one can generate a canonical conical island with
central peak, circular coast and coastal road, and semi-circular
harbor cutout. All the connections make sense by construction
now, and a noise()-driven remapping can give each island realistic
fractal individuality.
The archipelago itself can start as a rectangular or triangular
mesh of island vertices connected by boating routes, with
positions noise()-remapped to look more realistic.
[ Whoops, got to run. Maybe a few more from the stockpot some
other time. -- Cynbe ]
_______________________________________________
MUD-Dev maillist - MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the MUD-Dev
mailing list