Story engine

This article is a proposal for a means to provide interactive story content in PARPG.

Goals

 * Provide a flexible means for telling stories in an RPG.
 * Avoid "programming" stories, or mixing with game mechanics.
 * Support separate concurrent stories, and stories at multiple levels of detail.
 * Support for all story parts, both dialogue and non-dialogue.

Non-goals

 * Support for stories of arbitrary computational complexity.
 * Support for generated content.
 * Tight integration with the PARPG game code.

Overview
This design centres around the "story events" which make up any given narrative. The game mechanics and engine are responsible for knowing where a character is, how they move around, how they perform combat, their proficiencies and inventory and so forth. Story events are those things which will vary between different scenarios or locations, whereas game mechanics are those things which are consistently applied throughout.

Each story event can only occur when some set of preconditions is met. At any given time, a number of story events might be ready to occur. For example, a character might be ready to say any one of a number of different lines to different people; which she says will change the story. Each line is a story event; something that might happen in the continuation of the story.

The function of the story engine is to offer the game a set of story events that may occur. The game may or may not select one, in which case it notifies the story engine of its choice. This degree of flexibility is needed to make sure the human is able to influence the outcome of the story: when a set of choices involve the player character(s), the game can pass that choice to the human by presenting a list of options. When the set of choices only involves non-player characters, the game must choose by other means (e.g. randomly).

A story writer creates a set of story events, either initially as a text file, or later in an editor, which the game reads and acts upon.

Interface
The basic structure of a story event is:
 * preconditions: what must be true before the event can happen
 * consequences: what effect this event will have on the story and world

A story relies on two kinds of information:
 * story information (for example, plot development)
 * game information (character health, location, time of day)

Preconditions take the form of assertions about the information available. Assertions may be:
 * boolean: "castle_seen", "princess_rescued"
 * numeric: "pc.health > 10", "time == 20"
 * compound: "castle_seen and pc.health > 20"
 * patterned: "?ch1.health < 5"

The last needs explaining. "?ch1" is a wildcard; it can match anything in the available knowledge base. If there's anything that has a health and that health is less than 5, then this precondition will be true. Multiple preconditions can be given and they must all be true for the story event to be available.

Consequences can't ignore the difference between the two types of information in their knowledge base. A consequence may set or modify any story information it wishes, but it may not set or modify game information. Instead, it provides a list of script calls into the engine that the engine can choose to act on. These are really function calls to set up some state in the engine. For example cutscene("final_giant_cutscene.mpg") or combat(boss_ch, pc).

Although this is the basic system, a few extra parts will be needed.
 * A story event may have a title, in which case whether it has occurred will be efficiently stored for use by other events' preconditions.
 * A story event may have a description, in which case, in the event of the player needing to choose whether it happens, the engine will be able to use this text in any interaction boxes that appear.
 * A special wildcard ?actor can be bound which determines who is the agent of the event (for example, the player character speaking, or an npc speaking to the pc). The player only gets to choose between events having the pc bound as the actor.
 * A story event may be marked as repeatable or may only ever occur once.

Software elements
* read a set of story events from a file. * be queried efficiently about what events can occur at this time. * enact consequences of selected events. * manually supply the necessary knowledge that the game would otherwise provide. * clearly see which events are available and why. * graphical layout of story events. * automation of some details of story arcs and so forth. * 'note this will be hard and very time consuming to develop'
 * A library which can:
 * A debug shell which supplies a simple environment to test stories in:
 * An editor to allow easy creation of stories: