It’s been a little over four months since I
last looked at the dynamic narrative design of Reluctant Hero, our next
computer role-playing game project with 3D People. The last post on Dramatic
Role Proxies summarised my position at the time, and the issues I was dealing
with. Before proceeding, it is worth going over some of the (tentative)
decisions I have made in the interim:
The game will be narrated by the player character, provided we have the budget to record both a male and a female voice over.
All the game dialogue will be delivered as narration, although not all will necessarily be recorded.
The narration will be written as if it were a journal entry: “I made it across the mountains” or “He told me where I could find the bridge.”
We will likely use a role proxy system of some kind, but probably less extensive than previously outlined. In particular, the key Enemy (Nemesis) characters may be set and selected from a pool of options – generic foes run the risk of being narratively insipid.
The purpose of this post is to get straight
in my head some of the main issues of the story mechanics, in order to lay down
this framework of the game. Let us start at the top and work our way down, as top
down design tends to be more robust.
Chapters & Paths
Any game of Reluctant Hero is divided into
a certain number of Chapters, according to the game length the player
has chosen. Each Chapter must necessarily have its storyline – that is, each
Chapter begins with the activation of a particular Scenario (or, if you
prefer, Quest). This is vital: the player is free to do what they wish, but for
players requiring instruction, there must be a general path for them to follow.
Therefore, one of the first tasks is to establish the answer to the question:
how are Scenarios selected?
(Why Scenario and not Quest? For a start, the term has greater RPG antiquity,
but more importantly visiting your sister is a viable Scenario, but it doesn’t
sound like much of a Quest!)
The answer to this key question depends in
turn to how the Scenarios can be grouped, and in particular whether or not
there is a distinction between what we may call Arc Scenarios (those
that form part of a wider story) and Incidental Scenarios (“one off”
quests or stories). Let us presuppose this distinction, for we can surely
eliminate it later if it becomes troublesome.
Arc scenarios must then be grouped into Paths,
of which I can see four options:
The Adventurer Path is explicitly chosen when the player chooses to run away from their arranged marriage. It favours seeking lost relics and tomes, and the ultimate goal of finding the artefact that your father could not.
The Noble Path is explicitly chosen when the player chooses to go along with their arranged marriage. If favours a more domestic life, trying to invest the family fortune in suitable businesses and defend them from the attacks of brigands, monsters, and the pitfalls of misfortune.
The Family Path can go in parallel with either of these paths, and relates to the story of the protagonist’s Sister.
The Parent Path can go in parallel with any of the other paths, and relates to the problems that will be encountered should the player try to conceive children.
From these four Paths, all the Arc
Scenarios can be selected. (Note that the player can still find the relics and
artefacts of the Adventurer Path as a Noble, and can still run businesses as an
Adventurer; they are just not asked to do so).
Additionally, we require Incidental
Scenarios to fill the gaps between the Arc Scenarios. Most will doubtless be
“Monster of the Week” stories, but there are certainly other possibilities such
as journeys and curses.
But how will these many different Scenarios
The easiest way to solve the sequencing
problem is to specify an Act framework. Act I represents the story up to the
point that the player either accepts or flees from their arranged marriage. Act
II through IV are the main part of their life. Act V is about their death and,
if they should cheat death, Act VI is about their life after death (where
tragedy surely awaits).
Act I, I already know, has 3 Chapters in
it. The final Acts (V and VI) should be similar in length, although this has
yet to be determined. It follows that depending upon the number of Chapters the
player has chosen (i.e. the game length) there will be different numbers of
Scenarios in each of the other Acts, as follows:
The shortest possible game is 12 Chapters (3 in Act I, 2 in each middle Act, 3 in the final Act or final two Acts).
With 3 Chapters per central Act we get 15 Chapters (3:3:3), with 4 we get 18 Chapters, with 5 we get 21, with 6 we get 24 and with 7 we get 27 (3:7:3).
Finally, the longest game has 8 Chapters in each central Act for a grand total of 30 Chapters.
(It should be noted that the player will
select the game length and approximate number of Chapters – some
latitude may be inevitable.)
On this schema then, the shortest game
consists of just 2 Chapters per central Act. I have to wonder if 3 central
Chapters (one each per central Act) will be enough to develop the main Path
stories, or whether we will need all 6 central Chapters (both in each central
Act) to get a reasonable story… More narrative design is needed to answer this
At the other end of the scale, the longest
game will consist of central Acts of (say) 2 Chapters from the main Paths, 1-2
Chapters from the side Paths, and then another 4-5 Incidental Scenarios. That
requires at least 5 Incidental Scenarios for each central Act, but on the other
hand almost all of these will be quite simple to implement.
It strikes me from examining this that we
can have broadly linear sequences of Arc Scenarios (with some parallel or
contingent elements) that occur at the start of each Act, and then again near
the end of each Act, if there are two per Act. The Arc Scenarios from the side
Paths can be randomly allocated to the central Chapters in each Act, with the
remaining Chapters filled with Incidentals.
Incidental Scenarios can be chosen more or
less at random, although some contingency as to the nature of the player’s current
Location (and the Culture they are living in) along with the Act should be
taken into consideration. A minimum of 15 are needed; I suspect we’ll make more
like 45-60 or more (although many will be variants of one another). The
important thing is that there needs to be enough to allow every game to be
(I’d also like to give some Incidental
Scenarios “sequels” in later Acts, as I suspect players would enjoy that).
This should all have the desired effect of
making each game of Reluctant Hero something akin to a season of a TV
show, with a mix of long running and “one-off” stories.
Before looking at the Scenarios themselves,
an aside on the prologues is in order. Each Chapter will need to begin with
dialogue (strictly speaking, monologue) that sets the scene. The Scenario that
is chosen can specify either a Domestic Prologue or a Peril Prologue,
which in turn will vary according to game state, the season or the month.
A Domestic Prologue might be something like:
“I have not seen my sister for some time now, and I wonder how she is doing,”
or “My son has grown so much these past few years”.
A Peril Prologue might be something like:
“Spring has brought fresh tragedy,” or “I guess it was too much to hope that
Summer would pass without incident.”
These would then follow with the Scenario
introduction. I need to plan this out some more, but this isn’t the place to do
How are the individual Scenarios to be
Firstly, each must specify a Problem,
which becomes an entry in the Journal, and also a topic for conversation with
other characters. The Problem may be “How do I open the gate to the
Reliquary?”, “What can be done about the blight in Corwenth?” or “What is
attacking the merchants on the west road?” Without getting too sidetracked,
this token can be used to initiate conversations which in turn will guide the
player to a solution through perseverance and finding the right people to talk
But below this, we need to specify the
atomic elements of the story.
Anything that happens, from a line of
dialogue to the setting up of a future battle can be considered an Event.
Events can be in three essential states – inactive, active and occurred.
Only certain Events are active at any given time, the others are inactive
(haven’t yet become active) or occurred (have already taken place).
Events will need to consist of the
A unique ID that identifies this particular Event.
The Condition that triggers the Event (if any). When an Event is activated, it will sit in a “watched list” until its Condition is fulfilled; then it ‘occurs’.
The Line of dialogue (if any) that plays when this Event occurs.
Any Actions that take place when this Event occurs (such as the placing of new monsters, the addition of locations to the map and so forth); probably a LUA script.
The Next Event, that is, the ID of the Event (or Events) to activate (enter the watched list) after this Event has occurred.
A Deadline (when applicable) that determines when this Event expires (becomes inactive again).
The Expire Event, that is, the ID of the Event (if any) to activate after this Event expires.
Note that sometimes the Next Event will be
‘Chapter End’, that is, the current Scenario is concluded, and that many
different Events may lead to ‘Chapter End’.
Without getting into too much detail,
looking at the Conditions will help clarify how Events will function:
Unconditional Events just take place automatically
Destination conditions initiate a Event when the player goes to a certain place.
Persona conditions initiate an Event when the player goes to the place where a specific Persona can be
found, or begins talking to said Persona.
Item conditions initiate an Event
when the player acquires a specific item.
Practice conditions would initiate an Event when the player uses a specific ability (currently known in the
game as ‘Practices’)
Neutralise conditions initiate an Event when the player befriends, kills or causes to flee certain Monsters or Personas.
Wait conditions initiate an Event
at a specific juncture, such as dawn, dusk, or the start of a particular season.
We are now ready to explore these ideas in
Let us take for our example something very
simple, namely an infestation of parasitic hexapods near a farmstead (a type of
vicious insectoid critter peculiar to the Heretic Kingdoms). Initially, the
player will not know what the cause is, they will only find out the nature of
the problem, which in this case is that the crops are being eaten by something.
The Problem is “What is eating the
The first Events to be activated are
An unconditional event creates new hexapods and places them into a Lair (a type of Site in the game world) near the farmstead. This in turn triggers a Neutralise event (see below).
A Destination event is activated for the campfire in the field at the farmstead. If the player camps at this point, it will trigger an
event that waits until the early hours of the morning and moves some
hexapods into the field, and updates the Problem to “Where is the hexapod lair? (This simulates the player camping out to try and catch whatever is responsible).
A Destination event is activated for the Lair which updates the
Problem to “Eliminate the hexapods”. In effect, if the player discovers the Lair (which they may do by exploring on the map), they deduce the critters are eating the rye and they become the new focus of the Problem.
The Neutralise event for the hexapods has as its Next Event ‘Chapter End’. If the player eliminates them by whatever means (including hiring someone to do so), that will suffice for this Chapter. This event has a deadline of one year, with an Expire Event which waits until the next winter and kills them all off in a harsh winter frost. (All Chapters must end eventually).
This is a simple example, and omits the
details of how the player could also investigate in dialogue (as this concerns
the dialogue engine, not the story mechanics), but it demonstrates how this
Event system can be used to build Scenarios.
The dynamic narrative system proposed here
is not especially ground breaking; certainly more ambitious and impressive
proposals could be conceived. But it is a realistic proposition to implement
such a system, it should be comparatively robust, and it is not much more work
to execute than a conventional static quest system. Yet it does allow for some
dynamic narrative, and any amount of this that can be placed into a cRPG
without excessive development overheads is, I believe, worth considering.
Much of what will make it interesting will
be the nature of the Scenarios themselves, but I will need to pin down the
mechanics confidently before this work can be done, and I need the okay from 3D
People on the basic approach. Oh, and naturally I won’t be sharing the main
story details on the blog, of course – you’ll have to play the game to find out
the whole story!
Naturally, I welcome discussion in the
comments. Let me know your thoughts and opinions!
I'm not enormously familiar with Wired magazine, but I'm guessing in a glossy publication with 300,000 subscribers and just one page dedicated to videogames that it's a rarity for a game made on the budget the size of a sneeze to be featured. Yet the April 2007 issue of Wired has a review of Play with Fire in it! It's a schizophrenic piece; it praises the "clever concept" yet complains that "the addiction factor is missing." Notably absent is the requisite explanation of why the reviewer felt it was worthy of inclusion in the magazine in the first place - it left me scratching my head. I'm grateful for the publicity, but ultimately perplexed.
Elsewhere, Will Willing's Casual Game Design blog is running an interview with me about Play with Fire which you can find here. There's probably nothing new in it for regular readers of Only a Game, but it's a nice piece about the game for anyone not familiar with its story. My thanks to Will for taking both the time and the interest in the project.
Firstly, Gamasutra published the game design document for Play with Fire, which I hope will prove to be a useful resource for people normally starved of such things. You can find it here. (If it gets us a few extra downloads as well, that couldn't hurt either).
Secondly, the US's only independent computer games magazine, simply called Computer Games Magazine, published a rather nice review of Play with Fire in its Alt.Games column, April edition. It concludes:
Play with Fire is a captivating game that will challenge even the most experienced maze master [while] the Fun mode just lets you burn stuff, appeasing the firestarter in all of us.
My thanks to Troy Goodfellow for providing us with our first review of the game! Sadly, the news is that Computer Games Magazine's publisher has decided to axe it - Greg Costikyan has more on the story.
Ready to burn things to the ground? You can now download the demo of Play with Fire from Manifesto Games here!
You can turn the demo into the full game by buying an unlock code - and please do! If you want to see more original, unusual and inventive games, you need to support the indie developers who are the only people in a position to make these sorts of games (see the Indie Games Bazaar in the sidebar).
Most mainstream developers are now locked into a vortex of spiraling development costs where risk-averse publisher buying strategies dictate making more of the same but with fancier graphics and licensed IP. A few new things manage to survive the system, but they tend to get rarer each year. Let's try something different for a change!
Oh, and just so you know, we made Play with Fire for less than 1% of the budget of a typical game. For every humdrum videogame film tie-in you see, publishers could have funded a hundred games like this.
Also, if you blog, please help pimp Play with Fire for us. You can get screenshots from the Manifesto site. We need your help!
A few minor issues... the Manifesto page doesn't currently show the Fantasy Labs logo - they are the developer of this game, International Hobo are just the design team. Will get this fixed as soon as I can. Also, a couple of versions of Windows XP shipped by Microsoft are inexplicably missing a key dll for directX 9.0c. If this affects you, the missing file (d3dx9_30.dll) can be downloaded from here.
I hope you enjoy the game, and if you do - tell your friends!
Regular blogging will resume on Tuesday - see you then!
Play with Fire, the abstract platform-puzzle game that’s been developed as an
indie project for release on Manifesto went Master this Wednesday. It should be
on sale in early January.
It’s been 17 months since the original
concept design, and 14 months since we broke ground on the code. That’s a lot
longer than the 6 months originally planned for the project, but then we’ve
suffered numerous delays during this time on account of setting up the
developer, Fantasy Labs – including changing the programmer (which is always excessively
costly in time), and cross-talk with other projects that had to be undertaken
to provide bridge funding.
But still, the basic principle has held:
we’ve developed on a very low budget. Now all that remains is to see if there
is a niche market out there looking for something a little bit different,
something that could never be a mass market success, something which endeavours
to be original. My biggest concern is our rather high minimum spec. We may be
at the mercy of players more interested in the latest glossy FPS than an
oddball game like this one.
I’d like to thank everyone who has
supported the project, especially the volunteers from the external pool who
contributed more than half of the game’s fields, and in particular Maurizio
Pozzobon, Patrick Dugan and Ian Tyrell, whose contributions to the game have
been immense, and who will all be receiving a share of the revenue in return.
It’s not too late to help the project – please lend a hand building awareness
for the game by mentioning it on your blog when the link on the Manifesto site
goes live. (Images should be available on the Manifesto page).
This is a game about burning stuff to the
ground. It has a path for people looking for challenge and fiero, a path for
people looking for mind-melting puzzles, and a path for people who just want to
have a bit of fun and watch things blaze and collapse. All it needs now is
Digital Artist Management has a short piece on Play with Fire; here's a quote:
“The idea was to cut the cost of development any way we could and then
target a niche audience that we knew we could please. The basic way we
cut development costs was through the game design. For example, Play
With Fire was designed with only three verbs: move and jump, which are
trivial to implement, and burn, which admittedly was a little trickier.
The game world would be built entirely of cubes, because they'd be easy
to render and easy to build with, so that the only tricky technical
issues were in the implementation of the burning mechanics.
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
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
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: $Enemy:motive 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 Mentor and Mercenary proxies may also be possible. For instance, if the
player exterminates all but one of the monsters from a lair when they are
young, the surviving creature can be added to the Monster list along with a
narrator-delivered introduction line to be played when it is chosen (decades
later) as a Monster for a particular episode, e.g.:
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
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
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
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
New website RPGWatch has launched, and one of their articles is a developer diary for Reluctant Hero, written by myself. It expands upon many of the points explored here on the blog regarding time, experience and the chapter system. Check it out here.
I expect to be posting more about the design of the game in the next few months - in particular, the underlying data model and how it relates to the dynamic story elements, as there is still considerable work to be done on this aspect.
Back at the start of the summer, I hosted a week long symposium on play specifications, exploring different people's perspectives on nouns and verbs in the context of games. (I'm thinking of hosting another symposium in the Autumn, but still haven't chosen a suitable topic).
I've been internally digesting some of the discussions we had during the symposium since then, and one particular point has stuck with me. Jose Zagal raised this point in connection with first person shooter games:
[This] is a bit of rant I've had brewing since
hearing Chris Crawford talk a few years ago, there is usually a lot of
talk about how "weak" games are in terms of "verbs". I tend to agree on
one level, and disagree on another. Chris Crawford describes first-person shooter games as games where
you move, aim and fire. If he's feeling generous...add jump. It's a
valid critique, but I think that he misses the point...
Jose goes on to suggest that these games should be understood in terms of the verbs that emerge from the gameplay, and this is certainly one approach. But the reason this point has stuck with me is precisely the opposite:
Why should a lack of verbs be a criticism of a game?
If one is working in a narrative context, then a lack of verbs may reflect a lack of agency, but for play in general one needs only move and an action verb to constitute play. Consider Tetris (move and rotate), Res (move and shoot) or even Katamari Damacy (just roll, essentially!) The number of verbs is not an adequate measure of the play of a game. Play with Fire was intentionally built on a design with minimal
verbs - move, jump and burn - but the play of the game does not suffer
We can even scale back to single verbs. Building a sandcastle is engaging despite only being based upon one action - building with sand - and a hedge maze is entertaining even though it is solved solely by movement (and thinking, but internal thought processes are an entirely seperate issue to the actions taken). The idea that a multitude of verbs are a requirement for engaging play appears to be entirely erroneous.
I have not yet heard Chris Crawford talk, so I don't know if this second hand account accurately captures his position, but as far as I can ascertain there is no reason that one should judge a game deficit on the basis of a small number of verbs.