[MUD-Dev] Reusable plots for quests

[Brian Price]

I can easily see in retrospect where my original presentation was a 
bit misleading.  While the scope of the initial pnel theorem was 
intended to be a single-player game, my suggestion for muds is not 
to extend the theory to make a multi-player game.  Rather, I suggest 
it might be applicable to developing reusable quests for a mud.

As many of you have no doubt noticed, I find it difficult at times
to express my concepts in a clear and concise manner.  The pnel
theorem is indeed an example.  What I attempted to do with pnel was to
describe a set of rules for traversing an MxN matrix of nodes, where
the nodes are plot element nodes or story primitives.   If a story is
considered to be a path from the bottom row of the matrix to the top
row of the matrix, the number of permutations would seemingly be much
larger than M (approaching M^N).  If this is not possible/practical
then one may as well create M stories (a much easier task).

> From:          "Travis Casey" <efindel at polaris.net>
> Brian Price <blprice at bedford.net> wrote:
<snip> 
> >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
<snip>
> 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.

You've hit upon the major problem with implementing the original 
system as defined.  Frankly it is a very difficult task to construct 
the subplots even though a logic system is defined whereby 
incompatible sub-plots are excluded from the story's possibility sea.
It may have been hard to tell from my rambling explanation of the 
theory but none of the elements where randomly generated in the 
system described.  Rather they were randomly combined at run time 
according to the current state of the story from the set of 
non-excluded sub-plots and micro-plots under certain rules.  

< have to snip a bit here, basically I agree that it is improper
 (if not impractical) to apply the pnel theory to the mud story itself >

> 
> [some cut]
[some more cut]
> 
> 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.

It would be possible to leave out the random events but I believe 
this would be a serious mistake as it makes the result less complex 
to the observer (player).  The whole idea in a reusable quest 
mechanism utilizing a multi-plot approach is to overwhelm the player 
with the number of possible combinations.  Each pass thru is new and 
different, random events do much to help create the atmosphere which 
serves to disguise divergent points in the plots.

> >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.

Man learns a lesson :)
 
> - 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.

I see the similarity as well, these slots sound very much like the 
element associations/mappings used in my initial implementations.
 
> - 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.

In a pnel type multi-plot story, your stories and sub-stories 
developed as above would be mapped into the story's possibility sea 
as potential plots/sub-plots.  The story would not actually be 
built until run-time in an interactive manner with the PC/PC group.

> 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.

This is really the fork in the road in approaches to achieving 
reusable stories for quests vs. randomly generated quests.   A reusable 
story, using the multi-plot approach, achieves reusability through 
combinatorial complexity.  At a certain degree of complexity, it 
becomes indistinguishable to a human observer from a truly random 
plot generator.   The difference is that in the multi-plot approach, all 
aspects are guaranteed to be consistent and logical, once written and 
debugged, no further human intervention is necessary.  The writing 
and debugging, however, is a non-trivial task.  I'm very interested in 
the idea of generating the initial plots and sub-plots via a random 
generator along the lines which you describe as it would go far to 
reduce the abysmal burden upon the multi-plot story writer.

                   Brian Price
               <blprice at bedford.net>