Friday, January 25, 2013

More talk, more rock: on algorithmic game narratives, speculative narrative design futures, and "Shakespeare."

by Nexus

Last time, I wrote about procedural narrative in the context of "process intensity." Here, I expand more on designing the procedural / process part.

Back in an expertly-conducted 2011 Rock Paper Shotgun interview, Dan Pinchbeck argued that game development culture unnecessarily separates narrative from the rest of a video game:

"I just want story to be talked about as a gameplay element that sometimes isn’t there. It’s part of the set of tools that a game designer uses to create an experience – and it should be thought of along the same lines, as physics or AI or something more mechanical."

We have physics engines or texture libraries, so why don't we think of narrative as a modular "asset" or "engine" or "library" to be swapped around as well? Why can't narrative be more "mechanical." Where's all the narrative middleware? (Storybricks doesn't seem to be doing too well, unfortunately. I also don't agree with them, that proc narrative is mainly an AI problem...)

Part of the stigma is that AAA already commodifies narrative, and at its worst, it does it really poorly: I imagine a team of stubbled grad students, handcuffed to their desks in a flooded basement in Brooklyn, diligently typing generic dialogue into the "Soldier_Idle_Bark" spreadsheet for their free-to-play Chinese MMO overlords.

Meanwhile, the sworn enemy of that thinking is just as much of an establishment, this kind of indie design mysticism. Here, narrative is some sort of conveniently inscrutable "magic", a sacred unspeakable communion between player and developer that practically defies analysis because games are just so damn magical, man. (A counter-argument: these games do not tell stories -- the "magical game stories" come from already-talented storyteller-players who see through all the noise, i.e. Tim Denee's seminal Bronzemurder and Oilfurnace, or Zac Gorman's Magical Game Time. Good player-tellers pull out good stuff, and a bad player-teller will tell themselves a bad story.)

But despite my opinions, the truth is that everyone's right and that game narrative is all of those things: it's organic magic, it's a manufactured product; it's the soul of a game, it's trivial and unnecessary; it's profound, it's stupid fun. It's words you write, it's sound, it's scripted, it's environmental, it's unspoken interaction, it's a feeling, whatever. (Telltale's Walking Dead games did do a clever novel thing though: (SPOILER) your choices don't really affect the plot, but the game misleads you about the extent of the narrative simulation so that you'll attach imagined context / complexity to the NPCs' actions -- it's like fake gamification / fake gameplay. I liked it. Clever.)

The more important task here is to attempt some "vision" -- to map out which dimensions of game narrative aren't represented yet, and give those dimensions some space. A year and a half ago, it seemed one of those dimensions was procedurality, and to me, it still is: there is still no strong implementation of procedural narrative in a non-IF video game, none strong enough to inspire a whole new workflow in game dev culture as everyone rushes to copy their way of doing things.

Predictably, the interactive fiction community is furthest along in this type of thinking.


Nick Montfort's interactive fiction system "Curveship" separates story from narration. It makes a distinction between "fiction" files (the game, world, characters) and "spin" files (how the game, world, and characters are represented and narrated). This system design kind of resembles literary theory's divide of fabula vs. sujet, the difference between plot ("the raw material of narrative") and a story (the way plot unfolds), so that you can teach your computer how to narrate the world in a misleading or nonlinear way, or maybe switch narrators, or maybe even download someone else's narrator. Very interesting research.

Try playing Jim Munroe / Matt Hammill's short IF "Guilded Youth," and then look at its Inform 7 source code. The code syntax is based on plain English, sure, but the words don't really work the same (which, to me, means that Inform 7 is actually harder to use than more code-like code) because they had to invent new ways of thinking about storytelling and organizing interaction:

Login is a scene. Login begins when play begins. Login ends when player is not worried. Online is a scene. Online begins when player is in adventurers' lounge and map is in adventurers' lounge. [...] Logout ends when player is real.

There are parts in the code where Munroe has written paragraph-long passages that appear, verbatim, in the game. That workflow resembles traditional games writing: same text goes in, same text comes out, though few video games would directly code narrative like that without scripting in some other format. However, much of Guilded Youth's text (as with most other interactive fiction, really) is also algorithmically generated -- not just because the system understands the grammar of language, but because this system also understands a certain grammar of stories / worlds / behaviors.

Because code isn't just instructions to a computer. There's a theory and art to it; code is a way of thinking.

(Edit: Aaron Reed's Almost Goodbye is a compelling experiment in procedural sentence generation. Read his paper after you play it, too.)

So, the difficulty in writing interactive fiction isn't just a code syntax barrier. It is also about understanding this very different idea of what the writing involves, and what storytelling means. Curveship has a "world" with "concepts" that allow "actors" to "focalize." Undum has "situations" that afford certain "actions" to change certain "qualities." And Inform has this really complicated-looking scary flowchart just to explain what the basic backend does, barely even touching on how to engineer complex stories and worlds. Note that very little of this design is arbitrary, because simulations can also backfire horribly if over-designed (see Storytron)... What scares me more is that the IF gods deemed this magnitude of conceptual complexity to be necessary in order to write decent systemic stories. Is it possible to engineer a simpler, but still somewhat flexible, narrative system?


Valve's Elan Ruskin spoke at GDC 2012 about Left 4 Dead 2's procedural conversation system. Several months ago, I wrote about how I liked his implementation and its possible applications for procedural narrative, and I still like his approach a lot. He simplifies a lot of the workflow by writing narrative as a "pile of state" rather than drawing out all these networks. However, I now realize that it's more than just his implementation -- Ruskin also had several high-level / conceptual insights into narrative systems for games:

1) A narrative system doesn't have to author entire narratives. Instead, it can do just one or a few things well, and serve to off-load some work from writers. Mostly, the system should get out of the way and let writers write. (This is something that interactive fiction has taken to heart.)

2) A narrative system needs concepts, a way for actors to verbalize about those concepts, and a way for actors to remember concepts. (I would expand on this with a fourth detail, to complete the cycle: actors also need a way to synthesize new concepts, dynamically, in-game.)

3) A writer can think of narrative one way; the computer can think of narrative in a different way. (This, to me, is what's difficult about writing with current parser-based interactive fiction systems and even Ruskin's simpler system: too much data and complexity gets exposed, it's a very wide workflow scope. For Left 4 Dead, the writers were former database administrators so they loved writing with thousands of database entries and piles of state tracking -- still too complex of an implementation, to me.)

With that in mind, here's the working spec of the current narrative system I'm working on, currently codenamed "Shakespeare." Systems-wise, it is a hybrid between Ruskin's conversation system, traditional game engine entity frameworks, and various interactive fiction designs. It's still heavily under development, of course.


Shakespeare

To Shakespeare, stories are made of concepts and actors.

Actors are usually humanoid NPCs, but not always human and not always NPCs.

Concepts are ideas about anything. They tell actors to move around the world and hold / transport other concepts for them. Actors are basically a taxi service for concepts, they're not simulated people. (Remember: the main job of NPC AI in games is to walk around and play animations / sounds.)

(Detail #1: actors should stay near or around the player, and do things near the player. You'll want to keep simulated narrative closer to the player, otherwise it seems like NPCs teleport around / share knowledge "unfairly." I blame players' solipsistic refusal to accept object permanence.)

There are three types of concepts: World, Talk, and Plot.
  • A WorldConcept is like a room or a thing in the room, e.g. "DiningRoom" or "Table" or "Human."
  • A TalkConcept is like an idea an actor says aloud and possible ways to say it, e.g. the "Greeting" concept could be expressed with "Hello" or "Hi" or "Hey."
  • A PlotConcept is an event that happens at a WorldConcept, casts appropriate Actors in roles, and makes stuff happen, e.g. the "DinnerPartyIntro" concept would pull actors into the "DiningRoom" and make them speak "Greeting" to each other.
More specific concepts can inherit qualities of vaguer, more general concepts.
  • "Room" >> "LargeRoom", "PublicRoom" >> "DiningRoom"
  • "HeavyThing", "Furniture" >> "Surface", "Container" >> "Table" >> "FancyTable"
  • "TalkGreeting" >> "TalkGreetingRich", "TalkGreetingSmart" >> "TalkGreetingProfessor"
  • "Gather" >> "PartyIntro" >> "DinnerPartyIntro"
Shakespeare prioritizes more specific concepts, but can always fallback to vaguer concepts for whatever reason.
  • There are 5 actors in DiningRoom, so the room calls the DinnerPartyIntro concept, which looks for a nearby actor who knows the TalkGreetingProfessor concept. Eddie knows it. However, all the TalkGreetingProfessor dialogue lines are on cooldown because other people spoke them recently, so instead he falls back to speaking TalkGreetingSmart instead, which still fits the situation.
  • DinnerPartyIntro calls DessertParty, but there is no DessertRoom in the house, so it falls back to PartyGeneric, which looks for a room that inherits LargeRoom and PublicRoom -- it picks LivingRoom, since that's more specific than either of its ancestors.
(Detail #2: some voice over lines in Left 4 Dead 2 play once every few months, or something, so that the game can still surprise you, even after a dozen hours of play. It might be useful for concepts to have a "rarity" heuristic built into them, in addition to "specificity." Diversity of output implies a robust system.)

Actors have memory, remember concepts, and can share concepts. Only actors with (or maybe without) certain concepts will get picked by certain PlotConcepts.
  • Eddie has been in DiningRoom, so he remembers where DiningRoom is. Someone can ask him where any DiningRoom is, or if he's been to a specific DiningRoom.
  • The professor heard Eddie say TalkGreetingProfessor, so the professor will remember Eddie, and that Eddie said that in the DiningRoom. If someone asks the professor about Eddie, she might tell them about her memory of Eddie if there's nothing more specific available.
  • The UnknownConnection PlotConcept might look for an actor like Cooper, who doesn't have the specific DinnerPartyIntro memory but knows Eddie and knows the professor. UnknownConnection will bring Cooper into the room and have him say TalkIntroduce about Eddie; the Professor will verbalize the DinnerParty memory; Cooper will say TalkSurprised or maybe TalkSurprisedAngry. TalkSurprisedAngry might trigger a PettyArgument concept, etc.
Anyway. This can obviously get really complex -- but if it does, it might be because the writer wrote too much and wasn't using their concepts efficiently and simply. You can be as complicated or as simple as you want.

There are also some secondary ideas that I want to stress:
  • De-emphasize the myth of psychological realism as narrative simulation / the basis of action. Actors in Shakespeare do not have emotions or moods (unless you give them some, I guess) because fictional characters are not actually people. Instead, concepts guide characters.
  • The "conceptual reality," however, is still intensely psychological and epistemologicalIf no one remembers it happened, then maybe it never happened. I'm still very interested in how to reflect memory / reality in games.
  • Argue that narrative isn't really an AI problem, it's more a workflow / transparency problem. We need a system that makes it easier for writers to design narrative, yet with some of its working and causality painfully and automatically explained to the player.
  • Again, let writers write.
  • Instead of the player walking through a static branching structure, the game will dynamically build / mutate a network structure around the player. You simply author the nodes; the game will link them all automatically, and mutate new nodes based off of yours. This is the "self-branching" aspect that Ruskin talks about.
  • The structure is less like a tree, more like a network. A densely connected network is more resilient than a tree, with redundancy and fallbacks built into its structure.
  • Once you build a generic concept library (stuff like "Room" or "TalkHello") you can re-use that library in other projects and have some narrative simulation running in any other game within minutes. Maybe you could download a "romance" library off Github, and fork it to add lesbian romance as a feature? Maybe there'll be a CGTextures or Turbosquid of narrative?
  • Simple writing interface, compartmentalize data so you don't end up staring at a spreadsheet or web of nodes, encourage simple concept structures. You shouldn't have to stare at a complex network editor in order to generate a complex network, though maybe some sort of graph visualization would be good for debugging your plots. 
  • Most of all, I'm going to try to keep the framework ostensibly simple: three main data types, simple editor that gets the job done.
I have my system about half-implemented in Unity right now. We'll see how it goes. Maybe I'm wrong about everything...