[MUD-Dev] Wilderness
Ola Fosheim Grøstad <olag@ifi.uio.no>
Ola Fosheim Grøstad <olag@ifi.uio.no>
Thu Aug 2 15:24:27 CEST 2001
"Nathan F. Yospe" wrote:
> John Buehler <johnbue at msn.com> said:
>> 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.
> 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
The problem is more like: why do it? Designers want control, and
quite frankly designers are going to produce more interesting areas
than any general algorithm can produce. Yes, there are some
interesting algorithmic artworks, but such art typically has been
guided and selected by a rather patient artist in a rather
inefficient fashion... In the near future I think the role of such
approaches will be limited to fill-ins of designed structures.
Constraint style "paint tools" with various generators seem to be
much more useful for content generation that is actually worth
experiencing if used carefully. For instance, computer generated
ruins are plastic, a complete and utter waste of symbols. They
don't carry meaning. A designed ruin, however, may fit in the
greater plot. It is also a
high-potential-for-finding-a-unique-dungeon area. There are lots of
fractal exploration programs, but how much fun are they, really?
Actually, I think one of the strong points of (the mid beta)
Meridian59 from a user's perspective was that everything was
_designed_ with very little reuse of elements. Each place was a
place, it was unique. Users were inclined to search every minor
detail in order to find some secret. They would look for meaning
where there was no meaning. (Too bad the game world itself was so
static though) With a specific game system in mind you can design
each area to support different types of strategies. Ok, so it is
expensive to develop, but it certainly is more FUN than these
churn-out-as-much-land-as-possible designs that are typical. This
is not to say that you cannot do this algorithmically, but you have
to take a different approach from the one that I believe has been
argued in this thread.
--
Ola - http://www.notam.uio.no/~olagr/
_______________________________________________
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