What I find particulary clever is how he associates the story goal with the character played by the human, and thus reverses the drama dynamics of Turing’s original “Imitation Game”: Instead of the computer having to convince the human (that a third party is lying), the human has to convince the computer (that the relationship is over). This makes it much easier for the computer to motivate its own (possibly repetitive) behavior and answer “why”-questions: “Because I still love you, that’s why!” The one weak spot in this concept is probably encountered by players exhibiting the “harassment behavior” often found among chatbot clients – unless the computer character is crafted to act in extraordinary masochistic ways, it might be difficult to use a “But still I do love you!” strategy and achieve suspension of disbelief beyond the third major insult.

Anyway, I think that this work definitely moves forward, and demonstrates some of the opportunities of a “story-based” (or “coherent temporal structure-based”) approach to human-computer dialogue. Handing the conversational goal to the human – and thereby making the computer into the Change Character of the story – is (from the POV of the dramatist) not a universally applicable strategy, but it definitely has it’s uses, especially, I think, in a larger (game) context, and in using it, Rob is cutting some corners in an elegant way. I’d gained a lot by reading his earlier publications – which I’ve also recommended when the subject of NPCs came up on the Alicebot list a while ago -, but this time, he’s more inspiring than ever.

But a game that could actually involve the player with the characters ends up being quite different from games-as-we-know-them-right-now. And it results in a player experience that’s vastly different from what most game players expect – the actions are less clear, world state space is deeper and murkier, and the players ideally need to really put themselves in the frame of mind of a genuine participant in order to really understand what’s going on. I hope this won’t pose too much of a challenge in presenting these kinds of works to traditional gaming audiences…

By the way, Andrew – I love your final sentence. Can I steal it? ;)

To me, it simply is part of the dramatic conflict: There’s one character who won’t play along, and another character who has to make him change his mind. I think that writers of interactive drama have to learn to ask the same questions that ‘traditional’ dramatic writers ask themselves: Whose story is it? What are the goals – those of the characters as individuals, the goal of their conflict, and the overall goal of the story? Who is the character that has to change in order for the overall story goal to be reached? This allows for some conclusions that I believe are quite novel in the context of interaction design: it might turn out that it’s helpful for some scenarios to regard the character enacted by the computer as the main character of the story/interaction. And the (initial) goal of the character enacted by the human might be to just break the game. Then the goal of the conflict would be to get that character to change, in order for all the characters to be able to reach the overall story goal. And that’s what the design should be doing.

As an example, let’s twist your “Breakup” scenario one more time. Let’s assume the goal of the story/game is for the player to make an inheritance, and one condition to reach the goal is that she’s married to a certain computer character. Now the computer character declares the relationship to be over, and the human has to win it back… immediately you place the player in a position where insults won’t help at all. In sghort, the dramatics should be stacked in a way so that destructive behavior results in loss for the player – and not for arbitrary reasons, but as an integral, logical part of the story’s argument.

It has rightfully – I think – been argued that artists should be programmers. But that coin does have a flipside: While I was educating myself about computer programming during the last years, I often had the impression that some programmers trying to design interactive characters assume that they already know everything there is to know about the development of (fictional) characters, about dialogue writing, character motivation, conflict – in fact, they seem to think that many things that ‘traditional’ writers usually spend a lot of time and effort to get any good at somehow come natural to programmers. Well, this is not the case. Just as an artist who wants to get into interactive drama needs to learn basic stuff such as that one man’s constant is another man’s variable (and why this matters in terms of program design), programmers who want to get into it need to learn basic dramatist stuff, like the fact that the ‘protagonist’ of a story isn’t necessarily its ‘main character’ (and why this matters in terms of story design). If true collaboration between artists and programmers is a desirable goal, then I’m pretty much convinced that the learning should be mutual.