[MUD-Dev] Self-Sufficient Worlds

Zak Jarvis zak at voidmonster.com
Sat May 20 12:33:09 CEST 2000


> From: Lee Sheldon [linearno at gte.net]
> Sent: Saturday, May 20, 2000 6:51 AM

> Can we literally take the seeds: A character here, a character
> there, some situations, conflicts, resentments, etc. and simply
> stick them in our world, and let nature, the world, and the
> players, run their natural course?  I think so.

I *know* this method can work in smaller scale games. I've seen it happen
and been a part of the stories that were being told. It was indeed a
supremely satisfying experience, and it served to get me into this whole
field to begin with.

However.

I don't think it's a tenable option for truly large scale games. The
resources required are simply unreasonable. See my earlier post for a
sketch of a method I think will work.

http://www.kanga.nu/archives/MUD-Dev-L/2000Q2/msg00714.html

The earlier messages I've seen arguing against widespread use of
storytelling programs seems to make the fundamental assumption that a
storytelling program *must* use language to tell a story. It's the same
underlying assumption of 'Artificial Intelligence and Literary Creativity'
(which I'm still slogging through). It's also wrong.  For the foreseeable
future, language is going to be the Achilles heel of the designer creating
automated systems like this. That's why I'm proposing sidestepping it
entirely. We don't need language to tell stories, and furthermore, when
designing a system like this you can actively leverage the huge pool of
language resources between the ears of your players.

I wouldn't believe in story generators either if I thought they had to come
up with dialogue, descriptions or any textual output that had more meaning
than a street sign.

> One last thought.  You can also find -bad- examples of this in
> "Twin Peaks" and "The X-Files" where the seeds have sprouted
> all out of control of the planters, and -they- are not sure
> how everything connects.  Of course the creators of these
> shows approached the problem linearly, and it only got
> worse.  We have far more opportunity to adjust in our worlds,
> which makes me think what is a danger in linear fiction, may
> be an absolute plus for us.

I'm not completely sure Twin Peaks exactly grew out of control, I think it
has more to do with Lynch being a very odd person and that he wanted to see
how twisted and funky his seeds would grow if left alone -- but your point
is very good. It leads back into the anecdote Raph Koster brought up from
'Hamlet on the Holodeck' (which I ought to be reading instead of this book
on AI storytelling, really).

I strongly suspect that what is likely to make for the best player
experience won't be necessarily the best experience for the audience (IE,
the non-involved players). In the game I'm working on right now (which is a
much smaller scale game than the stuff I tend to rant about), one of the
things we have planned is a 'Casting Call'. Essentially, when there's some
big-assed shindig and it only involves a handful of players, before the
event occurs we're going to let the non-involved players try out for and
get supporting roles (usually as extras, perhaps sometimes even minor
parts). If the stalwart adventurers must break through an enemy stronghold
guarded by a buttload of little critters, we'll cast other players to be
the little critters. If the players must travel by boat to a far off city,
we'll cast pretty much everyone else to be crowds.

Of course in my oh-so humble opinion, The X-Files should have ended when
they had to recycle their first supernatural phenomenon. Really, there are
only so many variations you can do on vampires before it gets really
absurd. If the show continues, I have no doubt that we'll see tonsil, uvula
or phalangeal vampires. Just hope there aren't any cowpers or bartholins
vampires... Sadly, with Carter's hobbies, the latter two are more likely.

-Zak Jarvis
 http://www.voidmonster.com





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



More information about the mud-dev-archive mailing list