Robot Soul

Dirk, glad to see you've started your own blog; I'm happy to be the first commentor. :-) (Although I had to use the lycos translator to figure out how to register in German.)

Actually my central concern isn't really the conundrum I wrote about in that post from October 2003. For the kinds of interactive drama we're interesting in making, Michael and I have resolved that question to a reasonable degree of satisfaction. We describe our particular solution in our upcoming AIIDE paper; it's probably similar to your thinking on the issue.

Rather, my primary concern with all of this is about inventing implementation methods towards achieving high-agency interactive drama. How to architect a system capable of it, how to represent narrative knowledge, how to understand natural language to allow for maximum expression for players, ways to be as generative as possible, ways to more easily author it all.

Those were the motivations for the questions I posed on the panel -- but didn't get substantial answers for from the industry panelists.

Are these not are the same problems you perceive? If not, what do you consider to be the obstacles, in terms of design, technology and production?

While I agree with Conflict = Story, I don't think Interaction = Conflict is always true. That is, I don't think players will always generative interesting conflict; without some help from dramatists (e.g. a drama manager), naive players may only generate banal, uninteresting conflicts, such as griefing or attempts to break the AI.

Hello Andrew; thanks for dropping in (and for pointing out the language problem; I hadn't thought of that, and must now). Yes, when I read your presentation, it struck me as on slide #3 you explicitly tried to exclude the conundrum from your discussion: "Try to abandon those terms ['story' and 'game'] for this panel". I think I understand the intention behind this - if it was something in the vein of "let's stop discussing the definition of terms and instead let's discuss and learn from what existing code actually does already". And it's a valid move, no doubt - trying to get people out of an argumentative and into more of a conversational mode.

Inventing implementation methods, evaluating system architectures, representing narrative knowledge, understanding natural language - sounds like my terrain :-).

Are these not are the same problems you perceive?

Most definitely they are.

If not, what do you consider to be the obstacles, in terms of design, technology and production?

See, now, as a HumanActor, I'll do something without much effort that I had great difficulties in getting a VirtualActor to do in any sensible way (I can implement that now, but it's still expensive): returning "true" on the condition, but still following the "if not" branch, because the context calls for it. Yes, I do percieve the same problems you do, but all the while, I think there are different obstacles for you and for me to surmount. This, I believe, is due to our different initial positions from which we approached, and are still approaching, those problems you listed. I still need to find answers to questions that are trivial to you, because those answers are just fundamental knowledge in your line of work, and the same seems to be the case vice versa. And the only way I can explain what I mean here is if I'm allowed to use those dreaded words; "game", and "story".

How did you do without them, anyway? I imagine that, somewhere in the implementation of each of the systems that were discussed at the event - the design documents, the variable naming, or at least in the minds of the designers at design time - the terms "story" and "game" must have played influential roles, and I speculate that those terms might have occupied different roles in the design of all of them. I would find it hard to compare the outputs of different systems of the type we discuss here (dig how I'm smoothly avoiding having to say those words for a moment?) without discussing those differences. I'm sure that different usage of those terms leads to different system architectures leads to different outputs to the same (player/client) inputs. But maybe this is an example for the very problem I'm trying to adress here: an obstacle for me, but not an obstacle for you.


get name: grain-of-salt
set name: obstacles-scheuring
number="1"
value="must say 'story' and 'game'"


In order to visually indicate when I use my particular definition of a term like "game", "story", "actor", "whatever" in my writing in this blog, I format them as Metaphors, like Story, Game, Actor, Whatever. I think we must introduce some form of "namespacing" for those commonly used "terminating variables" (or "variable terminators"?) everybody assigns different values to; maybe we could agree on marking them as Metaphors, so anybody who writes Game in my blog refers to my definition, and anybody who writes Game in your blog refers to your definition (and you get to agree on a definition of Game with the other GTxA drivers ;-). I see this as an obstacle for both of us, and think that we need to get it out of the way.

Anyway: if I say Game in this blog, then

Game = Turing's Imitation Game

No other game, or "game", is Game. Everything else is defined in reference to Game, enabled by its very existence. It makes my first equation possible:

Game = Interaction = Conflict = Story

From there, it is easy to see that I will not get into that darn conundrum which so many people say affects their decisions on the level of their system architectures: I look at the Imitation Game from four different perspectives; switching perspectives, I can view it as Game, as Interaction, as Conflict, as Story, at any time. Since Game and Story are fundamentally equal - just two different views on the Imitation Game (which, at least in theory, can be taken "simultaneously" by one subject) -, there's no conundrum possible here. That doesn't preclude any lower-level objects from fighting over ressources, of course, but it does provide facilities for top-down iterative adjustment and extension, which is nice. And modularity, which is also nice.

As for the obstacles that I might encounter following this basic strategy: this blog is meant to grow into a list of them.

Dirk