[MUD-Dev] Wilderness
Ola Fosheim Grøstad <olag@ifi.uio.no>
Ola Fosheim Grøstad <olag@ifi.uio.no>
Sat Aug 4 03:36:45 CEST 2001
Hans-Henrik Staerfeldt wrote:
> On Thu, 2 Aug 2001, Ola Fosheim Grøstad wrote:
>> 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.
> The reason I see to do it is to provide much contents with little
> (or at least less) work. Also as pointed out in earlier posts, it
> provides a method for storing contents using much less space.
Uhm, but disks are at 100GB. You are better off spending that
computational power doing spatial intersection tests. :) A couple of
more years and they are at 1TB.
What I personally think algorithmic content is good for is not
storage at all, but bandwidth and visual object configuration. Not
large scale world design, but for smaller elements. Well, unless you
link the world-generator intimately to the game system. (that could
give the content some potential meaning)
> I do agree that we are yet to see fractally generated contents
> that match that of the designed. However the distinction is
> becomming less and less obvious.
What makes you say so? :)
[on NWN:]
> interactively take part in. Some may call this a 'quest', but the
> important thing is that the design tools need to provide the
> designers with a functionality that lets them tell this story.
Yes. So they need to be able to architect a sequence of events, and
place "signs" in the landscape. I don't doubt that creating the
story with fractal terrain generators is good entertainment, but I
am not convinced that it will improve the player experience to any
substantial degree. IMO a good story will stay within a limited set
of "places".
> Using fractal generation, would enable the designer to make
> large-scale design decitions when creating contents. For instance
> the creator could tell the design tool to generate a small
> village, and it would do this right down to the name of the local
> inn.
Uhu, but that village will be deprived of identity that is relevant
to the story, if that story is anywhere near original and worth
experiencing. It might make sense in the NWN setting though, but in
a semi-professional context we would assume that the designer is
actually capable of designing?
> The key now is to provide tools that let the designers move a step
> toward the generation algorithm, and let them use the algorithms
> to generate their contents in a way that lets it be
> permutable. This way their work can be immediately incorperated
> several places instead of just one, and thus produce varied yet
> unique contents for the game.
Well, I guess, but this sounds very much like procedural modelling.
And now you will have the same problem that programmers have, making
things seamlessly reusable often cost more than you gain. I believe
you would need some constraint based system on top of this, but then
the task of the algorithmic content is filling in the details. Which
is basically what I argued for in the first place (and have in the
past as well).
It's not that I don't understand the vision, it isn't exactly a new
one, I just think it is a _lot_ more complicated than it sounds if
your design is going to benefit from it. They have a long way to go
in making interesting algorithmic music, and world design is
definitively not easier
> To my knowledge, such tools are far from available presently, but
> that does not mean that such a solution is not viable. First stage
> would of course be to develop a fractal algorithm that would be
> easily expandable with new rules.
Hmm... I believe the most successful application of algorithmic
content is to use it as raw material which then is stitched together
in a collage. The human brain is very good at detecting lack of
variation and novelty. (not to say that h&s muds have much variation
and novelty) I doubt that machines will ever be good at that, they
seem to lack the necessary context.
> I see at least one way that would start moving the technology from
> the designers to the fractal algorithms, and that would be to do a
> machine- learning approach (or human analysis) to already
> generated, fixed designs, and let that discover the variation
> seen. Such as someone mentioned, rules such as 'this type of door
> goes well with this type of house in this envonment' etc. Not an
> easy task, but perhaps a beginning.
Yes, this is possible. But then you have to settle on a particular
vocabulary. I believe there is some success in generating music that
sounds like Bach, but then you are limited to the elements he uses.
(I.e. you can probably not use the same engine to generate
contemporary music which plays on atonality and the "colour" of the
sound)
There are lots of games that seem to use some kind of algorithmic
world design though. Even really old games like Artillery Duel (kind
of like Worms), Populous, Elite, Sentinel... and I believe one
norwegian flightsim even used IFS (Iterative Function Systems).
Still, in existing MUDs the quality problem does not seem to be
related to having too small worlds or a lack of realism or fractal
dimensions or any such thing, but a lack of skilled and meaningful
design that carefully blend esthetics with game elements.
--
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