[MUD-DEV] Ideas for dynamically generated worlds

Cynbe ru Taren cynbe at muq.org
Fri Dec 17 12:12:18 CET 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-archive mailing list