December 8, 2004
Head Games
Branching off our recent believable character discussion, I’d like to say something about writing, gameplay, and their interrelation. In that discussion, Ian W. suggested:
[Writers] are not likely to be engineers. Even if they are the roles are very different and their tools should reflect that.
I’d say, the roles aren’t very different actually. In fact, it will become necessary for writers to be engineers.
How are the roles not very different? Writers in any medium are creators of character behavior; they invent motivations for characters, and from that create what their characters do and say. In non-interactive media, such as books and plays, as a writer works, she plays these behaviors out in her mind and narrates them into pages of text. In interactive media, such as games, the behaviors themselves are written down, as procedures — pages of code annotated with surface text. The computer executes this program, animating the characters to speak and act. In each approach, the writer’s thought processes are very similar! Sure, it may be more work to write down the behaviors themselves, than to simulate them in your mind and narrate the results, but the creative thinking behind both is similar. It takes some training to learn how to write behaviors — that is, to program — but it’s do-able. If a writer for a game is only creating sentences of dialog, then she is only doing a subset of the actual task of writing; the engineer who coded the behaviors that play out the dialog has actually been a co-writer all along. And — all this answers why writers need to be engineers, or at least collaborate very closely together.
Ian W. also wrote,
would interactive writing really be procedural when the field is more mature?
I’ll flip this around — interactive writing will be more mature when it becomes procedural.
Related to this, speaking for what game developers are saying, Robin wrote:
[Developers] know what [they’d] like (believable actors who emote, who generate/support empathy, etc.) but… how does that dovetail with “gameplay”, exactly? How do [developers] make strong characters and still come away with “play” and not “entertainment”?
The gameplay will literally need to be about the characters themselves. The “state space” the player manipulates — the variables you affect, the values you change — need to be the feelings, emotions and thoughts of the characters, not just external counters, scores, levels and objects.
Rather than just firing a gun to cause an enemy’s health to decrease, or a crate to explode or a door to open, you’ll fire off discourse acts such as praise, criticism, expressions of feeling, requests and ideas; the other characters’ attitudes will immediately change, emotions will get generated, and new actions will become motivated and get performed.
What kind of game would that be? It could be the game of persuasion, or negotiation, seduction, or communication, for example. The kinds of games we play with each other all the time, really.
These psychological games can be integrated with action games — running, jumping, shooting, exploring. Games will become richer when players have to simultaneously play head games and action games, especially when the results of each game has secondary effects on the others.
Writing these psychological games will be about writing behaviors, as mentioned above. The behaviors will be part of the overall set of behaviors for the game; code to control how NPCs act physically are one and the same as the code that causing dialog to be spoken. After all, characters speak and act simultaneously! Speaking and action from the player can cause speaking and/or action from NPCs; it’s all the same thing.
One thing I’ve learned, these feelings, emotions and thoughts that the player are affecting will need to be displayed immediately, otherwise players won’t feel they are having an effect. This will be very challenging to do, but critical. I think this is one of the weaknesses of our interactive drama; too often, players don’t see the effects of their actions being displayed back to them in an instantaneous way. The truth is, it’s difficult to fully display the state of a character you are affecting in real-time — unlike displaying the state of a city or environment you are creating or demolishing.
And even if we did know for sure – how would we get the time/mandate to build it? Would it help sell games if we could only do this only *halfway*? A quarter of the way? What’s the low-hanging fruit? What’s the middle ground?’
To do this at all, a core requirement will be to give players a set of relational verbs — natural ways to express interpersonal feelings, attitudes and ideas. There’s little way around this hit; players will need more than controller buttons and joysticks for activating weapons and maneuvering. I’m not sure anything but language will work here — this means keyboard input, for example. (Does this mean consoles without keyboards are incapable of delivering this experience, short of robust speech input, which is much harder than understanding typed input?)
The fruit is lower than one might think; the domain of the game will limit what needs to be understood. In a war context for instance, between you and your NPC buddies or enemies, there’s a finite range of emotions and attitudes that needs to be understood by the system, and therefore hopefully a reasonably-sized state space to manage.
But I don’t think there’s any super-low hanging fruit. Anything interesting will require giving players, say, at least 10 juicy new verbs. But even a game with just 10 new verbs, that can be used at any time in any context of the game, would really go a long way towards enriching the play experience.
December 8th, 2004 at 9:18 pm
What an interesting post, Andrew. I think you misunderstand writing, but in what may well be a productive way.
I don’t think writers play out events in their minds and then simply transcribe what happened. A lot can (and does) happen between the mind and the screen, and lots more also happens during revision and editing.
Basically, I’m making a process point. Wonder if something similar does not hold true on the engineering side.
December 8th, 2004 at 10:51 pm
True, to help draw together writing and behavior programming, I’ve oversimplified the writing process, left plenty of things out. And surely not every writer works in the way I described.
However, that common writer’s adage, “as I write, I don’t have a grand plan for the story, I just let the characters take me there”, I think also jibes nicely with the processes I’m suggesting here.
December 8th, 2004 at 11:42 pm
Hi Andrew,
You don’t misunderstand writing. This post’s predecessor has had far too much in-depth discussion for it to end like that.
FYI, I just finished my doctoral thesis on an interactive storytelling system, and I’ve barely scratched the surface of the field. But enough of that, on to the rant-
A key distinction that traditional, or hypertext, authors seem to consistently miss is that of the interactivity that needs to be built into the very core of the storytelling for the thing to work. A focus on the player/interacter and what they’re doing should inform everything that happens in the experience, and this is when the science/humanities divide of our culture makes us hit a brick wall.
What happens ‘between the mind[of the author] and the screen’ is what has to be engineered, so that the “conversational boundaries”(sic) between the player and author is explicitly modeled as an interaction mechanism that effects the dynamics of the experience. The ‘low fruit’ in this case would have to be the more abstract representations discussed in the previous post, but for me, the key to creating believable characters in every case would be tied to the storytelling aspect of the experience.
If the characters’ actions don’t tie into other events in the story, doing things that, while consistent with internal models, are irrelevant to the plot, believability is adversely effected as much as when a character model’s geometry doesn’t work right.
Discworld noir is one game which takes your suggested approach for game interactions as ideas,thoughts,emotions,clues… and creates a great adventure game out of it. This sort of interface, and game mechanics based on character interactions, is what games can do already, but the interactivity of the plot as an independent entity still has not been addressed.
The game design maxim you’re referring to in ‘these feelings, emotions and thoughts that the player are affecting will need to be displayed immediately’ is just as true when you think of the plot as an interactive component, and for me the more impassable valley is that between traditional authors and engineers.
‘Just what was going on in his head when he wrote that story – and how can I code it?’
This is where barriers have to be broken down (& bridges built). It’s mutually beneficial for both sides to learn more about the other’s area of expertise, and interactive story creators most definitely will not be creating machines to take away writers’ jobs (as the NYT recently said – well, maybe bad writers) because these systems require considerable writing talent as well as engineering talent.
Anyway, my point is that authors have to able to use tools to create interaction spaces. Creating limits for character and plot simulation systems using rules that govern how the systems react to player interaction. Creating behaviours is not enough. The behaviours have to be a part of a larger, coherent, interaction scheme.
Me out
December 9th, 2004 at 5:03 am
Thank you very much, andrew, for this insightful post. It resonates very nicely with my own experiences during the past years. My main discovery was that writers have been engineers all along, and that the tradition of our shared culture can be tracked back at least to Aristotle’s time – and that’s only looking at the Western node!
An example: many writers, especially when working in the TV/movie business, like to break down their scrips on scene cards – they write on stock 3×5 cards that represent scenes, with more cards – perhaps in different colors – on which they note ideas belonging to those scenes, dialogue, character actions, thematic connections, etc. They use the floor of the largest romm they have, or the walls, lay out the cards and connect them with bits of string. Then they write the script, working on their diagram as they go along, adding cards, revising connections.
I found out that this is exactly what is done in object oriented program design: creating a set of networked objects that perform certain functions. In fact, a writer who likes to work this way might as well learn the UML in order to replace working on floors and walls with working on screen; it’s much easier to manage a virtual scene card system than a real-world one once you get the hang of it.
Computer programming is just one form of programming that writer’s have been doing since writing began. A novel, a movie script, even a newspaper article: they all are programs, designed and written to be executed on intelligent machines called humans. To enhance and improve communications between these intelligent machines, we are just now learning to use somewhat less intelligent machines called computers to act as our intermediaries – as media. This, to me, is what “interactive writing” is all about.
December 9th, 2004 at 7:50 am
A couple of interesting parallels between tools and creation methods here. I would tend to disagree about writers and programming. Writers / artists should have tools to create without the requirement of programming. The important distinction here is between, in a toolkit for example, being able to define “what” you want (i.e. behaviors) and actually, in a development environment, having to program “how” those behaviors are built. A writers medium is natural language rather than a programming language. This is a distinction between a declarative approach to creation and a procedural one and forcing the later over the former removes the writer from their ideal process. An analogy would be of having a movie director also build the camera.
A sucessful toolkit would abstract away this lower layer and give the writer a more natural interface from which to create, and in fact most behavior systems have at least a drag and drop way of tieing up behaviors to create scenes in effect. This is in essence declarative rather than procedural creation.
With interactive “writing” (which is not just writing dialogue, naturally) again I would tend to disagree with the procedural idea. I believe you will move to either an entirely declarative / event driven model or perhaps, more suitably, a mix of event based and scripted (as in the movie sense, which is procedural). Again, with a procedural approach you are defining exactly “how” a scene, for example, plays out rather than defining “what” you want to happen or encourage in the scene.
Procedural works fine with non interactive media where you have control over all of the variables and a contract with *all* of the actors but with interactive the most important actor has no contract to do as you would like and you have little or no control over what they do within a scene. That actor is of course the player. This would seem to break the purely procedural model? What you move to then is not directing but influencing, through events (btw, I use events to mean actions, dialogue and anything else rather than adressing them as separate items) how the player moves through the experience.
Games such as Half Life 2 (which I have looking at recently) do this well within their limited scope. As an “action” experience it is not too distracting that while you are being influenced to take certain paths and make certain choices your options are severly limited. I have heard it called being on rails but it is more like having a very constrained world in which to interact. This is a mix of event based and procedural that works well in its context. Events happen that “push” you though an environment where the story essentially “emerges” from these events (while it is actually scripted behind the scenes).
This I feel is where this new art is being born, essentially like a skilled “game master” you will, through subltle influence, “guide” the player through a constrained plot using events to create an emergent experience. Perhaps I am misunderstanding your definitions Andrew as I thought Facade (when I played it) followed this definition rather than being a purely procedural pattern? My experience was that the events I triggered myself lead to the emergence of a story?
I think the “low hanging fruit” will come from constraing the worlds and hence reducing the possible events (again, like Facade, and no, Andrew is not paying me ;) Also we should remember that there are *already* many games out there (especially MMOGs) populated by lifeless characters. Any improvement to those is a bonus and an easy win.
Typical of large publishers I would also say tieing these experiences to movie or especially TV licenses would offer a number of advantages, namely 1. Well understood roles and character behaviors, 2. A back story, 3. A prior emotional engagement with the characters, 4. Good PR. A typical house bound sitcom would fit the bill (“Friends” etc) which could be episodic but inject the player into the episode with perhaps a predefined role or purpose. The skill, initially, with interactive writing is to subtly steer the player away from areas for which you have no content or story and towards the areas around which your story revolves.
December 9th, 2004 at 10:32 am
Hmmm… How about this?
On GTxA one of the things we’re interested in is authoring within technical and social/geographic systems. It seems likely that more writers will be doing this, over time.
We’re also interested in the author of such systems.
And the boundary between these two types of authoring is fuzzy, and its placement somewhat arbitrary (a writer could be taking on any level of system authoring, certain levels of system authoring probably are sensibly called writing, etc).
There’s also a long history of this sort of thing. After all, what were the Oulipo but writers who designed systems and wrote for them? What else were the creators of new poetic forms? New forms of performance? Sure, once we get into performance you could start arguing that it’s really directing/acting/dramaturgy rather than writing — and then you’d be right back in a discussion like the one about programming rather than writing.
In short, I think the connection Andrew is drawing is an appropriate one — but it might be a closer connection to innovative writing practice than everyday writing practice. Most writers are writing within systems, but not all are thinking of authoring/altering the systems at the same time.
December 9th, 2004 at 12:56 pm
Noah, good point about the distinction between writing and directing — that had occurred to me when writing this post, but to keep my argument simpler I left that out. My response would be, I tend to view interactive works as performances, since they are performed in real-time as a collaboration between the player and the system, so the tension between what-is-writing and what-is-directing is there. For this we can look to the parallel examples of filmmakers and stageplay dramatists who are simultaneous writer/directors, for whom the creative process may not distinguish between the two a whole lot. (Woody Allen and Neil LaBute are my favorites. :-)
Most writers are writing within systems, but not all are thinking of authoring/altering the systems at the same time.
Aren’t writing behaviors writing within a system, though? Programming is done within a language and an architecture. Writing procedures are a meta-level above writing declaratively, but there is a meta-level above writing procedures as well, which is system building.
Let’s remind ourselves that text-based IF writers have been programming their writing for decades… (albeit typically in languages that afford a limited level of complexity.)
Ian, just to clarify what I meant by “interactive writing will be more mature when it becomes procedural” — I mean “writing” as a noun, not a verb. That is, when the writing becomes procedures, when the process of writing becomes the process of writing down procedures, i.e. programs. (Of course, the act of writing itself, for any medium, is a process, and therefore is itself procedural; but I’m talking the nature of what is being written down.)
Ian, yes, there may be a way to do declarative authoring of character behavior for interactive entertainment — it requires shifting much of the burden of authoring to the system. That is, like you suggest, a writer would give a set of declarations of the kinds of things they want to happen in a scene; the AI would essentially generate some behaviors that cause those events to happen. But there are several issues with this. One, the loss of authorial control; the writer is now sharing control of the writing with the AI. This may turn out well, if the AI is good at what it does, or it may feel very limiting. Declaring what you want to happen, rather than the procedures of how to get what you want, is underspecifying the experience you want to create.
Two, it’s a very ambitious task to create the kind of AI you’re talking about — a system that can take declarative writing and generate interesting, varied behaviors, that satisfy the human writer. It’s hard enough to manually write a specific, custom version of such behaviors in the first place (the method I’m suggesting), let alone a system that can generate those behaviors for you based on declarations of what you want them to do. In the short term, interactive stories will be more successful if writers engineer their own behaviors, rather than waiting for a tool that does much of the work for them. But it’s a really interesting direction to talk about, a great topic for future discussions.
Finally, to respond to your point about constraining the story world, the extreme version of this being “on rails” — sure, constraining the potential directions of the story is a necessary task when designing and implementing an interactive story. Yes, we did this in Facade, although strived for as much procedurality in the management of the sequencing of the story as we had time for (we wanted to do much more :-). I agree that the art of designing such constraints is a very important aspect of all this — but I see it as independent of the issue of writing procedurally vs. declaratively. When you suggest that constraining the story is a way to handle the player’s unpredictable actions, well, that’s true, but that reduces agency; instead, let’s have writers write procedures that are designed to handle a broad range of player action, as a way to offer some true agency.
December 9th, 2004 at 3:55 pm
I may be misunderstanding your distinction, and am admittedly only partly familiar with the internals of Facade, but would someone writing an interactive experience like that necessarily have to do all the procedural programming as well, once the infrastructure’s been written? I think there could be a useful distinction between building a beat-based drama manager, which is programming, and then actually writing a bunch of beats and hooking them up to the drama manager, which is authoring. At the moment authors have to do both, but I would hope in the future that at least some of that work can be done ahead of time. Do authors really need to implement their own custom drama manager from scratch each time they write a game in order to have enough freedom to make interesting stories?
December 9th, 2004 at 4:17 pm
In the case of Facade, the infrastructure is comprised of the ABL internals and its language, the drama manager and its language, and the NLP infrastructure and its language. In the case of, say, text-based IF, a commonly used language and infrastructure is Inform / Z-Machine.
A writer (author) then programs behaviors within these languages. This is the writing process I’m referring to — the process of writing procedural behaviors in such languages. This is authoring. A new drama created within the Facade system would require writing/authoring new behaviors in the drama manager language, writing new ABL behaviors, and new NLP rules. (It just so happened that Michael and I also originally programmed the infrastructure itself, that we then programmed within.)
When an IF author programs in Inform, similarly, they are writing procedural behaviors.
(Game developers often call authoring “scripting”, but that term has come to mean relatively simple programming in relatively simple languages; the baggage of this term has caused us to avoid using it.)
Sorry for the confusion… hope this clears it up.
December 10th, 2004 at 2:03 am
My brain focused on a minor idea in the blog:
Andrew wrote – Rather than just firing a gun to cause an enemy’s health to decrease, or a crate to explode or a door to open, you’ll fire off discourse acts such as praise, criticism, expressions of feeling, requests and ideas; the other characters’ attitudes will immediately change, emotions will get generated, and new actions will become motivated and get performed.
Real people eventually learn (a) if you’re being two-faced and praising them to their face but putting them down to others, and (b) if you’re overly generous with praise (or scorn, etc.). Thus, praise from someone I know to be a backstaber actually makes me worry, and praise from someone that praises everything is worthless. (Conversely, praise from someone that seldom praises is worth more.)
How is this modelled in NPCs?
I can think of a few ways, like providing less value to a player’s praise verb the more often it’s used. Or, for NPCs to somehow learn if the player is praising the NPCs enemies, or being disingenous. What if a NPC couldn’t know that the PC was being two-faced? Should this be modelled too? Does it give the PC too much power to lie?
Are there any other solutions?
December 10th, 2004 at 2:45 am
Mike there could be other ways, people who over praise, the interface could start forgetting other verbs, or when people praise too often maybe the dialogue misinterprets, scrambles it, makes they eyelids go crazy, speeds up delivery (audio or chat), increases reverb etc of sound cue or makes the avatar spin around etc..maybe the interface says: this word used XXX times and bops the character on the head with a thesaurus. Gee that would be scary for some world chatters!
Andrew-an author-a writer who writes behaviors-is there a more exact technical term?
December 10th, 2004 at 10:15 am
Mike wrote,
My brain focused on a minor idea in the blog
The concept of “head games” and discourse acts is one of the two main points of this post — not a minor point! :-) I’ll respond to that later today, but first, in the previous believability discussion, Erik C asked,
a little confused by notions of procedural and declarative here, are there online definitions of it as used in interactive fiction/storymaking etc?
I’ll answer that here, in this discussion of writing behaviors. Let’s say we want an NPC to greet the player character at the door. Declaratively, I’d imagine this would written something like:
while hanging out in my apartment, if someone knocks on the door, act surprised, open the door and greet them with “Hi, how are you?”
Procedurally, this could be written as follows — this is pseudocode of some ABL behaviors to accomplish this, a bit simplified to save space:
parallel behavior HangOutInApartment() {
subgoal StraightenUp();
subgoal MonitorAndAnswerTheDoor();
subgoal MonitorAndAnswerThePhone();
subgoal RelaxOnTheCouch();
subgoal ReadBlogsOnMyLaptop();
}
sequential behavior MonitorAndAnswerTheDoor() {
WME w;
with (success_test { w = (KnockWME) } ) wait;
subgoal FacialExpression(expression_surprised);
subgoal Speak(“Oh! The door!”);
subgoal SignalForGuestToEnter();
subgoal GreetGuest();
mental_act { deleteWME(w); }
}
sequential behavior SignalForGuestToEnter() {
// If too far to walk, yell for knocker to come in
precondition {
(KnockWME doorID :: door)
(PosWME spriteID == door pos :: doorPos)
(PosWME spriteID == me pos :: myPos)
(Util.computeDistance(doorPos, myPos) > 100)
}
specificity 2;
subgoal YellAndWaitForGuestToEnter(door);
}
sequential behavior SignalForGuestToEnter() {
// Default behavior – walk to door and open
precondition { (KnockWME doorID :: door) }
specificity 1;
subgoal WalkTo(door);
subgoal OpenDoor(door);
}
parallel behavior YellAndWaitForGuestToEnter(int doorID) {
precondition { (CurrentTimeWME t :: startT)}
context_condition {(CurrentTimeWME t [= startT + 10000)}
number_needed_for_success 1;
with (success_test {{DoorOpenWME door == doorID)}) wait;
with (persistent) subgoal YellForGuest(doorID);
}
sequential behavior YellForGuest(int doorID) {
subgoal LookAt(doorID);
subgoal WaitFor(random(1.0, 3.0);
subgoal Speak(“It’s open, come on in!”);
}
parallel behavior GreetGuest() {
precondition { (KnockWME knockerID :: guest) }
subgoal WalkTo(guest);
subgoal FacialExpression(expression_smile);
subgoal Speak(“Hi, how are you?”);
}
(Note that some of the above behaviors are parallel, meaning each step in the behavior is accomplished in parallel simutaneously, and other behaviors are sequential, meaning do each step one at a time, in order.)
A writer would much rather just write that simple one-liner declarative statement, rather than write all this behavior code, right? Well, the problem is that this code (which is relatively compact, btw, for what it’s accomplishing) is doing more than what that one declarative line has (under)specified; for example, if the NPC is far from the door, the NPC will yell for the guest to enter, instead of actually going to the door. To specify that declaratively would start making the declaration messier.
But more interestingly, what if we wanted a variety of ways to open the door and greet the guest, depending on who the guest is, how the NPC feels at the time, etc, etc? A fully-flushed out set of behaviors would have this kind of range. (I didn’t include that in the code here, to save space.) And we haven’t even gotten into how the NPC would handle the multitude of things the guest might do, such as be obnoxious, or flattering, or running away, etc., which is where things get really interesting.
Now, one could imagine an AI system with a huge library of default common-sense behavior built into it, including all varieties of typical behavior for answering a door; in such a system, a writer would merely declare a few new, custom things she wants for a new, particular version of answering the door. That’s theoretically possible, but not easy to build, and not easy to give the writer straightforward hooks to really customize the behaviors. In the end, you’d have your various NPC’s of supposedly different personality acting too much the same, I think.
(btw, I can’t remember, is this the first time we’ve seen code in a GTxA discussion?)
December 10th, 2004 at 11:36 am
As a follow up — in the past I’ve thought about how declaring / describing behavior is needed when initially writing down a design or specification for behaviors — i.e., writing a “spec”. There’s interesting overlap between that post and this one.
December 10th, 2004 at 1:04 pm
Hmm, you decide.
December 10th, 2004 at 1:55 pm
To skip back to Diane’s original reply to Andrew for a moment – I just wanted to mention that different authors write differently. Andrew, your concept that writers “are creators of character behavior; they invent motivations for characters, and from that create what their characters do and say” sketches out a sort of “method writing” where the author imagines “what’s my motivation?” for each character at each point, and where the engineer can model that motivation, or the soruce of it, in a program. Diane suggests that you may “misunderstand writing;” I wouldn’t go so far as to say that, but this sort of microworld / method writing idea really does have little to do with the linguistic turn that characterizes much of today’s literary writing.
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.
December 10th, 2004 at 5:29 pm
Mike, Anonymous — all the ideas you suggested about modeling praise sound good. There’s no one way to model these things; part of what we’re calling “writing behaviors” is exactly to keep track of and react to all the kinds of things you’re talking about, to the depth needed for your particular story you’re building. For one particular drama, perhaps only a simple level of modeling and monitoring for praise is required; for other dramas, more might be required. Building behaviors involves putting what you need into the system for your particular drama.
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.!)
December 10th, 2004 at 8:14 pm
Thank you Andrew that was an excellent example. I now see that there are 3 stages, declarative, the programmer/author’s translation of declarative into procedural whatever that is called, and procedural / event based(with substages of parallel and sequential).
I still have a sneaking suspicion that ‘declarative’ means several things to several people (the grand style of writing and narrative choreography) but I will leave it at that for now ;)
December 10th, 2004 at 8:28 pm
Andew wrote – The concept of “head games” and discourse acts is one of the two main points of this post — not a minor point! :-)
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.
December 11th, 2004 at 4:27 am
Mike Rozak wrote:
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.
December 11th, 2004 at 4:48 am
The only difference between andrew’s approach and mine seems to be that he believes in drama managers, and I believe in self-managing drama.
December 12th, 2004 at 12:26 pm
“while hanging out in my apartment, if someone knocks on the door, act surprised, open the door and greet them with “Hi, how are you?”
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. :)
December 13th, 2004 at 6:01 am
There’s still quite a way to go until someone will be able to fullfil your wish for such an engine, Steve. Currently, we’re still debating the basics of it all.
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:
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.
December 13th, 2004 at 7:21 am
Just to make sure that people can make the connection between the above and the topic of this thread, “writing, gameplay, and their interrelation”: to me, writing is gameplay – when I write, I play word games. This is true whether I write a movie script, a computer program, or a post like this one here.
December 13th, 2004 at 7:39 am
Also, when I say that andrew and I share the same approach, I refer to the “procedural” approach to writing, as illustrated by andrew here, not to the “managed vs. self-managing” approach to text generation.
December 13th, 2004 at 10:20 am
“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. ”
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.
December 13th, 2004 at 12:08 pm
Sounds amazing, Steve. How is natural language understanding handled?
December 13th, 2004 at 12:35 pm
Steve wrote,
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”, etc.
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.
December 13th, 2004 at 3:06 pm
Dirk: “Sounds amazing, Steve. How is natural language understanding handled? ”
Not sure what you mean.
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. :)
December 13th, 2004 at 4:00 pm
Hi Steve, thanks for contributing — as you’re an experienced writer in contemporary game production, who writes at length about the writing process on your blog and at your randomville.com column, I’m really interested to hear your feedback on this discussion.
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.
December 14th, 2004 at 5:33 am
I’m glad to contribute, Andrew, I’m just a little wary that you may be looking for engineering solutions and I’m either unsuitable to contribute or taking the discussion the wrong way.
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…)
December 14th, 2004 at 7:08 am
If I read Steve’s comment the right way (i.e. what follows is a subjective interpretation), as a writer, he wants his tools to enable him to treat his characters as autonomous. He wants to be able to directly create unique scenes in which characters can interact, instead of having to assemble them from atomic behaviors, using an abstraction mechanism that he did not come up with himself. This is the way many storytellers that I know do work. Personally, also I find it difficult to imagine communicating with my audience through a Drama Manager module instead of directly.
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.
December 14th, 2004 at 7:29 am
Dirk: “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.”
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.
December 14th, 2004 at 7:57 am
We might have a poll.
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?
December 14th, 2004 at 10:06 am
Steve, you mentioned a scripting language that was used for Revolution? How is it called? Is there any information available about it?
December 14th, 2004 at 11:07 am
C)”It will become necessary for engineers to talk to writers and create the tools they need to get the job done.”
:D
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.
December 14th, 2004 at 12:09 pm
By the way, how do I get to play Facade?
December 15th, 2004 at 3:04 pm
Steve wrote,
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.
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!
December 15th, 2004 at 4:39 pm
Andrew: “True, this is an expensive, time-consuming way to author, but it gives you the best results.”
I’m not clear on why that would follow.
December 18th, 2004 at 11:35 am
By “best results”, I mean that when the writing is built into clusters of reactive behaviors tailored for a particular situation in a game / interactive story, then the player will have a more reactive, robust, higher-agency play experience — versus if the writing has been implemented using, or shoehorned into, a more generic, or less procedural, or less expressive framework, such as dialog trees, or a matrix of responses, or even finite state machines.
In our work Michael and I been referring to the organizing framework of clusters of reactive behaviors as “beats”.
February 4th, 2005 at 3:02 pm
Johnny Pi describes how we wants to be able to program in plain English. In a comment I pointed him to this discussion.
February 15th, 2005 at 4:46 pm
Mike Leigh, one of my favorite filmmakers, makes his films in a way akin to what I’m talking about. This NYTimes article describes how Leigh gets his actors to develop their characters over several months, without knowing what the actual story events will be. Then, in rehearsal, he doles out a loose plot; characters are truly surprised when big plot points occur, since they didn’t really know they were going to happen until they do. The final dialog isn’t determined until they actually shoot.
June 14th, 2005 at 4:10 pm
[…] Meets Narratology in Game Design Space. In this paper, preluded as part of last December’s Head Games discussion, we talk at length about our take on resolving the tension between g […]
October 18th, 2007 at 9:49 pm
[…] impossible to pre-write it all. The system is going to need the narrative intelligence to write its own dialog — an ability endowed by the rules and knowledge that will be supplied […]