[MUD-Dev] Reusable plots for quests

Travis Casey efindel at polaris.net
Sat Oct 11 22:06:50 CEST 1997


Brian Price <blprice at bedford.net> wrote:

For the most part, I just have some random ramblings on what Brian wrote...
towards the end, though, I've got some thoughts about actually implementing
a plot generator:

>A story can be expressed as a combination of three plot scopes;  the
>master plot, the sub-plot, and the random event (or micro-plot).  A
>master plot consists of a dozen or more significant scenes spread, on
>average, widely through the story's time and space.   Generally, the
>master plot begins near the beginning of the story and continues
>through to the end.  The master plot is the main story line.

I don't really think we need all of these story elements on a mud.
Subplots aren't always needed -- many short stories don't have a
subplot, for example.  In longer stories, subplots can serve any
number of purposes -- usually, though, they serve to provide a
parallel or a counterpoint to the primary plot.  To serve these
purposes, though, the subplot would have to be constructed carefully
in parallel with the main plot, rather than being randomly chosen.

A mud, though, is more like a serial or a soap opera.  Since these
lack definite beginnings and endings, there's no need for them to
have subplots which "run with" particular plots.  Rather, secondary
plots can overlap primary plots in various ways and even with each
other.

Further, since a mud has many "primary" plots running at once, a
character might be involved in a leading role in one plot and at the
same time be in a secondary role in another plot.  From the point of
view of that player's "storyline," the first is a primary plot and
the second is a subplot -- but the positions may be reversed from the
points of view of other player's stories.

Lastly, one of the traditional areas for subplots is the relationships
between characters.  In this area, mud players will generate their
own subplots without any help.

What I'm getting at is that a mud generates subplots simply by virtue
of having multiple players interacting with multiple plotlines.  Thus,
I don't think there's a real need to explicitly create subplots.  I
also think that creating an automatic plot-generation system which
could create subplots which are thematically appropriate to the major
plots they are matched to would be *very* difficult.

[some cut]

>One difference between a novella and a novel is the drastic reduction
>with the novella form in the number of seemingly inconsequential
>events interspersed throughout main and sub-plot alike.  These events
>can be described as random events or micro-plots.  These micro-plots
>typically have a scope of only a single scene and have only minor
>relevance to any sub-plot or master plot serving mainly to add color
>although occasionally affecting plot direction.

For similar reasons, I think it possible to leave out random events --
however, it may be a good idea to throw them in anyways, since there's
less of a problem with creating ones which are thematically appropriate.

>A somewhat arbitrary choice of basic plot elements can be made to form
>the common set of plot elements.  The current plot element node logic
>theorem holds that these elements can be defined as setting,
>character, information, features, and events.  The element setting can
>be described as the physical surroundings in which the scene occurs.
>The character element consists of the characters and creatures which
>are within the setting during the time the scene occurs.  The
>information element consists of knowledge which may be obtained by or
>imparted to a character from some other element during the course of
>the scene.

This reminds me strongly of a method which has been used to generate
random stories created by a computer.  Here's the basic outline:

- First, a general "plot" is randomly selected.  These plots are
  *very* general -- along the lines of "find and retrieve something,"
  "help someone achieve a goal," etc.

- Each of these general plots has an associated set of "slots" which
  must be filled to generate the specific plot.  For example, for
  "find and retrieve something," the "slots" might be "what to retrieve,"
  "from where," "where to return it to," and "obstacles."  (Note that
  some "slots" might have more than one thing in them -- for example,
  the general "find and retrieve" plot might specify that 1 to 4
  obstacles should be chosen.)  Also, the choices made for some slots
  may restrict what choices can be made for other slots.

- The story is then built using this information.  At some points,
  "substories" might be inserted -- for example, the story of how
  a particular obstacle was overcome.

Adapting this to a mud seems fairly easy -- simply pick a generic plot,
randomly pick items that match the types needed by each slot (i.e.,
NPCs, objects, places, etc.), and then place items where they need to
go for the plot to be viable.

Example:  Let's say that the randomly selected plot is "rescue someone."
It's slots are "who to rescue," "who to rescue them from," "where are they
being held," and "where to return them to."  "The princess Esmerelda" might
be randomly chosen for who and "the evil wizard Dolor" for who from.  These
choices might then force "a cell in Dolor's castle" to be used for where
from, and "King Varain's castle" to be used for where to.

[It should be noted that the "setup" could be implemented in an "organic"
fashion -- that is, rather than simply moving Esmerelda to Dolor's castle,
the program could set things up for Dolor to go out and capture Esmerelda,
take her to his castle, send a ransom note to Varain, and then have Varain
put out a call for adventurers to free his daughter.  Making the plot
generator do things in such an "organic" fashion would be a lot more work,
but could be well worth it.]

Such a mechanism could work automatically, without any human intervention
being needed.  However, I personally think that it makes more sense to
have each potential plot that's generated be checked by a human.  The
human could (a) approve the plot, allowing the computer to go on and
automatically set things up for it, (b) turn down the plot ("Esmerelda
again?  She's already been kidnapped four times this year!") or (c)
partially
or completely take over the implementation of the plot, throwing in whatever
individual touches he/she thinks would make the plot better.

The human checker functions both as a quality control mechanism and to
provide the touch of creativity that the plot generator can't.  I think
it would be a good idea to have the plot generator do no "consistency
checking" -- what seems like it might not work could give a human an
idea for something that would.  For example, what if the program chooses
Esmerelda to be her own captor in the "rescue" scenario?  A creative
checker might be inspired to create a plot in which Esmerelda is getting
herself involved in something that she shouldn't be, and therefore must
be "saved from herself."
--
      |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
     |,4-  ) )-,_..;\ (  `'-'        rec.games.design FAQ:
    '---''(_/--'  `-'\_)      http://www.io.com/~efindel/design.html





More information about the mud-dev-archive mailing list