These rehearsals and accompanying improvisations provide Mr. Leigh with what he calls the “raw material” from which he shapes the movie. Yet even when shooting is under way, there is no script, something that posed an interesting situation when Mr. Leigh was nominated for an Oscar for best director and “Vera Drake” was nominated for best original screenplay.

“I have just had to prepare the screenplay so it can be sent out to academy members,” he said. “But actually the screenplay that was nominated doesn’t exist. The film is the screenplay. So when people ask me if I am more writer or director, I don’t know the difference. It’s the same thing.”

… “In terms of the way I do it and the things I try to say, there is absolutely no distinction between film and theater.”

In our work Michael and I been referring to the organizing framework of clusters of reactive behaviors as “beats”.

I’m not clear on why that would follow.

Yes, actually I am imagining creating behaviors specific to a character — in fact, often specific to a character in a particular situation. That is, just as you might write a particular scene to be unique and specific, a behavior programmer (in the role of the writer) would write specific, unique behaviors. However, there could be a lower-level set of common behaviors for that character, that could get re-used some in various situations.

To set up the coding for a behaviour that happens once is probably not the best way to utilise resources, better would be to code the tools which allow the writer/implementer to create the iniqueness of the scene in an efficient manner.

True, this is an expensive, time-consuming way to author, but it gives you the best results. Making this kind of authoring more time efficient is a major issue.

By the way, how do I get to play Facade?

We’re just debugging it now, and finishing up the audio. We’ll be sure to let everyone know when it’s finally ready!

I’m not aware that Revolution has published any information about it. I don’t think there’s anything fundamentally special about the language, just the way the tools enable us to use the language and the way the engine takes what we would write and do cool things.

A) “It will become necessary for writers to be engineers.”
B) “It will become necessary for engineers to be writers.”

How many readers opt for claim A? How many for claim B?

Lack of communication is one of the biggest problems in developing tools.

I remember a situation a number of years ago and a writer I worked with at the time asked one of the programmers to give him a text editor, so he did. The writer then claimed it was unusable because all it did was edit text. It turned out that he actually wanted a degree of formatting, a way to keep track of variables, colour coding, etc…

The writer had assumed that the coder would know that this was what was wanted. To the coder, a text editor was something very specific that he delivered. They just weren’t talking the same language and hadn’t reached an agreed specification beforehand.

One problem with tools is that there is always the danger that they will be seen as a way to create content rather than a way of enabling the efficient creation of content. It’s like the screenwriting software that you see advertised for those who want to break into the film industry. It’s only an aid – the potential screenwriter still needs to create the story, scenes, characters, etc. In some respects, I don’t believe that the development of behaviours is the creation of content, but part of the process that can be used to create the content.

BTW, I’ve had this discussion before. For half a year, I’ve shared office space with some of the developers of alVRed, a virtual reality authoring tool (I believe that Michael Mateas mentioned receiving a copy of that software at TIDSE 2004, or something, so the GTxAers might have looked at it). I tried to convince them to look into what writers actually do before writing software that is supposed to help writers write. They wouldn’t. That software never worked for me.

There are always limitations to writing. A novel is different to a stage play; an animated film is different to a radio comedy. The trick is in learning how to deal with those limitations in a creative way. If you know the limitations at the start of a project a writer should be able to adapt and make the best of those limitations. The difficulties in writing for games is that the limitations vary so much from game to game, genre to genre and are changing all the time – mostly for the better.

The role of the writer varies, too. I’ve recently been talking to one company that simply wanted a story on which to hang the game. My involvement with the development of the game would have been virtually non-existent once that was done. Another company were really insistant that the story provided the motivation for the gameplay and so the process was more complex and involved me working with the team in order to develop the story in a way that wouldn’t conflict with their vision of the gameplay.

The more the story and gameplay can be worked on in parallel, the better, in my view. The game will have a more whole feeling to it.

When I worked with Revolution, I was able to work with the coding team to develop a set of tools which enabled the implementation of the gameplay to be devolved to the design team. What this meant was that a scripting language was created that was much more “readable” to a non-coder. The tools became very sophisticated and even had a view that enabled the implementer to look at a scene in a way that is similar to video editing software. Tracks could be linked to one-another with time offsets and characters could be given parallel tasks to perform, lines to speak, etc. Wrapping the scenes in logic also meant that they could be made to play out differently depending on whether a character has already spoken to character A or not.

Of course, writers don’t always get the chance to work directly on the scenes of the game and must rely on interfacing with the people who are implementing. In some respects, the people are part of the tool chain that the writer must work with.

Programming is vital to support the aims of the writer, and particularly to do so in a way which complements the vision of the gameplay. There are a great numbers of ways to make writing both more dynamic and more subtle. The introduction of subplots and more developed character motivation will make the wider story more dynamic, for instance, whereas the subtleties of subtext, facial expression and body language will enrich the scenes themselves.

I find the idea that writers run their characters through a series of behaviours in their head a strange one. That would imply that we plan out lists of behaviours and then run a simulation until the scene plays out in the right way. It certainly doesn’t work for me like that (unless it’s on a subconscious level). I never think of my characters in terms of behaviours as I’m writing, but of characteristics.

I know that if you want to create a generic character that behaves in a realistic way, you have to create rules and behaviours, but that only works where you are dealing with generic conditions. In a complex and subtle scene the conditions will be unique to each scene and so the behaviours will be unique. To set up the coding for a behaviour that happens once is probably not the best way to utilise resources, better would be to code the tools which allow the writer/implementer to create the iniqueness of the scene in an efficient manner.

(I went on a bit, sorry…)

Rather than asking you go off and read about the behavior authoring language in discussion here, as I rather bluntly suggested earlier (sorry), let me ask a more general question:

As a writer, to what extent or in what ways, if any, have you felt limited by the tools / framework that you write in?

For example, if you wanted to make your writing even more dynamic, varied and reactive, do you feel the tools and framework supplied by the engineers you work with are enough? Do you get a chance to collaborate with engineers much on establishing this framework? Theoretically speaking, does programming seem like a fruitful direction to move towards, or a bad / unfeasible idea? Or, perhaps, you’ve already reached a comfortable point of complexity in your writing, and don’t desire or need to make it more dynamic?

Finally, what do you make of my suggestion that (some) writers invent and sort of simulate behaviors in their minds in the first place, when they write? Which is what behavior programmers have to do explicitly.

Andrew, this is why I’m not an engineer. :)

Does precondition and context_condition simply mean that you’re checking for variables to be true?

The scripts I’ve worked with have always checked for variables so that a sequential script will depend on what the current conditions are. Also, if I wanted to have two things happening in parallel I would simply run two different scene scripts and have one wait for the other if necessary, perhaps on a while loop.

I may be screwing with what you’re trying to discuss, but I was asked to contribute. :)

Steve, you’ve focused only on the sequential part of the behavior code example, and ignored what’s going on with the code that use the keywords parallel, precondition, and context_condition. It is that type of code for which straightforward declarative writing is an insufficient substitute. The best way to get more detail about what those parts of the code are accomplishing (and other such behavior code commands) are to follow the “Um, hello” links at the top of the Hard to Believe post from a few days ago.

I’ve already worked on games that use this approach with an engine that allows me to do exactly that. The commands are functions written by the engine’s coders which are interpreted by the implementation tools at build time.

The command to change a charater’s mood means that the engine changes the face of the character to fit the morph target settings that have been pre-defined for that character in that mood.

Routing a character to a door shold actually be to a point that’s offset from the door handle that exactly matches the position the character needs to be in order to run the anim to open the door and have his hand interact properly with the handle.

In the example that andrew introduced and that you expanded upon, the NPC gets imperative calls from a “Drama Manager” module, ordering it to “look surprised”, “stand up”, etc. Thus, the NPC is not an “autonomous agent”; andrew and michael explain their reasons for limiting the autonomy of their characters in “Towards Integrating Plot and Character for Interactive Drama”. Put short, there’s an “intermediaton layer” involved – the PC might think that s/he is talking to the NPC, while actually s/he’s talking to the Drama Manager, who then talks to the NPC, making it react.

While this approach offers certain theoretical advantages that are elaborated on in the paper linked to above, in practice, it also has at least one serious disadvantage. Rob Zubek commented on it in this thread, writing:

But intermediation reduces transparency. Now errors can occur at either stage of intermediation: both translating surface text into communicative acts, and then using those acts to ‘understand’ the given situation. And when things go wrong, the players gets very little information about what happened.

I think that this is true enough for me to stay away from the Drama Manager model. The approach that I’m taking instead gives all the generative power to the words themselves; the goal being to come up with something that I call “self-managing text”. In this model, words – the smallest units of text – behave like atoms. Atoms bond to other atoms, forming larger structures called molecules. The probabilities of certain atoms bonding with certain other atoms are not fixed, but vary according to the environment (the context). Thus, there is no global control, like when using a module to manage text generation; instead, each single word responds locally to changing global conditions (which it gets informed about via the system bus) by bonding with and/or repelling other words. The molecules that form that way may react with other molecules, building text structures from the ground up.

I didn’t come up with this wonderful “words as atoms” metaphor – that was Yuri Tarnopolsky, who buildt on Ulf Grenander’s Pattern Theory. However, I can say that I built the first simple systems that worked that way two years before I came across Tarnopolsky’s paper, and was pleasantly surprised that somebody had already devised a theory that fits my own practice so well. Anyway, for me, Pattern Theory provides an excellent tool for further development.

So the bad news is that there’s still no way for a writer to write a command like ‘play anim mood (player) “look surprised”’, and have it interpreted correctly by an engine. The good news that at least two parties are working towards it, taking roughly the same approach, but applying it to two different levels of abstraction.

Procedurally, this could be written as follows…”

Wouldn’t you just have an engine that handled all of that without the writer even knowing it’s there, so it becomes

play sound fx “knock on door”
play anim mood (player) “look surprised”
play anim (player) “stand up”
route (player) to “door”

etc.

As a writer, this is the closest I want to get to any engineering. :)

So, when I asked the question, I wasn’t thinking about a specific drama, but was seeing if there were any generalized solution.

One general-purpose story-structuring tool that seems to work for non-interactive writers like George Lucas, Joanne K. Rowling and Quentin Tarantino is Dramatica. From my experience, it also works well for interactive writing, if I make the PC one of the two subjective characters in the model.

Sorry, the minor idea was the details of implimenting the more major point. BBSs and E-mails never seem to communicate as clearly as face-to-face conversations…

Just as an example, in Facade, during a particular beat of the drama a character may ask the player what you think of her decorating; without telling you, she’s actually fishing for criticism here, and so for that beat, praise is mapped into disagreement, and criticism is mapped into agreement. We call such mappings contexts, and we author different contexts for different story beats. This way, the same words from the player can have different meanings at different times, as appropriate.

Thanks, good info.

Building behaviors involves putting what you need into the system for your particular drama.

I didn’t go into details, but in my case, it’s not that easy…

I’m developing a tool that lets amateur authors write graphical interactive fiction, and/or a graphical MUD. (Think of Myst III’s or Zork Nemesis’s 360-degree surround images combined with a text parser and text-to-speech, along with images of characters and objects in the room.) Personally, I think one tool can cater to both types of authors. Some IF and MUD authors will undoubtedly disagree.

I just read Chris Crawford’s book and discovered that an interactive storytelling crowd exists. From my (naive?) perspective, I see interactive storytelling as a virtual world where emphasis is placed on NPCs and a plot. (IF tends to emphasize place, while MUDs emphasize other players.)

So, when I asked the question, I wasn’t thinking about a specific drama, but was seeing if there were any generalized solution. I was also considering the problem in the scope of a really-really large world where players could logically wander from town to town “lying” to NPCs. Should a player’s reputation follow? If so, what are the mechanisms? If the reputation doesn’t follow, then players will continually lie and perhaps break the purpose of the mechanism.

Just as an example, in Facade, during a particular beat of the drama a character may ask the player what you think of her decorating; without telling you, she’s actually fishing for criticism here, and so for that beat, praise is mapped into disagreement, and criticism is mapped into agreement. We call such mappings contexts, and we author different contexts for different story beats. This way, the same words from the player can have different meanings at different times, as appropriate.

Chris Crawford’s latest book goes into detail about his particular approach to modeling interpersonal discourse.

Nick — yes, I should refine my argument to say this concept really only suggests a way of writing, not the way all (or even most) writers work; and like I mentioned earlier, it’s an oversimplification in any case. But I’m hoping one can see the overlap between writing and engineering I’m talking about. Like you suggest, it may only partially match certain writers’ styles — or perhaps it’s an even better match for certain genres of writing, like melodrama or pulp fiction, or better match forms such as theater or TV, versus contemporary literature. (I’m a huge fan of the O.C.!)

I rather doubt that Harry Mathews, Walter Abish, Robert Coover, and John Barth do anything remotely like that when they write. I would guess that Paul Auster, on the other hand, might. It appears, at least, that he sets up startling plot events and then plays out how his characters would react to them, what they would do and say. Still, this is my fanstasy of how he writes; I don’t actually know that it is his process.

If you were to ask me which writer listed above is the most like an engineer, though, it wouldn’t be Paul Auster. There are other ways that writers can engineer literature, ways that focus on language rather than characters and motivations.