Play Specifications

FreeSpeak Remembered

Although we appear to lack strong commercial pressures to push naturally for the development of dynamic narrative systems, these remain something that many fans of videogames still long for. Corvus is revealing from time to time details of his forthcoming Honeycomb Engine over at his blog, such as this radial plot diagram. It has inspired me to dig up the now retired FreeSpeak system that International Hobo developed over the space of several years. This ambitious notation held tremendous potential, but was never funded. Eventually, we had to withdraw the project. This post is a final testimonial to the work that was done with FreeSpeak, in the hope that it will encourage others to continue to pursue similar goals.



What was FreeSpeak?

The FreeSpeak system of dynamic narrative was an evolving toolset for scripting games and constructing interactive stories with non-linear elements. Dynamic narrative refers to the principle of scripting and plotting a game with a non-linear plot whilst avoiding the combinatorial explosion that happens with a conventional branching structure. The idea is to reuse materials, and to focus the plot to be constrained to specific pathways, covering most of the changes in plot not through expensive development of additional locations, but through the use of dynamic dialogue. In principle, the result would have been that players could experience a greater sense of involvement in the development of the story, and the developer could achieve this through the production of additional dialogue (which is comparatively cheap) and not through additional art materials.

At the time of discontinuation in the project, we had three components:

  • FreeSpeak schema: The elements of the FreeSpeak schema form a different way of looking at a game story. The story is comprised of a number of Episodes, which in turn are composed of a number of Scenes (which may be composed of a number of subscenes). Characters in the story are represented by Personas, whose  State changes in accordance with the player's actions. The players path through the story is dynamic - changing according to the player's actions.     
  • FreeSpeak notation: A format for generating nested flow charts that describe the      plot of a game using the FreeSpeak approach. Some examples are given below.
  • FreeSpeak 2.0 specification: a formal specification (using EBNF - Extended Backus-Naur Form) for FreeSpeak. Game scripts written in FreeSpeak 2.0 could have been incorporated into game code through the use of a custom parser. 

Future components were intended to include:

  • FreeSpeak 3.0 specification: an XML specification for FreeSpeak, improving upon the techniques developed in FreeSpeak 2.0, and reducing the level of programming knowledge required to use it.
  • "Writer Friendly" FreeSpeak Editor: a tool kit for editing FreeSpeak stories. It was intended to include a drag-and-drop plot editor (using FreeSpeak notation), a Persona editor, an Event editor/dialogue scripter and a Script Validator process which would ensure all branches and conditional dialogue was consistent and complete.

Developed by my company, International Hobo, FreeSpeak was based on an early prototype known as DNL (dynamic natural language) used in the (increasingly obscure) Discworld Noir adventure game. I always wanted to improve upon the techniques used in Noir, and FreeSpeak was an attempt to do just that. 

The goal of FreeSpeak was to develop a compact, innovative and highly expressive tool set with the power to transform non-linear narratives into workable, cost-effective propositions. It failed because of a lack of funding, and a growing doubt that the dynamic narratives produced would find a large enough audience to justify the investment of time and money implied.

The Elements of FreeSpeak

Plot Elements

The high level specification of a FreeSpeak story were concerned with Plot Elements, which allow the structure of the story (or plot skeleton) to be constructed.

Freespeakepisode_sample_2 Episode

A division of the plot - equivalent to an episode of a TV show. Depending on the particular game, an Episode might correspond to a particularly large game level, or a series of game levels with a specific resolution.

The diagram shows a set of FreeSpeak Episodes, and how they relate to create a complete story. This is the highest level in the schema. The story starts (bottom) and ends (top) with fixed episodes, but is internally variable.



Each Episode is composed of a number of different Scenes, generally equivalent to a game level, sub-level or a cut scene. It was characteristic of a Scene that it takes place in a single specific game Location.

The diagram demonstrates how a set of Scenes form the internal structure of a given Episode. This Episode has a fixed starting Scene, but can end in one of two different Scenes.

Freespeaksubscene_sample Subscene

When Scenes are sufficiently complex, they are decomposed into clusters of Subscenes. These are exactly equivalent to Scenes in the formal notation.

The diagram shows the composition of a particularly complex Scene. This Scene can be linked into the story from three different Scenes (note the three lines at the bottom) and connects to two different Scenes in its conclusion (at the top).


A particular graphical area in the game world. These are not the same as a game level, but more like a set for a TV show. The idea is that locations would be reused according to the needs of the story.

Control Mechanisms

The sequence that the player traverses the plot skeleton (the collection of Plot Elements) was determined by the narrative control mechanisms.


A flag that is set when a specific set of events have transpired. Keys might be set if the player speaks to a certain Persona, or if they have carried out a certain action in the game world, or because a set of game variables reach a certain condition.


Any aspect of the game data can be considered a 'variable'.

Affinities (Optional)

A class of Variables used in a FreeSpeak script. Affinities provided data on the relationship between certain game entities (generally Personas). Personas have values assigned representing their attitude towards various people and concepts - positive numbers representing supporting views, and negative numbers representing hostile attitudes to that person or concept. Changes in Affinities may affect a change in State for a Persona (see below).

Narrative Elements

Those elements which pertain to the player's actions and the dialogue the player hears were the narrative components of FreeSpeak, specifically Events and Speech segments.


An Event refered to any player action in the game world that will trigger either dialogue, or a change in the plot progression. Scenes were composed of a number of Events.


A specific section of dialogue was refered to as a Speech segment. Since Speech was only triggered by Events, all Speech was embedded in the Events of the story. All Speech was therefore inside an Event object (to use object-oriented parlance) but not every Event object needed to contain Speech (those that didn't would change the state of Variables, or set Keys, for instance).

Persona Elements

The characters in FreeSpeak were considered Personas, and formed a vital part of the specification.


Any game character who can talk (or be talked to) was considered a Persona. For each Persona, a number of States were defined which dictated the possible 'emotional spaces' the Persona can end up in as a result of the player's actions.

Freespeakpersona_sample States

The narrative roles that a Persona can fulfill are named Relationships. The usual classes allowed were Contact, Ally, Enemy and Flame (i.e. lover or unrequited lover). Transitions between States were explicitly triggered by the setting of a particular Key: once that Key is set, the transition occurs. Also, when a Persona transits into a new State, this could have set a Key.

The diagram shows the States for a particular Persona, in this case a Flame. She has three States: Friendly, Worried and Distrust, whose transitions are mediated by keys.

FreeSpeak Notation

Freespeaknotation The diagram here shows all of the elements in the FreeSpeak notation. Even had the script format and editor not proceeded, the FreeSpeak notation provided a new way of looking at the structure of a dynamic narrative. I would certainly have appreciated having this notation when I was working on Noir. I present it here just for general reference.  (Click on the image for a bigger version).

On the left, you can see the Plot Elements (Episode and Scene - both interactive and non-interactive). On the right, the Control Mechanisms (transition between Scenes, transition mediated by the presence of a Key, and transition mediated by the absence of a Key).

Underneath, the Persona Elements (the States, and the transitions between them; shown here is a transition mediated by the presence of a Key, using the same notation as the Control Mechanisms, above).


For many years, I was convinced of the commercial value of dynamic narratives of this form, that is, tightly scripted dynamic stories that have the capacity to vary both in the sequence and unfolding of the plot, and in the relationships between the protagonist and the other characters. Indeed, the very concept for FreeSpeak was built upon the idea that these two elements could be constructed to interrelate. I consider the notation to be a success, in that it fulfills its goals, and its EBNF notation was machine compilable to boot (although in need of an overhaul). But whether its goals were worth pursuing is harder to believe with any confidence.

Although other approaches for dynamic narrative exist, including simulationist systems which lie just beyond the horizon, one of the elements that marked FreeSpeak as distinct was that the writer was given direct control of the story; authorial intent remained strongly expressed. The idea that it might have been possible to compose these dynamic stories using a drag and drop editor, and perhaps even compile them into working games using a library of locations and character resources is a tantalising glimpse of a dynamic narrative system which may yet come to pass by other means. Perhaps it was not the right time for this approach.

FreeSpeak could have been adapted to work with any number of different game genres, and the example diagrams shown are from an FPS-style game entitled Shifting Sands, created solely to explore the viability of the system (unlike most FPS games, guns were a largely optional part of the play of this game). Like so many dynamic narrative systems, FreeSpeak was a victim of its own ambitions. As a semi-commercial project, it could have been brought to successful term, but as a commercial endeavour it was flawed. The inescapable problem was that there was insufficient commercial pressure for such an approach. Why should a game invest in a narrative infrastructure that could bring forward support from a minority audience when it could invest in its graphics engine and elicit support from a wider audience?

I believe in the value of dynamic narrative, and I keep the faith that we will see new systems developed. But my belief in the commercial value of these systems has wavered considerably over the years. Perhaps, however, there is a niche market that can be captured by a dedicated entrepreneur. To anyone attempting such a project, I wish you godspeed. May the passing of FreeSpeak serve as a memorial to its worthy goals, and not to its silent passing.


Feed You can follow this conversation by subscribing to the comment feed for this post.

Its interesting that your primary data structure for nouns, a personality model, is the same approach as Storytron, yet your take on the supporting nouns is temporally discrete (scene by scene) rather than spatially discrete (stage by stage) as in Storytron. I suspect the latter implies more recombinance. Also, I get a sense that your notation primarily deals with booleans and bears a heavy resemblance to a parallel FSM, which might be useful for framing the scripting efforts of a traditional genre such as an adventure game, but is perhaps less robust than a linkmesh weighted by arthimetic formulae, as you see in Storytron. This is possible because persona states in Storytron are numerical rather than Boolean, as I imagine your four relationships are.

Now I don't want to undermine your effort, or sound like a cheerleader for Crawford's efforts, but I think the distinction is non-trivial.

You are spot on when you say this is related to finite state machines; both the persona modelling and plot skeleton are exactly this! I'm not sure anyone else ever produced a compilable scripting language which generates nested FSMs though, so in this regard FreeSpeak may be unique. (I'm prepared to be corrected, however!)

(Just as an aside, there weren't just four relationships in FreeSpeak, there are as many as the writer defines; there are just four *default* relationships. Also, there were Boolean and numerical elements, as Affinities are a numerical relationship; complex variable systems can be generated, the only requirement is that to alter FSM states the variable states must correspond to keys - this is what a key is in FreeSpeak - a set of conditions to detect in the variable states).

The key distinction between FreeSpeak and Storytron (ignoring the obvious distinction that FreeSpeak is dead and Storytron is still ongoing!) is that Storytron is a simulationist system. FreeSpeak really isn't and was never meant to be!

The purpose of FreeSpeak was to create a system for designing dynamic narratives with strong authorial intent. Simulationist systems tend not to have; they can have weak authorial intent, but the very nature of a simulation focussed approach is the hope for interesting emergent behaviour instead. Of course, weak authorial intent can be just as interesting, it's just a different focus on narratives.

In regard of recombinance, I don't doubt that Storytron's approach creates more organic 'meshes'; the FreeSpeak plot skeletons are expected to be understandable as conventional narrative paths, which I doubt is possible in the more simulation-driven Storytron approach. I assume, however, one can 'constrain' Storytron and 'force' it to model a simpler narrative structure.

Inherent to the approach is the idea that conventional writers should be able to use it with minimal training. I think this is the unanswered question for Storytron - can a conventional writer use it to create a story world? The feel I get from the literature I've read is that creating a story world is more of an engineering task than a strict writing task.

Certainly, although there are some common elements, I've never considered FreeSpeak and Storytron to be very closely related. The goals of the two systems seem quite seperate, and Storytron is considerably more ambitious.

While well worthwhile, I get the impression that FreeSpeak was too ambitious; it tried to run before it could walk. If version 1.0 had started life as, say, purely a dialog engine for specifying and implementing a single two-way conversation, and then built upon that, it would perhaps have been more tractable and found more potential buyers in the marketplace. From that you could have begun to add more story-management features.

This would made an ideal university research project provided that funding could be found. Nowadays, and in Europe, it probably could.

Ernest: I agree - we aimed too high. And if I'd known then what I know now about the desire for universities to find commercial partners, I think we could have got this off the ground. Oh well...

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Your Information

(Name is required. Email address will not be displayed with the comment.)