Dynamic narrative is not something that the
mass market for games has any real interest in at this time, but it is
something that many game-literate players see as something of a grail. There
are many possible approaches, and it can be difficult to know which are worth
exploring and which might be dead ends without committing time and resources to
prototyping. One such approach is the substitution of proxy characters for
specified dramatic roles.
Although I greatly value the high degree of autonomy I enjoy with International Hobo, it is offset by our lack of resources. Nowhere is this more apparent than the sheer volume of work we have carried out investigating and blueprinting dynamic narrative systems that we generally do not have the resources to implement. Many of these systems have been proposed for certain game projects, but none of those projects have proceeded to funding, and that leaves a lot of the ideas and concepts largely untested.
Reluctant Hero is intended to include a dynamic narrative system, but the question
that hangs over the design of this system is the extent to which we will be
able to implement new concepts. Game design is almost always a balancing act –
new ideas may have great merit, but they take time (and hence money) to prototype,
implement and tweak. Usually, I would advocate building a game out of the
fewest number of game systems necessary – and since this game already has an
inventive combat system, negotiation system and structure, I have to seriously
consider to what extent we can risk exploring dynamic narrative techniques as
A fallback position is essential in such situations, and in this case we can always resort to a regular cRPG scripting solution but divided into an episodic structure, much like a TV show (a topic I have discussed before). The game story can then be pieced together from atomic components. This will provide a basic dynamic narrative, but it delivers rather less than I would hope for.
What I would like to explore in this
instance is abstracting out the dramatic roles of the narrative, and then
instantiating these roles in each episodic instance, which for now I shall term
dramatic role proxies. This is an idea we developed before for a rather
interesting game project which, sadly, did not proceed to funding. However, the
basic idea has always seemed sound and worthy of further investigation.
Before discussing the problems relating to this, it is necessary to relate something of the data structure of the world of Reluctant Hero. Essentially, the world of the game consists of a database (as can be claimed for any cRPG or MMORPG) the principle elements of which are the Personas (people, monsters) and the Sites (locations, establishments, lairs). Every Persona exists at a Site in the game world – so the world of the game consists of a number of Sites, at which lives a certain collection of Personas (some of which are NPCs and some are monsters).
The idea behind role proxies is that the
Personas that the player meets will be collected in lists – Friends lists for
those the player has related positively with, and Enemies lists for those the
player has related negatively with. (An Allies and Nemesis list may also be
used for the player character’s closest friends and worst enemies). These lists
are then used to substitute for the general case roles in the narrative engine.
So, consider for instance an episode that is scripted around a hostage situation plot. In informal terms, this episode script might read something like this:
An ENEMY occupies one of the Hero’s ESTABLISHMENTS, disabling the EMPLOYEES and demanding 50% of the Hero’s new worth. The Hero has 7 days to pay up.
When these story events come into play, the game would look at the player’s Enemy list and select a Persona from this list to instantiate the dramatic role of ‘Enemy’. Similarly, an Establishment (e.g. a Smithy, a Trading House, a Guild house) owned by the player is selected from the appropriate list, and everyone who has that Site as their home is disabled. A clock is then set for 7 days for the player to either pay up the ransom or overcome the Enemy by other means. (A pre-requisite for this episode being triggered would be the player owning an Establishment, of course).
This episode can then be scripted according
to this general pattern. When the player encounters it, the Enemy chosen will
be someone that the player has already encountered and who has a reason to hate
the player character, and will therefore make sense in narrative terms.
Where are the difficulties with such a system? It transpires that the actual substitution of dramatic role proxies is the easy part – the difficult parts are identifying circumstances within the game state which generate the role classes (Enemy, Friend), and determining how to store dialogue so that it can be meaningfully recovered when necessary.
The first of these problems is most certainly
soluble – Enemies and Friends can be generated both by the action of episode
scripts, and also by the outcome of combat situations and negotiations (both of
which have their own engine, and hence such assignments can be made as part of
the exit conditions of these systems). The problem in this case is that there
will probably be a large number of ad hoc situations which must be detected –
and detecting specific cases in game state is a recurrent game design problem. It
is not that there is a problem to be solved, per se, so much as concern must be
given to the amount of time and resources required to implement, and subsequently
to debug such a system.
The second of these problems is somewhat trickier. It requires thought as to where in the game data structures the dialogue is held, and to which dialogue is specified in the episode scripts, and which is owned by the Persona in question. For instance, we can store a value with each Enemy that reflects why that Persona became an Enemy. This value can have associated with it dialogue that comments on why this Persona hates the player.
Player kills Enemy’s Husband:
“I can never forgive you for killing my husband.”
Player kills Enemy’s Wife:
“You killed my wife, and I can never forgive you.”
Player foiled coup to control $Region (episode outcome):
“$Region should have been mine, but you had to get in my way”
These motive lines can then be given a reference ($Enemy:motive) and triggered inside episode scripts where appropriate.
For instance, in a prior example of a
hostage situation, an event may occur when the player character and Enemy meet
for the first time in the episode:
Player: “Why are you doing this, $Enemy?”
Enemy: “Consider this my revenge.”
This scratches the surface of the
technique, but I hope it’s clear that there potential here for constructing
stories on the fly in which the player’s actions have consequences which are
reflected in the story, and hence in dialogue.
As well as Friend and Enemy proxies, Lover,
Monster and perhaps even
Narrator: “The $Monster seems to recognise you – there is hatred in its eyes.”
All of this makes this particular dynamic
narrative form sound easier than in practical terms it is likely to reflect,
and neither I nor 3D People have committed to following this approach yet. I
need to specify the formal elements of this system completely so that we can
fully assess the scope and risks before we can proceed.
A related issue worth considering is whether or not to write dialogue in a direct form, whereby the characters in questions will ‘speak’ the lines, or whether to script the entire game from a narrator perspective.
So for instance (and assuming a female
enemy – both male and female case lines must be written in most cases to
Enemy: “I can never forgive you for killing my husband.”
Narrator: She says she can never forgive you for killing her husband.
The advantage of the narrator approach is
that we could then use a narrator voice actor to record all the dialogue of the
game (at least in principle – some stitching might be required). If we don’t
use this approach, it will be hard, if not impossible, to record any
dialogue for the game.
Frankly, I’m uncertain of the best way to jump on this issue, but I’m swaying away from a purely narrator based approach. It might be superior to use the narrator to introduce, link and close individual episodes, and leave in (unspoken) dialogue for the rest of the story elements.
This doesn’t cover all of the issues (I
have skipped over the dialogue matters relating to funnelling and
breadcrumbing, for instance, as this is the easy part in this case) but it
gives a snapshot of the problems and potential currently being explored for the
dynamic narrative of Reluctant Hero. I don’t know if we will end up
using dramatic role proxies or not, but at the moment it seems tenable – a more
complete specification of the system will be required to convince me that there
no ‘unexploded bombs’ in the design before we can proceed.
Naturally, I welcome opinions from other people on this subject. Are the goals of this approach worth pursuing? How much of the dialogue workload should be given to the narrator? Let me know what you think.