Mailbag: QBN System Variants

Hello Emily,

I was reading through your blog and, in your post dated May 25, 2017 you describe several narrative systems, and the last one you write about you name it “System with Dynamic Requirements”

I’ve been working for a couple years now (on my free time) on a system that is very similar to what you describe: A tool to create narrative very similar to the way QBN does but with dynamic requirements for actors and locations.

The main difference is that it is a system to run over a real time game and the choices are done by gameplay inputs instead of selecting or letting the game select.

The tool provides a visual-node interface to create attributes and rules. The player actions trigger events on the system (i.e. looting a body trigger and event and we can create a rule on the tool that say “when loot event is triggered add attribute looter to the player”) and the attributes are evaluated continuously by the rules and giving results (i.e. If player have looter attribute with a value higher than 5 add world attribute “looter missions activated”)

Of course, there are the dynamic requirements that I’m using as I think the player’s engagement will be higher if the characters used on the story are people they “choose” to met in the game instead of previously designed so I can check if at one point they helped someone to escape or to acquire some item or whatever and later check the list of actors and use that one to be part of the story, or I can check between the locations in the world and create a mission that use a location with a certain attributes instead of always the same location for the same mission.

My question is: Do you know about other projects working on the same line?

Sort of, depending on how precisely you define “the same line”.

I know of projects that make use of Node-RED to visually define rules for various purposes other than interactive narrative rules.

I know of IF games, including my own, that allow the player to unlock new gameplay and story sections with any item that matches some general requirement; and sometimes a puzzle will have multiple solutions, but the specific solution the player picks turns out to be important or expressive in some way, or is used to judge the protagonist’s character.

I know of experiments with dynamically-gated story elements — most (but not all) of these tools in the academic space rather than among hobbyist IF tools or (for that matter) commercial video game tools. You may be interested in Ian Horswill’s Dear Leader’s Happy Story Time, described here in an academic paper with references and mentions of other related academic projects, or here in a video talk. (The references here provide a lot of potential further searches, with context.)

I know of realtime games that serve up specific beats depending on what tags are currently matched about world state. See Elan Ruskin’s work for Left4Dead, covered in this excellent talk. This is salience-based matching for various world states, which then in turn influenced the design of the dialogue-fitting in Firewatch. Not the same as constraint solving, but relevant to some of your other points about wanting to unlock specific story beats if the player has the right background.

I do not know of an existing tool with all the features you describe: a visual interface to create the rules for a dynamic-conditions interactive narrative system, applied to a realtime experience. (That’s not to say no one’s building one. I just haven’t seen it.)

That said, I’d like to suggest that you’re opening not just a technical space but a challenging design space, and you’ll want to test your assumptions about the player experience. There are some finished, public examples of games that do play a little in this space. For instance, games in the Fable series assigned story importance to figures the player had spent time with. I would suggest, based on my experience with that, that your initial assumption (“the player’s engagement will be higher if the characters used on the story are people they “choose” to met in the game instead of previously designed”) may not be true in all cases.


Montage, Narrative Deckbuilding and Other Effects in StoryNexus

empressshadow_smallIn a previous post, I wrote about design considerations for quality-based narrative systems, and mentioned that there was probably room for a standalone article about frequently-used patterns here. (This article in many ways mirrors one I wrote years ago about scene types in parser IF.)

When I write for Fallen London, I find myself using and reusing a couple of standard structures.

Straight choices tied to a progression quality: the storylet is available as step 1 (or 4, or 10, or X) of the story; there are two or more things you can do within that storylet; when you’re done, the narrative advances to step X+1. Maybe some of the things you can do in the storylet depend on secondary qualities, but this is basically recapitulating a fairly tight branch-and-bottleneck CYOA structure.

Continue reading

Chris Crawford’s Encounter Editor

Yesterday, Chris Crawford put up a post with the following plea:

I’m asking everybody to consider an important post I have made at…. There’s 25 years of work hanging on this.

He also emailed me the same message directly. So I had a look.

The basic premise is as follows: Chris’ long-running Storytron system, designed to make interactive storyworlds, needs a lot more content in order to show off its hypothesized strengths. In particular, it needs content that feels handcrafted to some degree, to go with the procedural descriptions of characters gossiping, falling in love, and fighting. Or, as Chris puts it,

After many years of trying, I have learned the hard way that the procedurally intense interactions provided by the Storytron technology lack the color that most people expect from traditional storytelling. There’s a repetitive, mechanical feel to those interactions, and while they are dramatically more intense, more significant, they are like the skeleton of the story, the core elements, in need to fleshing out with muscle and skin. That’s the purpose of Encounters. They provide a more data-intense form of interaction that is shallower in dramatic significance, but more colorful.

To build this, he created an encounter editor. The Encounter Editor lets people design encounters that:

  • are locked or unlocked by certain prerequisites consisting of other encounters
  • start with a description of a meeting with another character
  • let the player make a choice in response
  • provide several possible reactions for NPCs, including some variable-based probability around which of those reactions they’re most likely to choose

In other words, the encounter bears a strong resemblance to storylets in StoryNexus. The editor looks like this:

Screen Shot 2017-06-21 at 8.15.50 AM.png

It’s a little more constrained than StoryNexus about how prerequisites work — they can only depend on what other encounters the player has run into, not on the whole range of variables in the world state.

Continue reading

Mailbag: High-Agency Narrative Systems

Today’s mailbag entry (at the request of the submitter, anonymized and edited a little) gets into the question of how to create salience and quality-based narratives and other similar games, given that typically one has to build one’s own.

What I keep getting drawn toward on a personal level is your work–and other people’s work too–on procedural narrative generation. I have enough knowledge of coding to understand states and modeling systems and when to move from one to another on a conceptual level, but at this point I could not make one in any language or engine. I think this is something I would like to learn to do more of...

Obviously I’ll need to learn a language from the ground up. That’s fine. I suppose I’m asking what would be most helpful to focus on–not just in terms of C# or Ruby or Python–but other skills as well… most of my questions/interests are about event generation, procedural chains of causality, etc.

Further discussion with the asker indicated they are talking about the kind of quality-based and salience-based narrative systems I wrote about in the article Beyond Branching; this RockPaperShotgun column about Alcyone also gets into some detail about the state of play in this space.

Systems like this can achieve a combination of player freedom and agency that is hard to reach in CYOA or any other node-based system (I would include ChoiceScript here): there are often dozens of viable choices available.

Meanwhile, because you’re not tied to a specific simulation concept (like the standard parser IF world model), you can adjust the qualities of your QBN to the particular needs of this work. Track your protagonist’s health, her interest in opera, her sense of humor, her tolerance for pain; track her relationships with each of a dozen friends, or a dozen aspects of her relationship with one friend.

On the other hand, the tooling and the design abstractions in this space are not nearly as advanced as they are for parser IF or CYOA/hypertext/stats-based IF, so if you want to work with it, you probably have to build your own.

That’s a topic that could take a number of articles, and there isn’t as much writing in this space to point to as in the parser space.

Continue reading

Mailbag: Writing for Versu

g_ending_2@craigtimpany writesYou’ve covered Versu’s architecture, but I’m curious what that was like to write for… In particular I’ve been wondering how very non linear tools affect a writer’s flow.

For those just joining, Craig is asking about Versu, a system focused on agent-driven narrative. Versu and the games made with it are no longer available, but there’s information available about the system, including several papers at the Versu website, and past posts of mine here about the conversation system and about what it was like to convert Galatea to the Versu format.

During the first portion of its development, Versu content was driven through Praxis, the language that specified social practices and truths about the world state. Praxis is very powerful and allows the user extremely detailed control over what is true about the world, and what all the agents want; and the baseline implementation of conversational practices, among others, were written in Praxis. However, writing extensive dialogue in Praxis was essentially wrapping conversational elements in code — a high-friction way to compose, and one that discouraged revision. To address that, we developed a DSL called Prompter. I am not going to re-describe here everything about how that worked, since the attached papers go into detail.

But the core point to know is that, within Prompter, one wrote scenes. Each scene could have some opening text; some parameters about what was allowed to happen in that scene (e.g., “no one dies in this scene, but Veronius is allowed to have sex”); a body of dialogue that can be spoken only in that scene and nowhere else; and then one or more ways that the scene can end.

Using that information, the system would follow its own rules about how conversation and social actions could chain into one another, improvising a particular performance around the scene parameters the writer had set on the page.

Continue reading

Voyageur: Impressions

This slideshow requires JavaScript.

First, a massive disclaimer: Voyageur’s author Bruno Dias is a friend. Also, I often do work for Failbetter, which provided support for Voyageur via Fundbetter. In addition, Voyageur uses procedural text generation features that draw on things I did for Annals of the Parrigues, and I had a number of conversations with Bruno about the game while it was in development. That said, I will try to be as useful as I can, since I’ve been asked for more of an assessment than the simple announcements I’ve been posting.

What is Voyageur? This is a systematic quality-based narrative with procedurally generated textual descriptions, trading, and perma-death — though in the right circumstances you can leave a substantial legacy to a future captain.

To unpack that a bit: you start out on a planet with a little money and a few supplies and something called a Descent Drive. A Descent Drive is alien technology that moves faster than anything made by humans — but only in one direction, towards the center of the galaxy. If you want to take a trip on one, you are never coming home.

So you set out, and each time you do, you have the ability to steer a little. You can typically pick which of 2-5 available planets you want to see next. You know one or two facts about them. Sometimes those facts are enough to tell you which planet is going to be the best place to sell off your current cargo or drop a passenger; sometimes you’re pretty much taking your chances. The descriptions of the planets, as well as the crew you pick up and the trade goods you acquire, are all procedurally generated. Planets have governments, cultures, climates. Trade goods have different levels of quality and other features that make them appealing on different worlds. I particularly enjoyed some of the trade good descriptions that hinted at the surrounding culture: Sea urchin substitute. Generic locust steaks. An artwork consisting of AR decorations overlaid on electronic components.

Continue reading