The Conversation

With the success of Heavy Rain and the critical acclaim it has so far received, narrative is once again thrust to the forefront of game development. Like casual and social gaming have recently done in their own areas of the gaming spectrum, Heavy Rain has broadened the interactive experience in what has traditionally been regarded as the “hard core” arena. The lines that define what makes a game have been blurred once more, but what might it mean for developers in general and game writers in particular?
If the industry is to embrace stronger, character-driven narrative without abandoning the heart of what makes a great game – solid gameplay – how might we approach it? How can we structure interactive scenes and dialogue in a way to give the player gameplay control without becoming overwhelmed at the writing stage?
The key to a writer of interactive dialogue keeping control of the writing process and feeding into the game’s design and development in a constructive way is twofold. Firstly, a writer should learn to think through the structure of interactive scenes in terms of Boolean variables and secondly, they should abandon all thoughts of dialogue trees.
Although I’m aiming this article primarily at game writers, it is also intended for anyone involved in developing the structure of interactive dialogue scenes. Designers, for instance, may not have the job of writing the dialogue in the scenes, but understanding and working with the structure is important, particularly if they are the ones who need to track down and fix bugs later in development.
How much interactive dialogue a game needs or the degree to which it is implemented depends very much on the requirements of the game. This approach to interactive dialogue should always be a part of the overall development with the importance of its role defined by the team’s creative leads.

Structure and Boolean Variables
For any writers who may not know what a Boolean variable is – perhaps not having any experience in coding at any level – it is a simple variable that has just two values: True or False. The beauty here is that there is no ambiguity, which enables everything to be kept neat and tidy. But, you may ask, how will this help those writers who never go near scripts that contain variables?
While writers don’t need to learn to create logic scripts or step on the development team’s toes in this respect, they will find it incredibly helpful to think in this way, not only to keep track of the complex interactions taking place, but also use Booleans as a tool in the creation of the structure.
At the simplest level, the use of Boolean variables can stop multiple characters telling the player character the same piece of information or stop a character repeating dramatic dialogue and diminishing the drama.
One of the problems with developing interactive scenes is that they can quickly become very daunting and may overwhelm writers if they don’t have some method of structuring their approach. Yes, be aware of the larger picture, but concentrate on the building blocks themselves in a way that creates that picture.
When approaching any interactive dialogue scene try defining – in terms of Booleans – what the player character knows, what he needs to know, who he has spoken to, what has been discussed, what he has in his inventory and what his goals/objectives are. For example: Has the PC spoken to Mary? Is there a bomb in the inventory? Does the PC have the name of the murder victim?
The dialogue itself will be coloured by story, plot, the agendas of the other characters and whatever sub-plots are taking place, but controlling the information states with Boolean variables will keep the structure manageable. You end up with a lot of variables, but if they are named in ways that make sense it can be easy to track them.
It can be tempting to use variables that increment, but this can cause logic bugs which are difficult to track down and hard to fix. If you had a variable called Bill_Conversation that incremented with each subject discussed, it would only be possible to discuss topics in a specific order or the incrementation and conditional topics will break down and bugs will appear. Forcing a specific order goes against the whole idea of an interactive dialogue scene and it may as well be a cut scene.
Naming variables based on the purpose they serve and the characters or objects to which they relate enables you to manage a list of them much more easily. If we have three characters in a game: Tom (player character), Dick and Harry, we may have variables named:

 – Tom_Knows_Banana – he knows he needs a banana.
 – Dick_Spoken_Banana – Tom has spoken to Dick about the banana
 – Harry_Spoken_Banana – Tom has spoken to Harry about the banana

All these variables will start out as False and Tom cannot speak to Dick or Harry about the banana until he knows he needs to do so.
If Tom, through the actions of the player, finds that he needs a banana, we set the Tom_Knows_Banana variable to True. This in turn means that when the player interacts with Dick, say, we can trigger the part of his interactive scene that’s conditional on this variable. When Tom has discussed the banana with Dick we set the Dick_Spoken_Banana variable to True. Not only can we use this to stop Tom and Dick talking about the banana again (unless we specifically want them to), it also acts as an information flag that Tom is effectively carrying around with him from this point on.
If the player interacts with Harry, he and Tom can talk about the banana. Tom and Harry may talk before Tom and Dick, but we’ll assume that Tom has already spoken to Dick about the banana before talking to Harry. Tom asks Harry about a banana and he then tells Tom that Dick likes fruit and might have one. Because Tom has already spoken to Dick, the variable Dick_Spoken_Banana is True and triggers a nested condition where Tom explains that he already asked Dick. In scripting terms it may look like this:

IF((Tom_Knows_Banana == True) && (Harry_Spoken_Banana == False))
{
[Ask Harry about the banana. Harry says Dick may have one.] IF(Dick_Spoken_Banana == True)
{
[Tom says he already asked Dick.] }
Harry_Spoken_Banana = True;
}

Obviously, talking about bananas is a very simple example, but even this can get complex if the number of characters increases or the route to getting the information about the banana has additional gameplay complexity. We may, for instance, introduce another interactive character, Sally, who will only say something important after Tom has spoken to both Dick and Harry. This part of Sally’s scene is then dependent on both variables Dick_Spoken_Banana and Harry_Spoken_Banana being set to True.
What you may notice is that although we’ve potentially created a lot of structure, there is no dialogue. While we establish the structure dialogue is irrelevant – writers can have the fun of creating that at a later stage. In a sense, this has a parallel with the scene creation approach to film scriptwriting, but in terms of game writing it becomes potentially much more complex. A typical film might have around forty scenes but a game may have hundreds.
One particular beauty in this structural approach is that the development team can see the shape that’s forming much earlier because they don’t have to wait for the dialogue. The gameplay implementation of the interactive scenes can take place before the writer has completed the dialogue, which will likely benefit schedules and milestone targets.

No Dialogue Trees
Some people may think it an absolute necessity to have dialogue trees in order that scenes will be fully interactive, but I find that thinking in terms of dialogue trees is distracting. In seventeen years of developing interactive dialogue scenes I’ve never used a branching tree structure. I find that the structure I outlined above is far more flexible and enables the writer to think of each discussion topic as a separate building block but linked and perhaps modified by the use of the Boolean variables and what those variables control.
To me it’s much clearer when approaching a scene to think of all discussion topics as being at the same level. The availability of the topics is controlled through the script by the Booleans as described above. After discussing a topic the dialogue engine should return back to that same level to enable the player to choose the next topic.
One of the problems of developing dialogue with a tree structure in mind is that there is often the need to copy whole sections of dialogue into new places in the tree in order to get them to trigger in the right way. This strikes me as very clumsy and a huge waste of time. If dialogue needs to be copied and pasted anywhere, then there is likely to be a problem with the scene structure or the system that drives the dialogue.

Further Complexity
There may be times when the “flat” approach to topics will need to deal with a second layer temporarily. The writer may want to give the player choices that have different outcomes and doesn’t want to return to the main level and confuse the issue with topics that don’t have an immediate bearing. An interrogation, for example, may throw up critical information that the player character concentrates on until the resultant sub-topics have been exhausted.
This second level of topics is not a tree structure and can best be described as a nested level of topics. It should be thought of in the same “flat” way. In scripting terms you might think of it as a kind of “while loop” where the conversation is held in this level until the condition for release is met, at which point the system should return to the original topic level.
Many games will not have a need for the complexity of multiple levels, but if it is required the team needs to ensure it is built into the dialogue system.
Emotions are a further way to add complexity, particularly if the choices the player makes and the actions of the gameplay have an effect on the emotions of the other characters. If the player has done something to make Dick angry with Tom we may set a Dick_Angry variable to True and create conditional dialogue within the interactive scene that is triggered by this variable. It may be, for instance, that Dick refuses to talk about anything at all while he’s Angry with Tom, in which case the player may need to discover a way to placate Dick before he can get the information he needs. Or the player may need to discover another way altogether to get that same information.
As mentioned before, how much complexity you need is dictated by the requirements of the game and how important interactive dialogue is to the experience you want to give the player. Take these ideas and adapt them to your needs.

Conclusion
In many ways, approaching the writing of interactive scenes is blurring the boundaries between writing and design, which is not a bad thing. The more they become intertwined the better integrated the story and gameplay will be. The two aspects will marry closely and share a clear vision.
Because Boolean variables can only be True or False, it may seem that there is a danger of losing the spectrum of subtlety. They are not there to define the subtlety, or the lack of such, but control the structure within which the team creates the subtlety. The use of multiple Booleans working together will create its own subtlety, of course, but the real subtlety will always come from the writer knowing the characters well and knowing how they will react to being teased, seduced, interrogated, etc.
The interactive structure is not a substitute for good writing, but a tool that enables the writer and designers to make it work in the best possible way for the player.

Steve Ince is a games writer-designer with 17 years in game development. After 11 years with Revolution Software, Steve turned freelance in 2004. In 2008 he received an award nomination from the Writers’ Guild of Great Britain for the game, So Blonde.