1997Q4/
<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD&#45;Dev]  Reusable plots for quests -->
<!--X-From-R13: "Fenivf Qnfrl" <rsvaqryNcbynevf.arg> -->
<!--X-Date: Sun, 19 Oct 1997 20:40:43 +0000 -->
<!--X-Message-Id: 199710192040.QAA02142#polaris,net -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev]  Reusable plots for quests</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:efindel#polaris,net">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
      text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">

  <font size="+4" color="#804040">
    <strong><em>MUD-Dev<br>mailing list archive</em></strong>
  </font>
      
<br>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->

Date:&nbsp;
[&nbsp;<a href="msg00126.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00128.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Thread:&nbsp;
[&nbsp;<a href="msg00126.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00135.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Index:&nbsp;
[&nbsp;<A HREF="author.html#00127">Author</A>
&nbsp;|&nbsp;<A HREF="#00127">Date</A>
&nbsp;|&nbsp;<A HREF="thread.html#00127">Thread</A>
&nbsp;]

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev]  Reusable plots for quests</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: &lt;<A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A>&gt;</LI>
<LI><em>Subject</em>: Re: [MUD-Dev]  Reusable plots for quests</LI>
<LI><em>From</em>: "Travis Casey" &lt;<A HREF="mailto:efindel#polaris,net">efindel#polaris,net</A>&gt;</LI>
<LI><em>Date</em>: Sun, 19 Oct 1997 16:39:01 -0400</LI>
<LI><em>Reply-To</em>: "Travis Casey" &lt;<A HREF="mailto:efindel#io,com">efindel#io,com</A>&gt;</LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
Brandon J. Rickman &lt;ashes#pc4,zennet.com&gt; wrote:
&gt;On Sat, 11 Oct 1997 22:58:39 PST8PDT "Travis Casey"
&gt;&lt;efindel#polaris,net&gt; wrote:
&gt;&gt;Brian Price &lt;blprice#bedford,net&gt; wrote:

&gt;First a brief nitpick about the use of terms like "story", "plot", and
&gt;"quest".  It seems to be clear that a story is, generally, made up of
&gt;plot elements.  (There is a storytelling software package that avoids
&gt;the absolute definition of "story" by defining something called a
&gt;"story argument", the latter being a subset of the former.)  But the
&gt;plot of a story is more of an after-the-fact detail.  The Troll King
&gt;actually kidnapped Princess Shortcake because he was in love with her,
&gt;and Our Hero rescues the Princess because her father, King Shortcake,
&gt;hates Trolls.  The plot elements of the story may not make sense, until
&gt;the whole story is finished.  In the traditional mud quest there is a
&gt;clearly defined goal or solution to the story.  But a Hero, by dealing
&gt;with the plot elements, may end up with an interesting story yet
&gt;fail to solve the "quest".  One way to rescue the Princess would be to
&gt;form an alliance between the trolls and King Shortcake.  If the quest
&gt;was supposed to be "capture the princess and kill the Troll King" this
&gt;is a failed quest solution.

Well, I think of the "plots" more as things which help us to create plot
elements which *could* combine with the actions of the players to create
something resembling a traditional fantasy story -- that is, the "plot"
is simply a guideline to help the designer (whether human or automated)
choose a set of plot elements which *can* make sense once the story is
finished.  The outcome may not be that envisioned, and the storyline
may vary from that originally envisioned as well.  Indeed, I'd *expect*
both of those to vary, according to the individual players involved and
what else is happening on the mud at the time.

&gt;&gt;A mud, though, is more like a serial or a soap opera.  Since these
&gt;&gt;lack definite beginnings and endings, there's no need for them to
&gt;&gt;have subplots which "run with" particular plots.  Rather, secondary
&gt;&gt;plots can overlap primary plots in various ways and even with each
&gt;&gt;other.
&gt;
&gt;In a world where the stories are constantly returning to the same
&gt;state (a local climax) or some endless permutation of storylines
&gt;(soap opera) there seems to be a desire for a steady-state system.
&gt;These systems purport to be "interesting" but they have great
&gt;potential to be tedious and dull.  It is, I would argue, the personal
&gt;involvement with the story or the vicarious enjoyment of the story that
&gt;needs to be emphasised.  Rather than the "man learns a lesson" plot, which
&gt;is the most common story in muds already, think about the "man is a
&gt;seemingly insignificant pawn" plot:

I'd argue about "man learns a lesson" being common in muds, but that's
probably outside the scope of this list.  :-)

&gt;You are a messenger.  Your master, some local noble, gives you a message to
&gt;take to the king.  You must travel many miles, deal with road bandits,
&gt;outsmart greedy innkeepers, and perhaps "learn a lesson" before you can
&gt;deliver the message.  Maybe there isn't even a "big" plot associated with
&gt;the message, it is just some routine correspondence.  But the messenger
&gt;doesn't know that (and, in my world, the _game_ doesn't know either) until
&gt;the message is lost or stolen and a plot breaks out.  Whatever overall
&gt;story there is involves several characters, and none of them know every
&gt;detail of the story.

I agree that there should be overarcing plots on a mud.  However, I
believe that such plots should be designed by a human rather than
automatically generated.  Since we've been discussing automated "quest"
generation, I haven't been mentioning them.

IMHO, a mud should not have a "steady-state" position -- if it does, then
the players can't really change the world in any significant way, and all
their actions are for naught.  While this might be realistic, it's
definitely
not fitting in the heroic mold.  (Of course, if your mud isn't supposed to
be in the heroic mold, it may be appropriate for the actions of the PCs to
never have any significant effect.)

The sort of plots that we're talking about generating automatically should
be fitted into one of the overarcing plots where possible.  That's one of
the reasons that I suggested having a human look at the automatic plots and
be able to modify them -- a human can supply the high-level, long-term view
of where you want the mud to go more easily than any software can.  That
human can then "adopt" some plots into the overarcing plot(s).

&gt;&gt;&gt;One difference between a novella and a novel is the drastic reduction
&gt;&gt;&gt;with the novella form in the number of seemingly inconsequential
&gt;&gt;&gt;events interspersed throughout main and sub-plot alike.  These events
&gt;&gt;&gt;can be described as random events or micro-plots.  These micro-plots
&gt;&gt;&gt;typically have a scope of only a single scene and have only minor
&gt;&gt;&gt;relevance to any sub-plot or master plot serving mainly to add color
&gt;&gt;&gt;although occasionally affecting plot direction.
&gt;&gt;
&gt;&gt;For similar reasons, I think it possible to leave out random events --
&gt;&gt;however, it may be a good idea to throw them in anyways, since there's
&gt;&gt;less of a problem with creating ones which are thematically appropriate.
&gt;
&gt;I don't know what these "random events" are that you would like to leave
&gt;out.  A random die roll?  A random encounter?  Random weather?  A random
&gt;venerial disease?  A random sub-quest to find cheese for a mouse?
&gt;
&gt;Which is easier: taking a big story plot and breaking it down into lots of
&gt;little bitty plot details, or taking lots of itty bitty plot details and
&gt;putting them together into a big story plot?  Making up a big plot based
&gt;on details could be called a conspiracy theory.

I think the original poster was talking about random story events which
don't have anything to do with the plot.  These could be encounters,
barroom brawls, false clues, etc.  IMHO, most of these things will
happen anyways, because the mud has more than one storyline happening at
once -- therefore, a player who's attempting to follow a given storyline
will run into things that aren't directly relevant to his/her storyline
without them being explicitly added.

IMHO, the "making up a big plot based on the details" is the responsibility
of the humans running the mud -- it's not really something well-fitted to
automation.  My basic thrust is that since such details will happen anyways,
there's little need to have random quest-generation software add them.

&gt;&gt;Adapting this to a mud seems fairly easy -- simply pick a generic plot,
&gt;&gt;randomly pick items that match the types needed by each slot (i.e.,
&gt;&gt;NPCs, objects, places, etc.), and then place items where they need to
&gt;&gt;go for the plot to be viable.
&gt;
&gt;This always implies some kind of directed activity on the part of the
player,
&gt;i.e. players are obligated to go on "quests" where they must perform some
&gt;"action".  I think an open-entry fishing competition would be more
&gt;interesting.

Personally, I prefer the idea of "implicit quests."  That is, rather than
having an old LP-style situation where there are certain known quests, and
it's made explicitly clear that the players are expected to follow these
quests, have a world in which things are happening and the players are free
to choose whether or not to get involved.

That's probably not too clear, so let me put it another way.  As much as
possible, I'd like the world to seem like it's real to the players.  Having
quests which are created, announced, and known to exist as quests works
against this -- it's blantantly obvious that such quests are artificial
constructs, meant purely as hoops for the characters to jump through.
Instead of announcing quests via out-of-game mechanisms, quests should be
worked into the game in such a way that they appear natural.  For example,
the characters might come into one of the mud's villages to find that it's
been burned to the ground, then discover something (a lone survivor, runes
scratched in the dirt, whatever) that lets them know that the Red Hand
orc tribe was responsible.  It's then up to the players to choose what to
do, without any "quest info" or other such things being available.

Of course, doing this in a way that will seem real requires one-shot events
and a mud that will change over time -- if the village comes back as soon
as the "quest" is solved, or if more than one group can run across the same
dying old man and get information from him, the illusion of reality is
spoiled.

&gt;There was once a game on the C64 called Adventure Construction Set, made by
&gt;Electronic Arts.  There were two prebuilt adventures, and the construction
&gt;set, plus an option to let the program generate its own adventure games
&gt;for you to play.  This took an ungodly amount of time (probably half an
&gt;hour to generate a "short" adventure) and the adventures were always
&gt;"If you bring me X I'll give you Y," quests.  These adventures, needless
&gt;to say, became quite predictable (and further suffered from speed and
&gt;memory limitations of the 64).  But it was quite a brilliant game for
&gt;the time.  I can't remember why I wanted to bring this up.

Probably because these seem to be the dominant type of quests on many
muds.  They're good for players looking for a simple adventure, because
there's a definite goal and a definite way to reach it.

This stands in contrast to an "organic" quest like the burned village I
described above.  What is the party supposed to do?  Try to hunt down the
orcs and avenge the village?  Are there survivors who should be rescued
from the orcs?  Are the orcs planning other raids that need to be defended
against?  Is it possible that someone else performed the attack and has
left fake evidence to point to the orcs?

A well-built "quest" should be able to go in many different directions
depending on the actions of the players.  However, such a "quest" is harder
to create than a simple linear quest, and demands more from the players.
Thus, these will probably always be less common on muds than the "go to X,
get Y and bring it to Z" type quests.

&gt;&gt;Example:  Let's say that the randomly selected plot is "rescue someone."
&gt;&gt;It's slots are "who to rescue," "who to rescue them from," "where are they
&gt;&gt;being held," and "where to return them to."  "The princess Esmerelda"
might
&gt;&gt;be randomly chosen for who and "the evil wizard Dolor" for who from.
These
&gt;&gt;choices might then force "a cell in Dolor's castle" to be used for where
&gt;&gt;from, and "King Varain's castle" to be used for where to.
&gt;
&gt;How does the character figure out the story?  Do they have to do a brute
&gt;force search of Dolor's castle?  And most important, is the intended
&gt;solution to have the character defeat the evil wizard Dolor?  Maybe you
&gt;would want to customize the story around the player, a thief or a wizard
&gt;might solve the story in different ways.

IMHO, the story should be able to go in many ways, depending on the actions
(or lack thereof) of the players.  A few quick ones with the example:

- It's possible that no players will choose to "take up" the quest.  Thus,
  there should be some sort of time limit after which something else will
  happen -- the king might pay the ransom and have the princess returned,
  or the king might pay the ransom and Dolor might simply kill the princess
  and keep the money, or the king might send some of his own knights to
  try to rescue the princess, etc.  Some would consider this a failed
  outcome, but I wouldn't -- even if no players get involved in the story,
  the fact that things can happen without the players getting involved
  will make the world seem more real.

- The players might enter Dolor's castle and do a brute force search for
  the princess, killing anyone who gets in the way.  (They know that Dolor
  has the princess, since the ransom note said so.)  If the princess is
  there, they'll undoubtedly find her, provided they can survive long
  enough.

- Since these are supposed to be reusable elements, it's possible that
  other players may have been in Dolor's castle before.  Thus, the players
  might choose to find another player who knows the inside of Dolor's
  castle and either hire him/her as a guide or get information about Dolor's
  castle from him/her.

- It's also possible that the players might choose to use stealth.  They
  might disguise themselves as some of Dolor's henchmen and seek to enter
  the castle that way, or they might try to bribe some of Dolor's henchmen.
  For this to work, of course, the designer must have either anticipated
  the possibility or there must be someone available who can control the
  actions of the NPCs on the fly.

Of course, there are plenty of other possibilities.  Maybe Dolor is
keeping the princess somewhere else.  Maybe Dolor doesn't actually have
the princess, but someone wants the king to think he does.  Maybe the
princess has fallen in love with Dolor, and the two of them are scheming
together to get money from her father before they leave to start their
new life together.  And, of course, there's a near-infinite variety of
actions the players could take.  To really allow for the full gamut of
possibilities, it would be best if someone could be assigned to watch
what the questers are doing and provide reasonable reactions to unexpected
situations.

&gt;Here is a story: everyone is on a quest for a magic object.  Along the way
&gt;many of them are told that the object has already been found, or doesn't
&gt;actually exist.  Eventually someone finds the object but it is too late:
&gt;the kingdom has fallen into ruin, the object doesn't work they way it was
&gt;supposed to, and all the important characters die.
&gt;
&gt;The theory here being, as the storyline has an increasingly significant
&gt;affect on the world the potential lifespan of the world gets shorter.
&gt;If King Shortcake has all the Trolls killed there might not be anything
&gt;interesting left to do in the world (for the next dozen years).  Is
&gt;that the end of the mud?  Shouldn't it be?

I agree that such stories need to be possible, as I think my comments
above will indicate.  I do know, however, that I'd be hesitant to create
a storyline which might end the mud (unless I was getting tired of
running it).   :-)
--
      |\      _,,,---,,_        Travis S. Casey  &lt;efindel#io,com&gt;
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
     |,4-  ) )-,_..;\ (  `'-'        rec.games.design FAQ:
    '---''(_/--'  `-'\_)      <A  HREF="http://www.io.com/~efindel/design.html">http://www.io.com/~efindel/design.html</A>



</PRE>

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00143" HREF="msg00143.html">Re: [MUD-Dev]  Reusable plots for quests</A></strong>
<ul compact><li><em>From:</em> coder#ibm,net</li></ul>
<li><strong><A NAME="00135" HREF="msg00135.html">Re: [MUD-Dev]  Reusable plots for quests</A></strong>
<ul compact><li><em>From:</em> Adam Wiggins &lt;nightfall#user2,inficad.com&gt;</li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00126.html">Re: [MUD-Dev]  Reusable plots for quests</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00128.html">Re: [MUD-Dev] multiple intelligences</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00126.html">Re: [MUD-Dev]  Reusable plots for quests</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00135.html">Re: [MUD-Dev]  Reusable plots for quests</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00127"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00127"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev]  Reusable plots for quests</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00095" HREF="msg00095.html">Re: [MUD-Dev]  Reusable plots for quests</A></strong>, 
Travis Casey <a href="mailto:efindel#polaris,net">efindel#polaris,net</a>, Sun 12 Oct 1997, 02:09 GMT
</LI>
<LI><strong><A NAME="00096" HREF="msg00096.html">Re: [MUD-Dev]  Reusable plots for quests</A></strong>, 
Brian Price <a href="mailto:blprice#bedford,net">blprice#bedford,net</a>, Sun 12 Oct 1997, 13:08 GMT
</LI>
<LI><strong><A NAME="00098" HREF="msg00098.html">Re: [MUD-Dev]  Reusable plots for quests</A></strong>, 
Brandon J. Rickman <a href="mailto:ashes#pc4,zennet.com">ashes#pc4,zennet.com</a>, Mon 13 Oct 1997, 00:09 GMT
</LI>
<LI><strong><A NAME="00126" HREF="msg00126.html">Re: [MUD-Dev]  Reusable plots for quests</A></strong>, 
Travis Casey <a href="mailto:efindel#polaris,net">efindel#polaris,net</a>, Sun 19 Oct 1997, 19:57 GMT
</LI>
<LI><strong><A NAME="00127" HREF="msg00127.html">Re: [MUD-Dev]  Reusable plots for quests</A></strong>, 
Travis Casey <a href="mailto:efindel#polaris,net">efindel#polaris,net</a>, Sun 19 Oct 1997, 20:40 GMT
<UL>
<LI><strong><A NAME="00135" HREF="msg00135.html">Re: [MUD-Dev]  Reusable plots for quests</A></strong>, 
Adam Wiggins <a href="mailto:nightfall#user2,inficad.com">nightfall#user2,inficad.com</a>, Tue 21 Oct 1997, 08:51 GMT
</LI>
<LI><strong><A NAME="00143" HREF="msg00143.html">Re: [MUD-Dev]  Reusable plots for quests</A></strong>, 
coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Thu 23 Oct 1997, 17:05 GMT
<UL>
<LI><strong><A NAME="00150" HREF="msg00150.html">Re: [MUD-Dev]  Reusable plots for quests</A></strong>, 
Travis S. Casey <a href="mailto:efindel#io,com">efindel#io,com</a>, Fri 24 Oct 1997, 18:30 GMT
<UL>
<LI><strong><A NAME="00152" HREF="msg00152.html">Re: [MUD-Dev]  Reusable plots for quests</A></strong>, 
coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Sun 26 Oct 1997, 06:08 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
</ul>
</LI>
</UL></BLOCKQUOTE>

</ul>
<hr>
<center>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
</center>
<hr>
</body>
</html>