Plot:Design:Documenting

From Adonthell
Jump to: navigation, search

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.

Contents

Contents

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

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

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:

  • 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.
    Plot design path.png
    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.
  • 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.
    Plot design activity.png
    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.
  • 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.
    Plot design keypoint.png
    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.

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 ollowed by a brief commentary, to highlight and to explain the most important features.

Character description

 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 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 Tower. 
 
 The Princess  ...

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.

Location description

 Wizard’s Tower  This is the home of the 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. 

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.

Top level Dependency Graph

 Plot design example1.png
 

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.

Second level Dependency Graph

 Plot design example2.png

To make the toplevel dependency graph clearer, it might make sense to group several activities together. Here the toplevel Get intoTower activity has been split into four nodes, and two different paths, on the second level. Incase 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 toplevel, no keypoints are required. However, all ‘entry’ and ‘exit’ activities should be included. The Ids used in the subgraph easily allow to identify the toplevel activity –- no. 2 in this case.

Activity Description

 1  Intro  As one of the king’s knights, the player is sent to rescue the Princess from the 
 Wizard’sTower. The game starts with him arriving in the tower area. 
 
 2  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: 
 
 2.1  Kill Kraken  A deadly beast guards the lake that surrounds the 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. 
 
 2.2  Eat winged berries  ... 

The activities should be sorted alphabetically by their Id. Sublevel activities should be inserted after the corresponding toplevel 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.

Personal tools
Namespaces

Variants
Actions
Navigation
Exits
Tools