[Adonthell-commits] CVS: doc/plot_guideline .cvsignore,NONE,1.1 Makefile,NONE,1.1 abstract.tex,NONE,1.1 activity.dot,NONE,1.1 documentation.tex,NONE,1.1 dot.tex,NONE,1.1 epstopdf.sty,NONE,1.1 example1.dot,NONE,1.1 example2.dot,NONE,1.1 example3.dot,NONE,1.1 keypoint.dot,NONE,1.1 main_plot.tex,NONE,1.1 mini.dot,NONE,1.1 nodes.dot,NONE,1.1 npc.tex,NONE,1.1 path.dot,NONE,1.1 plot_guideline.tex,NONE,1.1 side_quest.tex,NONE,1.1 structure1.dot,NONE,1.1

[Kai Sterker <address@hidden>]

Update of /cvsroot/adonthell/doc/plot_guideline
In directory subversions:/tmp/cvs-serv11342

Added Files:
        .cvsignore Makefile abstract.tex activity.dot 
        documentation.tex dot.tex epstopdf.sty example1.dot 
        example2.dot example3.dot keypoint.dot main_plot.tex mini.dot 
        nodes.dot npc.tex path.dot plot_guideline.tex side_quest.tex 
        structure1.dot 
Log Message:
ADDED plot design guidelines

--- NEW FILE ---
*.aux
*.log
*.toc
*.pdf
*.tgz
*.out
*.ind
*.idx
*.ilg
*.zip

--- NEW FILE ---
IMAGES = \
    structure1.eps \
    path.eps \
    activity.eps \
    keypoint.eps \
    example1.eps \
    example2.eps \
    mini.eps \
    nodes.eps \
    example3.eps
        
all: ${IMAGES}

pdf: ${IMAGES} *.tex
        pdflatex --shell-escape plot_guideline.tex

#%.pdf: %.eps
#       epstopdf $<

%.eps: %.ps
        ps2eps -f $<
        
%.ps: %.dot
        dot -Tps2 -o $*.ps $<

clean:
        rm -rf *.ps *.eps *.pdf

--- NEW FILE ---
\section{Abstract}

This document contains rules and guidelines for the designers of Adonthell's 
plot. It does \textbf{not} contain any information about the actual plot. It 
just deals with ways to create an interesting plot that adds to the overall 
gameplay and replay value of Adonthell. 

The first few sections deal with the main plot line, side quests and NPCs. The 
last part of the document deals with everything needed to put the plot to 
paper, including a short introduction to the \texttt{dot} tool.

Although some parts of this document are purely Adonthell-specific, it might be 
worth a read for everybody interested in the creation of role playing games. If 
you plan to help with Adonthell's plot however, please read the entire 
document. It will set you on the right track and answer many of the questions 
you might have. In brief: RTFM ;-).

--- NEW FILE ---
digraph activity {

 rankdir = LR;
 ratio = compress;

 node1 [label = "1.3  Put hamster\ninto microwave"];

}

--- NEW FILE ---
\section{Documenting the Plot}
In the previous sections we've seen rules and guidelines on how to design the 
plot. The remainder of this document deals with putting it to paper; so please 
read on if you are working on an ``official" game.

\subsection{Contents}
First of all, we have to sort out what belongs into the plot documentation. 
Basically, there are three different parts: {\it characters}, {\it locations} 
and {\it activities}.

\paragraph{Characters} that appear in the plot should be described in some 
fashion, no matter whether they are player or non player characters. As 
stressed above, NPCs need a background and various other traits. This will give 
the artists an impression of a character and will further aid writers with 
dialogues and plot design in general.

Character descriptions may be given in any form, in varying detail, depending 
on the character's importance for the plot.

\paragraph{The location} part covers the game world's appearance. Places 
required by the plot have to be described in any case, but other areas or 
landmarks may also appear. Therefore, this part will be the main source of 
inspiration for graphic artists and map designers. To give them the freedom 
they need, descriptions shouldn't include more details than necessary.

Locations can be described in text form, by sketches or maps. If a quest 
requires a location to have a certain layout, this should be pointed out, 
possibly together with a link to the description of that quest.

\paragraph{Activities} are the core of the plot documentation. They describe 
the player's options at any given point in the game. They should refer to 
locations and characters as needed. No difference is made between main plot and 
side quests.

The documentation is usually split into a graph showing the dependencies 
between activities and a textual description of each activity. As the plot is 
not strictly linear, and since many tasks can be accomplished in several ways, 
this will make the plot much easier to follow and to understand.

\subsection{Dependency Graph}
Textual information contained in the plot documentation has no special 
requirements regarding its form and appearance. This is different for the 
dependency graph however. As it is the glue for all the activity descriptions, 
it needs to follow a few conventions to be easily understandable and free of 
ambiguities. Below you will find the symbols explained that are used by the 
graph:

\paragraph{Paths} are the connection between two activities. They indicate that 
the activity at the path's origin needs to be completed before the player can 
carry on along that path. If additional requirements have to be met to follow a 
path, this can be indicated with an optional label. 

\begin{figure}[ht]
\center
\includegraphics[width=3cm]{path.eps}
\caption{Path between two Activities}
\end{figure}

Often, two or more paths will lead to the same activity. This usually means 
that a player has so many different alternatives to reach that point. Whether 
those alternatives mutually exclude each other, or whether they can be pursued 
simultaneously needs to be described in the actual activities. At present there 
is no way to include this information in the graph itself.

\paragraph{Activities} describe what options a player has if she wants to get 
on with the main plot or a side quest. Each activity has a unique numerical ID 
to easily identify the corresponding description and vice versa. It is further 
summarised with a few words. This should give readers a rough impression of the 
plot without having to refer to the textual descriptions.

\begin{figure}[h]
\center
\includegraphics[width=3.5cm]{activity.eps}
\caption{Second level Activity}
\end{figure}

An activity can describe a singular option of the player, or a group of options 
with roughly the same result. In latter case, a subgraph can be used to depict 
a group in detail on a lower level. That prevents the top level graph from 
becoming cluttered with all the little details. Here the ID can be useful to 
indicate the level and to determine the relationship between activities on 
different levels. It has the form $x$ on the top level, $x.y$ on the second, 
$x.y.z$ on the third and so on.

\paragraph{Key Points} denote important events that have to be passed by all 
players. All key points together form a linear storyline that summarises the 
different paths a player may take through the game. 

\begin{figure}[h]
\center
\includegraphics[width=2cm]{keypoint.eps}
\caption{Key Point}
\end{figure}

This story line should be placed alongside the top level graph. Activities 
taking place at a certain key point should be aligned with it. Should the top 
level graph ever become too large to handle, it can be easily split into 
several parts with the key points as delimiters.\\

In the future we might introduce further symbols, or use colour codes to add 
more information to the dependency graph. But for a start these three symbols 
are all we need.

\subsection{Example}
 
Now that we've seen the theory of documenting the plot, a complete -- albeit 
small -- example will certainly help to understand how it is supposed to work. 
Each part of the example is followed by a brief commentary, to highlight and to 
explain the most important features.

\floatstyle{boxed}
\newfloat{Example}{thp}{loe}

\begin{Example}[H]
\caption{Character description}
\center
\parbox{0.92\linewidth}{
\paragraph{The Wizard} has been one of the king's trusted advisors for many 
years -- until recently. In a vision he has seen the fall of the kingdom, 
should the {\sc Princess} ever follow her father onto the throne. After sharing 
his fears with his liege, he was banned and driven out of the castle. But being 
full of love for the kingdom, he carried off the princess on the spot, to 
imprison her in his {\sc Tower}.

\paragraph{The Princess} \ldots
\\
} 
\end{Example}

Note that the character description can become much longer and much more 
detailed. Usually, it should include name, race and approximate age of 
characters. It may also list what factions they belong to and what special 
talents they have. But for the sake of keeping this example as short as 
possible, those details have been omitted.

\begin{Example}[H]
\caption{Location description}
\center
\parbox{0.92\linewidth}{
\paragraph{Wizard's Tower} This is the home of the {\sc Wizard}. It sits 
inmidst a lake on a small island. Various exotic trees and bushes grow along 
the shore of the lake. There is no obvious path across the water.\\
}
\end{Example}

As long as the plot has no special requirements, a location's exact appearance 
should be left to the artists -- as is the case in this example. If a certain 
layout is needed however, it should be described in detail and accompanied by a 
sketch or map, if possible. In addition, one may want to contact artists and 
map designers directly, to make sure they are aware of any special wishes.

\begin{Example}[H]
\caption{Top level Dependency Graph}
\center
\vspace{5mm}
\includegraphics[width=12cm]{example1.eps}
\vspace{5mm}
\end{Example}

Since the dependency graph gives a good overview of the plot as a whole, it 
makes sense to place it before the activity descriptions. Of course this 
requires properly labelled activities, otherwise it might just lead to 
confusion. Especially when implementing the plot, a good dependency graph will 
make life much easier for developers.

\begin{Example}[H]
\caption{Dependency Graph for Activity 2}
\center
\vspace{5mm}
\includegraphics[width=12cm]{example2.eps}
\vspace{5mm}
\end{Example}

To make the top level dependency graph clearer, it might make sense to group 
several activities together. Here the top level {\sc Get into Tower} activity 
has been split into four nodes, and two different paths, on the second level. 
In case of our example, this is already sufficient. Larger plots might even 
require a third level, which should be the maximum number of subdivisions 
though.

On levels different from the top level, no key points are required. However, 
all `entry' and `exit' activities should be included. The IDs used in the 
subgraph easily allow to identify the top level activity -- no. 2 in this case. 

\begin{Example}[H]
\caption{Activity description}
\center
\parbox{0.92\linewidth}{
\paragraph{1\hspace{4mm}Intro} As one of the king's knights, the player is sent 
to rescue the {\sc Princess} from the {\sc Wizard's Tower}. The game starts 
with him arriving in the tower area.

\paragraph{2\hspace{4mm}Get into Tower} As the Princess is kept inside the 
tower, the first step is to get in there. There are multiple ways to accomplish 
this:

\paragraph{2.1\hspace{4mm}Kill Kraken} A deadly beast guards the lake that 
surrounds the {\sc Wizard's Tower}. If the player tries to swim to the other 
side, the kraken will catch and pull him beneath the surface. To kill the 
beast, he has to lure it near the shore and cut off its tentacles before they 
can reach and grab him.

\paragraph{2.2\hspace{4mm}Eat winged berries} \ldots
\\
} 
\end{Example}

The activities should be sorted alphabetically by their ID. Sub level 
activities should be inserted after the corresponding top level activity. The 
descriptions themselves should briefly cover the situation and then list the 
actions required to complete that activity. This can be done in form of a 
walkthrough, or in any other suitable way.

--- NEW FILE ---
\section{The {\tt dot} Tool}
This section introduces a program that greatly simplifies the creation of the 
dependency graph. Read on if you ever plan to work on that.

\subsection{Introduction}
Creating the dependency graph is possibly the biggest problem when documenting 
the plot. As it will undergo frequent changes and updates, an ordinary graphics 
package such as The Gimp or Photoshop isn't suitable for drawing the graph. 
Vector drawing tools are much more fitting, but they still force the user to 
manually arrange and connect nodes, making dependency graph maintenence a time 
consuming business. This is where {\tt dot} comes in, a lightweight command 
line utility that draws directed graphs from a textual description. It is part 
of AT\&T's {\tt graphviz} package\footnote{\sf 
\href{http://www.research.att.com/sw/tools/graphviz/}{http://www.research.att.com/sw/tools/graphviz/}}
 and freely available for various platforms.

\subsection{Examples}
To learn about all of {\tt dot}'s features you should refer to its user manual. 
But if all you want to do is creating plot dependency graphs, then the examples 
below should be enough to get you going. They all show a graph on the left and 
the code to create it on the right. 

\begin{Example}[h]
\caption{A minimalistic Graph}
\begin{tabular}{m{0.43\linewidth}m{0.49\linewidth}}
\centering\includegraphics[height=2.6cm]{mini.eps} &%
{\footnotesize
\begin{verbatim}
digraph minimalistic 
{
    n1 [label = "Node 1"];
    n2 [label = "Node 2"];
    
    n1 -> n2
};
\end{verbatim}
}
\end{tabular}
\end{Example}

The example above demonstrates the basic layout of a {\it .dot\/} file. They 
always start with the {\tt digraph} keyword, followed by a custom name for the 
graph. Two nodes are then defined and labelled accordingly. The last line 
finally creates an edge between those nodes.

\begin{Example}[h]
\caption{Node shapes and edge labels}\label{Example7}
\begin{tabular}{m{0.43\linewidth}m{0.49\linewidth}}
\centering\includegraphics[height=3.4cm]{nodes.eps} &%
{\footnotesize
\begin{verbatim}
digraph nodes
{
    rect [shape = polygon, sides = 4,
          label = "Rectangle"];
          
    none [shape = plaintext, 
          label = "Plain Text"];
          
    rect -> none [label = "Edge\nLabel"];
};
\end{verbatim}
}
\end{tabular}
\end{Example}

Example \ref{Example7} shows how to create nodes with different styles. Edges 
can have labels too, and `\verb+\n+' can be used to add custom linebreaks to 
any label.

\begin{Example}[h]
\caption{Key Points and node alignment}
\begin{tabular}{m{0.43\linewidth}m{0.49\linewidth}}
\centering\includegraphics[width=\linewidth]{example3.eps} &%
{\footnotesize
\begin{verbatim}
digraph complete
{
    start  [shape = polygon, sides = 4, 
            label = "Start"];
    wizard [shape = polygon, sides = 4, 
            label = "Encounter\nwith\nWizard"];
    end    [shape = polygon, sides = 4, 
            label = "End"];
            
    start -> wizard -> end

    intro  [label = "1 Intro"];
    git    [label = "2 Get into\nTower"];
    dw     [label = "3 Defeat\nWizard"];
    tuww   [label = "4 Team\nup with\nWizard"];
    fp     [label = "5 Free\nPrincess"];
    sp     [label = "6 Sacrifice\nPrincess"];
  
    intro -> git -> dw -> fp
    git -> tuww -> sp
  
    { rank = same; start; intro; }
    { rank = same; wizard; dw; tuww; }
    { rank = same; end; fp; sp; }
};
\end{verbatim}
}
\end{tabular}
\end{Example}

The last example finally shows how to add key points to the graph, and how to 
align them with corresponding nodes. That's what the last few lines are for.\\

Once you have created a {\it .dot\/} file, you can turn it into a PNG image of 
the graph by running {\small\verb+dot -Tpng -o image.png file.dot+} from a 
shell or DOS box.

\subsection{{\tt dot} and \LaTeX}

As seen above, {\tt dot} can produce pixel graphics of a graph. However, if we 
want to compile the plot documentation into a nice PDF file for example, vector 
graphics would improve the document's appearance considerably. Unfortunately, 
{\tt pdftex} cannot directly use any of the vector formats produced by {\tt 
dot}. But, as the {\sc Plot Design Guidelines} show, there is a way to convert 
its postscript output into something usable. The following guide assumes that 
you are using {\tt graphviz} 1.8.5 or later.

\paragraph{Step 1} Create the postscript version of the graph. This is done by 
invoking {\tt dot} with the following parameters:
{\small
\begin{verbatim}
    dot -Tps2 -o image.ps file.dot
\end{verbatim}
}

\paragraph{Step 2} Turn the {\it .ps\/} file into valid EPS format. This 
especially involves fixing the Bounding Box, i.e. the extensions of the graph. 
This can be achieved with a tool like {\tt 
ps2eps}\footnote{\href{http://www.tm.uka.de/~bless/ps2eps}{http://www.tm.uka.de/\~{}bless/ps2eps}}:
{\small
\begin{verbatim}
    ps2eps -f image.ps
\end{verbatim}
}

\paragraph{Step 3} Turn the {\it .eps\/} file into a format understandable by 
{\tt pdftex}, i.e. PDF:
{\small
\begin{verbatim}
    epstopdf image.eps
\end{verbatim}
}

This will finally produce an {\it image.pdf\/} file, which can be used by 
\verb+\includegraphics+ and similar commands. To automate the whole process, 
the following {\tt Makefile} might prove to be useful:

{\small
\begin{verbatim}
    IMAGES = <list of .pdf files>
        
    all: ${IMAGES}

    %.pdf: %.eps
        epstopdf $<

    %.eps: %.ps
        ps2eps -f $<
        
    %.ps: %.dot
        dot -Tps2 -o $*.ps $<
\end{verbatim}
}

Note that this description is not meant to be exhaustive. It is little more 
than a reminder for the author himself, but it should get you started. Much 
more information on this topic is available from various sources on the 
internet.

--- NEW FILE ---
% File:      epstopdf.sty
% Version:   2001/02/04 v1.1
% Author:    Heiko Oberdiek
% Email:     <address@hidden>
%
% Copyright: Copyright (C) 2001 Heiko Oberdiek.
%
%            This program may be distributed and/or modified under
%            the conditions of the LaTeX Project Public License,
%            either version 1.2 of this license or (at your option)
%            any later version. The latest version of this license
%            is in
%              http://www.latex-project.org/lppl.txt
%            and version 1.2 or later is part of all distributions
%            of LaTeX version 1999/12/01 or later.
%
% Function:  This packages adds support of handling eps images
%            to package graphic{s,x} with option `pdftex'.
%            If an eps image is detected, epstopdf is automatically
%            called to convert it to pdf format.
%
% Required:  * The program `epstopdf'.
%            * The feature `\write18' has to be enabled to get
%              the conversion via the program epstopdf work:
%              * command line option: -shell-escape
%                example: pdflatex -shell-escape test.tex
%              * configuraton file `texmf.cnf': shell_escape = 1
%
% Use:       The package is loaded after graphic{s,x}, eg:
%              \usepackage[pdftex]{graphicx}
%              \usepackage{epstopdf}
%            Images with extension `.eps' are now detected
%            and supported:
%            * Implicitly: \includegraphics{bild}
%              If `bild.eps' can only be found,
%              then it is converted to the file `bild.pdf',
%              that will be used by pdfTeX.
%              On the next ocurrences or on the next pdfTeX run,
%              the pdf file is already available, so the
%              conversion step is skipped.
%            * Explicitly: \includegraphics{bild.eps}
%              Each time the conversion program is called.
%
% History:   2001/01/06 v1.0:
%              * first public version,
%                published in the pdftex mailing list.
%            2001/02/04 v1.1:
%              * minor documentation update.
%              * CTAN.
%
\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{epstopdf}%
  [2001/02/04 v1.1 Conversion with epstopdf on the fly (HO)]

% Check, whether package graphics is loaded
% (also graphicx loads graphics)
address@hidden
  \PackageWarningNoLine{epstopdf}{%
    No graphics package \string`graphic{s,x}\string' loaded%
  }%
  \endinput
}
% Check, whether pdftex.def is loaded
address@hidden@pdftex.def}{%
  \PackageWarningNoLine{epstopdf}{%
    Graphics driver file \string`pdftex.def\string' not loaded%
  }
  \endinput
}

% Patch address@hidden to execute #3, if it contains
% a command
address@hidden@setfile
address@hidden
  address@hidden address@hidden
    address@hidden address@hidden@nil}%
    address@hidden@base #2}%
  \else
    address@hidden
  \fi
}

% Adding .eps at the end of the list of extensions,
% defined by \DeclareGraphicsExtensions
address@hidden@address@hidden,.eps}

% \DeclareGraphicsRule for .eps
address@hidden@address@hidden #1}}

\endinput

--- NEW FILE ---
digraph example1 {

  rankdir = LR;
  ratio = compress;
   
  start      [shape = polygon, sides = 4, label = "Start"];
  wizard     [shape = polygon, sides = 4, label = "Encounter\nwith Wizard"];
  end        [shape = polygon, sides = 4, label = "End"];

  start -> wizard
  wizard -> end

  intro      [label = "1  Intro"];
  git        [label = "2  Get into\nTower"];
  dw         [label = "3  Defeat\nWizard"];
  tuww       [label = "4  Team up\nwith Wizard"];
  fp         [label = "5  Free\nPrincess"];
  sp         [label = "6  Sacrifice\nPrincess"];
  
  intro -> git
  git -> dw
  git -> tuww
  dw -> fp
  tuww -> sp
  
  { rank = same; start; intro; }
  { rank = same; wizard; dw; tuww; }
  { rank = same; end; fp; sp; }
}

--- NEW FILE ---
digraph example2 {

  rankdir = LR;
  ratio = compress;
   
  intro      [shape = plaintext, label = "Intro"];
  kk         [label = "2.1  Kill\nKraken"];
  ewb        [label = "2.2  Eat\nwinged berries"];
  swl        [label = "2.3  Swim\nthrough lake"];
  law        [label = "2.4  Levitate\nacross water"];
  dw         [shape = plaintext, label = "Defeat\nWizard"];
  tuww       [shape = plaintext, label = "Team up\nwith Wizard"];
  
  intro -> kk -> swl -> dw
  intro -> ewb -> law -> tuww
  swl -> tuww
  law -> dw
}

--- NEW FILE ---
digraph example3
{
  ranksep = 0.8;
  
  start     [shape = polygon, sides = 4, 
             label = "Start"];
  wizard    [shape = polygon, sides = 4, 
             label = "Encounter\nwith\nWizard"];
  end       [shape = polygon, sides = 4, 
             label = "End"];
            
  start -> wizard -> end

  intro     [label = "1  Intro"];
  git       [label = "2  Get into\nTower"];
  dw        [label = "3  Defeat\nWizard"];
  tuww      [label = "4  Team\nup with\nWizard"];
  fp        [label = "5  Free\nPrincess"];
  sp        [label = "6  Sacrifice\nPrincess"];
  
  intro -> git -> dw -> fp
  git -> tuww -> sp
  
  { rank = same; start; intro; }
  { rank = same; wizard; dw; tuww; }
  { rank = same; end; fp; sp; }
};

--- NEW FILE ---
digraph keypoint {

 rankdir = LR;
 ratio = compress;

 point [shape = polygon, sides = 4, label = "The End"];

}

--- NEW FILE ---
\section{Main Plot}

In this section we have a closer look at the plot. How it is composed and how 
it should look like. A thought we'll have to keep in mind all the time is that 
\textit{the player should drive along the plot, not vice versa}.

\subsection{Components}

A plot is a rather abstract concept. It is made up of many different aspects, 
and all of them are equally important. First of all it needs a world to take 
place in. This does include the geographic location as well as a history and 
culture. 

\paragraph{The history} is essential as it helps to explain the situation that 
sets the plot in motion. A player needs not know the complete background right 
from the beginning, or at least not all of it. However, as she progresses 
through the game, it should be revealed step by step, so that she can finally 
understand the reasons for her situation. Not only solving the main quest can 
be motivating, but also figuring out the background.

\paragraph{Culture} gives the plot a frame. It defines acceptable and 
unacceptable behaviour and gives the player something she can rely on, even if 
everything else is uncertain. It also helps with the creation of NPCs, history 
and locations. Diversions from the expected behaviour of NPCs and appearance of 
locations will bring additional flavour to the game. They stick out most if the 
rest largely follows the rules dictated by culture.\\

The plot further needs a storyline. It unravels in dialogues and cutscenes, in 
scripted events and in the player's exploration of the world. In general, there 
are two ways to tell a story, and in our case it is important to find a good 
mixture of them.
 
\paragraph{Interactive} story-telling includes dialogues (if they offer enough 
choices) and in general the player making her way through the world. These 
parts of the story are centered around the player's actions and decisions, and 
so often differ from player to player. But for an interactive game, they are to 
be preferred of course. Still the player needs some short- and long-term goals, 
to give her a direction. Being lost without a clue what to do next is 
definitely a plot-killer.

\paragraph{Non-interactive} elements such as cutscenes and scripted events are 
the best choice when more control over the story is required: to create 
suspense, to add some interesting twists, or simply to surprise the player and 
to throw her into new, unforseen situations. These elements are the spice of 
the plot, but they have to be utilised with care. 


\subsection{Structure}

Unlike a book or movie, the plot of a role playing game cannot be linear. As 
the name implies, the player should be able to take on whatever role she likes 
and consistently stick to that role. In other words, the plot should adapt to a 
player's style of playing, not the other way round. This however would lead to 
completely open-ended gameplay, where everything depends upon the player, 
without predefined storyline. A (good) storyline however is part of the 
motivation to continue playing. It provides a long term goal and indicates 
progress, apart from gaining higher levels and acquiring better equipment.

So the difficulty lies in finding a good compromise between a linear story and 
non-linear, adaptive gameplay. If we look at a story, we will soon find key 
points that are essential to it, while other parts are merely required to 
connect those key points. This is something we can use to our advantage. In 
case of our plot, those key points are events or situations every player needs 
to pass in a certain order for the plot to make sense. Different paths between 
those key points allow for different styles of playing. Depending on the style 
the player chooses, she might experience the key point from a different 
perspective and will also find different ways to carry on afterwards.

To be more precise, a key point is a set of plot nodes that are roughly 
equivalent. Usually they share the same location and events, but often differ 
in the player's possible actions and outcome. The outcome then influences the 
paths that are available afterwards. Some of them might be shared between 
different nodes, while others would be exclusive to a certain node.

\begin{figure}[h]
\center
\includegraphics[width=11cm]{structure1.eps}
\caption{Overall plot structure}
\end{figure}

Each of those different paths can contain a number of key points itself, so 
that we can have multiple alternatives on this lower level as well. These might 
not depend so much on the player's style of playing, but more on other factors. 
Basically, a task would be completable in different ways. Some of them might 
require certain skills or artifacts and would therefore apply to a limited 
number of players only, while others would be open to any player. There can't 
be distinct ways to complete a task for every possible player, but there should 
be a fair number of alternatives.

Of course, at some point further division of the plot makes no more sense, or 
is simply impossible. But if there are different ways to complete a task, or 
part of a task, these alternatives should be implemented. This especially 
applies to alternatives that are really unique, while it is no must-have for 
alternatives that just differ marginally.

\subsection{Design}
There are numerous ways in which two paths between key points can differ, and 
it is certainly impossible to implement each of them in every case. The list 
below is a selection and by no means complete, but it should give you an idea 
how a particular aspect of the plot might be accomplished in different ways.

\paragraph{Player alignment} is probably the most obvious. Especially tasks 
that involve NPCs can often be accomplished in either good or evil fashion - or 
some shade in between. Give them something in exchange for an artifact, or just 
steal it. Do as they say, or deceive them. Help the fair and pursue the foul or 
slay the innocent and band with the villains.

\paragraph{The gender} of a player might also affect the way a task can be 
accomplished. Some NPCs might prefer either male or female characters, and 
therefore make life harder for the other sex.

\paragraph{Special equipment} can help to simplify many tasks. The proper spell 
or item at the right place might unlock shortcuts or help persuading NPCs 
without doing the usual errand for them.

\paragraph{Special skills} are similar to the equipment. A charming player may 
influence others to his favour, and an athlete may be able to climb walls or 
cross obstacles that force everybody else to a long detour. Practically every 
skill can be used to ones advantage at certain occasions.

\paragraph{Different quests} could lead to the same result or reveal similar 
hints for the next step. That way, the player may chose the one that suits her 
best, although it needs not always be obvious that different quests are 
available.

\paragraph{Different NPCs} can give the same information after sending the 
player on an individual errand first. They might also offer completely 
different solutions to the same problem.

\paragraph{Different artifacts} can have the same or similar effect, just like 
different NPCs can give the same hints. Thus they are interchangeable and 
either of them helps to accomplish a certain task. There might also be multiple 
occurances of the same artifact. \\

Quite a lot of these alternatives have special requirements, meaning they will 
be available to a small number of players only. When designing multiple ways to 
accomplish a task, it is important to keep this in mind. Otherwise individual 
players might still find themselves without a choice. So most ways should be 
open to all, or at least a large number of players. A few 'shortcuts' for 
gifted (or lucky) players are in order though, as long as each player can be 
lucky from time to time.

--- NEW FILE ---
digraph minmalistic 
{
    // Node definitions
    n1 [label = "Node 1"];
    n2 [label = "Node 2"];
    
    // Node connections
    n1 -> n2
};

--- NEW FILE ---
digraph nodes
{
    rect [shape = polygon, sides = 4,
          label = "Rectangle"];
          
    none [shape = plaintext, 
          label = "Plain Text"];
          
    rect -> none [label = "Edge\nLabel"];
};

--- NEW FILE ---
\section{NPCs}

Here we discuss some guidelines for designing non player characters. As a rule 
of thumb, NPCs should have the same options the player has and vice versa.

\subsection{Roles}
NPCs are as important for a good plot as the various locations. They are one of 
the parts of the game world the player can interact with; they hand out quests 
and information and provide items and training. Most of them are harmless, but 
others may turn hostile, or are enemies right from the beginning.

What follows is a breakdown of the different roles NPCs can play. Note that 
individual NPCs can play several roles at the same or at different times.

\paragraph{Key characters} play a special role in the main plot, either active 
or passive. They could help the player with information or required artifacts, 
but the player might also have to do something with them, be it killing or 
saving them, or something completely different.

\paragraph{Party members} are those NPCs that may join the player for a short 
while or the rest of the game. They may do so because they really like to aid 
the player, or simply because they believe they can reach their own goals that 
way. Of course it is up to the player to chose her companions, but sometimes 
the plot may leave her no real choice if she wants to make any progress.

\paragraph{Side characters} have no part in the main plot, but offer side 
quests or are involved in their completion. The player may completely ignore 
them, but they often provide helpful items and experience to support her in the 
course of the main plot.

\paragraph{Merchants} sell and buy from the player. Whether they sell goods or 
informations, or just a room to stay for the night makes no difference. Most 
would go openly about their business, but some might act more hidden.

\paragraph{Teachers} are a special class of merchants. They allow the player to 
improve her skills and learn new things. Like merchants they may charge money 
or ask for a favour. They may prefer certain characters and refuse to teach 
others.

\paragraph{Diversion characters} are NPCs that take no part in plot or side 
quests, and are neither merchants nor teachers. Their main purpose is to liven 
up the game world. They may be funny or severe, provide interesting information 
about game world related topics, or just crack silly jokes.\\

If a NPC does not fall into any of those categories, it should be left away. To 
populate a location you shouldn't fall back on ``dummy" NPCs that just stand 
around idle with no purpose at all. Use diversion characters instead!

\subsection{Design}
After having seen the roles a NPC may fill in, we will now take a look at a few 
guidelines to make the most out of them in terms of gameplay and plot design. 
In general, all NPCs should be viewed as real people with a background and 
occupation, goals and dreams and various connections with the game world, 
independent of player and main plot. If these things are regarded when creating 
NPCs, they will add a lot to the game world's ambience, and watching NPCs and 
interacting with them will be as much fun as possible. \\

If a NPC has a spouse or children, the player should be able to meet them, 
unless they live in an area not covered by the game. More distant relatives 
need not be covered, but it should become clear that most NPCs do have a 
family. If NPCs have friends or foes, the player should be able to learn about 
them too, if she wants to.

NPCs may have the latest gossip about neighbours and other NPCs and will in 
general share their thoughts and opinions with the player. Not all NPCs will 
share such news readily and for free, and only few would bother the player, 
even if she isn't interested in their gossip.

Most NPCs do not treat the player in a special way, just because she happens to 
be the player. To them she is a stranger and needs to gain their confidence 
first, unless she gets credit from another NPC or belongs to the same faction. 
On the other hand, the player should be able to get to know select NPCs better, 
make friends and allies but also enemies. This is especially true for key 
characters and party members, who feature largely in the main plot. It should 
be possible with a few other NPCs as well, though. Of course this also depends 
on the path the player takes through the game. In the most extreme case, a NPC 
could become her best friend in one game and her utter enemy in the next. \\

When creating NPCs it is important not to fall into a black and white scheme. 
Few NPCs will be totally evil, and few are complete saints. The more 
interesting characters are simply misguided, or seek to accomplish the right 
things in the wrong way. Others may happen to have goals that conflict with 
those of the player, but that needs not make them outright enemies. Of course 
there are also unscrupulous bastards, but even they might have some good, or at 
least less evil, traits.

Even if two NPCs are individually good, they might not necessarily like each 
other. Such conflicts can often lead to interesting side quests, where it is 
impossible for the player to tell right from wrong. In other cases this will be 
more obvious, but there should also be NPCs where the player's first impression 
turns out to be completely false. Seemingly bad characters might become good 
friends in the end, while good ones will finally betray her.\\

Apart from their background and affinity to the player, NPCs should also have 
an occupation. That doesn't mean they have to be productive, they just should 
spend their time with different activities. Especially, no NPC should stand 
around idle without purpose. If possible, the player should be able to guess on 
a NPCs occupation from its activities. Otherwise, she should have other ways to 
figure it out.

The activity of NPCs might even be important for the plot or a side quest. Some 
roles of an NPC may be tied to a certain activity, or even to a special 
location. A shopkeeper for example, would only sell things while in his shop. 
Another NPC might only reveal informations when invited to a few drinks while 
staying in the pub. In general, an NPCs occupation will not only liven up the 
game world; it can also be relevant for gameplay.

--- NEW FILE ---
digraph path {

 rankdir = LR;
 ratio = compress;

 node1 [shape=plaintext, label = ""];
 node2 [shape=plaintext, label = ""];
   
 node1 -> node2 [label = "[condition]"]
}

--- NEW FILE ---
\documentclass[11pt, a4paper, twoside, pdftex]{article}
\usepackage[english]{babel}
\usepackage{a4}
\usepackage{a4wide}
\usepackage{pifont}
\usepackage{array}
\usepackage{calc}
\usepackage[pdftex]{graphicx}
\usepackage{epstopdf}
\usepackage[pdftex,
            pagebackref=true,
            colorlinks=true,
            linkcolor=blue,
            urlcolor=blue,
            pdftitle={Adonthell Plot Design Guidelines},
            pdfauthor={Kai Sterker},
            bookmarksopen=True,
            pdfsubject={Adonthell Designer's Reference}
           ]{hyperref}
\usepackage{fancyheadings}
\usepackage{float}
%\usepackage{makeidx}
%\makeindex

%------- Redefinitions ----------
\newcommand{\clearemptydoublepage}{\newpage{\pagestyle{empty}\cleardoublepage}}
%\newcommand{\Index}[1]{#1\index{#1}}

\begin{document} 
 
%-------------- Title ----------------
\clearemptydoublepage         % Title
\pagestyle{empty}
\title{Adonthell Plot \\ Design Guidelines}
\author{Kai Sterker}
\date{13.09.2002}
\maketitle
\thispagestyle{empty}

%------------------------------------------
\newpage                      % Copyright
\pagestyle{empty}

\begin{center}
{\sc Adonthell Plot \\ Design Guidelines} \\
\vspace*{\stretch{2}}
This document is part of the Adonthell Designer's documentation\\
{\sf \href{http://adonthell.linuxgames.com}{http://adonthell.linuxgames.com}}\\
\vspace{1em}
\Pisymbol{psy}{211} 2002 Kai Sterker \& The Adonthell Team\\
{\sf address@hidden
\vspace{1em}
Created with \LaTeX{}2\raisebox{-0.4ex}{$\varepsilon$}
\end{center}
\clearemptydoublepage

%------------------------------------------
\tableofcontents             % Contents
\clearemptydoublepage        
%------------- Layout ---------------------
\pagestyle{fancyplain}
\addtolength{\headwidth}{\marginparsep}
\addtolength{\headwidth}{\marginparwidth}
\renewcommand{\sectionmark}[1]{\markboth{\thesection\ #1}{}}
\renewcommand{\subsectionmark}[1]{\markright{#1}}
\lhead[\fancyplain{}{\bfseries\thepage}]{\fancyplain{}{\bfseries\rightmark}}
\rhead[\fancyplain{}{\bfseries\leftmark}]{\fancyplain{}{\bfseries\thepage}}
\cfoot{}

%------------------------------------------
\pagenumbering{arabic}
\thispagestyle{empty}
\include{abstract}          % Abstract
\thispagestyle{empty}
\include{main_plot}         % The Main Plot
\thispagestyle{empty}
\include{side_quest}        % Side Quest
\thispagestyle{empty}
\include{npc}               % Non Player Characters
\thispagestyle{empty}
\include{documentation}     % Documentation
\thispagestyle{empty}
\include{dot}               % The dot Tool
\end{document}

--- NEW FILE ---
\section{Side Quests}

In this section we deal with plot elements not directly connected to the main 
storyline. We find out how they differ from the main plot and how they can be 
designed.

\subsection{Differences}
The name itself says it all: side quests are additional tasks players may 
accomplish beside the main plot, and as such they are completely optional. 
While success or failure in their completion will have no direct effect on the 
main plot, artifacts, skills and experience gained in side quests can often 
greatly simplify parts thereof.

The main plot must allow any player to solve it in some way or another, whereas 
side quests don't have this restriction. Therefore, they can be tailored much 
better to individual characters and styles of playing. Some players might 
simply find a side quest unavailable to them, while others would have no chance 
to complete it. Failing a side quest is without dire consequences though; a 
player may miss out on a nice item or such, but she can still continue the 
game. The main plot on the other hand mustn't contain any such dead ends.

Further, side quests are usually quite short and self-contained parts of the 
game that aren't related to the plot in any way. As such they can be viewed as 
stories within the story. In most cases, these side quests are independent from 
each other, but from time to time the availability of a certain side quest can 
be based on the successful conclusion of previous ones (or even on a certain 
level of progress in the main plot). Other side quests might mutually exclude 
each other.

In most cases, side quests have some kind of reward at their end, be it some 
spell or fighting feat, an expensive or unique item, or just lots of 
experience. As such, side quests help players to prepare for the various 
challenges of the main plot. In addition they should also reveal additional 
information about game world and NPCs.

\subsection{Types}
In general there are three basic types of side quests. The ``classic" one is 
certainly the odd errand necessary to gain the help of some NPC, to receive 
training or a special item. Here it is the player wanting something, and the 
only way to get it is doing the NPC a favour. These side quests can differ 
considerably in length and difficulty, but they are usually quite 
straight-forward, with a well-known goal and few key points. Still, we should 
make sure that there are different ways to complete these errands, including 
the possibility to deceive or trick the NPC.

Another type of side quests are NPCs that seek help from the player. Here it is 
up to the player to accept or reject, as the reward is often unknown 
beforehand. Those requests for help can range anywhere between good and evil, 
may include stealing and killing but also recovering lost items or mediating 
between hostile parties. Quests of this type can become quite complex, and are 
often harder to spot and to solve than the classic ones. It should be fairly 
easy to devise different ways to complete or fail in such a quest.

And last but not least, there are those side quests that don't involve NPCs at 
all. This can be a hidden cave or ruin for the player to explore, valuable 
items that can be ``gathered" from various places and everything else that 
requires the player's initiative without any further instruction. Those quests 
usually involve puzzle solving, exploring and possibly combat, while the others 
also require a certain amount of talking.

All three types have in common that they may provide the player with means that 
aid her in the main plot. 

\subsection{Design}
Unlike the main plot, side quests offer much more freedom to the designer. That 
also means they can be much more diverse than the rest of the plot, which needs 
to suit all types of players. Side quests can range from simple and 
straightforward to difficult and complex, can put the emphasis on either 
exploring, fighting, talking, solving puzzles or any combination of these. They 
can require the player to have certain talents, equipment or alignment, or be 
open to - and completable by - all players. They can be funny, dead earnest or 
just plain silly.

Although side quests differ considerably from the main plot line in terms of 
design, there shouldn't be large differences in terms of gameplay. A player 
shouldn't get the feeling that she can skip a side quest, just because it is 
``a bloody side quest". If possible, they should appear as important and 
pressing as the next task of the main plot.

When designing side quests, one should try to avoid repetition. No two side 
quests should be alike, and they should also differ from elements of the main 
plot. Most of them should consist of more than just killing that character or 
recovering this item. Some may be specially designed for good or evil 
characters, others might seem good but turn out rather bad. For a difference, 
NPCs could even try to deceive the player. 

Further, the outcome of a side quest may have some influence on other quests, 
either unlocking or disabling them. They can change the player's standing with 
the various factions. They can even have an influence on the main 
plot\footnote{Did I stress this enough now, Ben? ;-)}. Special items or spells 
gained in side quests might help at certain points, as would do friendly NPCs 
and factions, while angered NPCs could force the player to chose a different 
path to get on with the main plot.

--- NEW FILE ---
digraph structure1 {

 rankdir = LR;
 ratio = compress;
   
 start      [shape=polygon, sides=4, label = "Start"];
 keypoint1  [shape=polygon, sides=4, label = "Key\nPoint 1"];
 keypoint2  [shape=polygon, sides=4, label = "Key\nPoint 2"];
 end        [shape=polygon, sides=4, label = "End"];

 start -> keypoint1
 keypoint1 -> keypoint2
 keypoint2 -> end

 n0         [label = "Node 0"];
 n1         [label = "Node 1"];
 n2         [label = "Node 2"];
 n3         [label = "Node 3"];
 n4         [label = "Node 4"];
 n5         [label = "Node 5"];
 n6         [label = "Node 6"];
 n7         [label = "Node 7"];
 n8         [label = "Node 8"];
 n9         [label = "Node 9"];

 n0 -> n1
 n0 -> n3
 n1 -> n2
 
 { rank = same; start; n0; }
 { rank = same; keypoint1; n2; n3; }
 
 n2 -> n4
 n2 -> n6
 n3 -> n6
 n3 -> n7
 
 n4 -> n5

 { rank = same; keypoint2; n5; n6; n7; }
 
 n5 -> n8
 n6 -> n8
 n7 -> n9
 
 { rank = same; end; n8; n9; }
}