Mailbag: Writing for Versu

@craigtimpany writes: You’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.

The concept of scene structure and especially the rules about scene-beginning and scene-ending do owe something to Inform 7‘s implementation, which was itself inspired by the scene machinery I built for the game City of Secrets.

Initially, when I was first working on this for City of Secrets, I was trying to solve the challenge of modeling narrative units on top of or alongside a traditional parser world model. City of Secrets is a large open world with a lot of different map areas that need to behave differently at different points in the game, and the openness was part of the design brief given to me by the people who commissioned it.

In particular, City of Secrets does not primarily manage its narrative stages by opening new areas of the map, in contrast with Counterfeit Monkey. There are a few areas that you can reach only in the late game, but a lot of the city is open at once, and stays open through significant plot changes.

That meant that I needed to control when the player would be able to go into various buildings, which NPCs the player would meet in different locations, and so on. As I wanted to do that without having a huge mess of disorganized flags, I used the abstraction of the scene mechanic instead. I could then write code that said a particular shop was closed during a given scene, or that a scene should end in a particular way. I also used the scenes to handle drama management: if the player hadn’t made progress on some puzzle for a long time, I could start a mini-scene that would use an NPC to drop hints. But mostly, the scene concept was a way to structure and organize plot-based constraints on the simulation, in contrast with the spatial constraints that were already built into the world model.

For Versu, it does something similar. There’s less of a physical model in Versu than in Inform by default (though you could build rooms and an inventory structure if you wanted, and some of the Versu games do more with this). But there are lots of different social practices available at different times, and the scene structure helps to constrain and structure those.

Now here in a little more detail is an (edited for length) example scene from Blood & Laurels. We start by establishing what the scene is, the moods of the participating characters, and the thoughts you would see in their thought bubbles if you happened to tap on their heads.

 

*** Scene – Further instruction of Marcus ***

(Marcus thinks Artus is considering a coup. Conversation is restricted. Artus is worried. “This matter is very serious.” Marcus is worried. “If I do what is asked, I could be killed”)

“Marcus thinks Artus is considering a coup” establishes a piece of factual information that applies in this game universe: Versu doesn’t try to track every possible fact, but it does track important beliefs that are likely to change character behavior, unlock new dialogue, or be transmitted through dialogue.

This scene doesn’t do so, but you can also use the scene-setting section to put a prop or two in play, as in “Marcus carries a bag of gold.” Physical objects are much less important in Versu than in the typical parser game, and they’re mostly defined in terms of how they contribute to the social possibility space — for instance, enabling a social practice of bribing someone.

Next we establish some topics of conversation already in play: this determines what dialogue will be offered to the player to select first:

(The scene is about the emperor, the temple, and the plot.)

Next we supply the narration that starts the scene:

Narration: There is a long silence. If Marcus did not know him better, he would almost say that Artus was afraid to go on with the conversation.
>> Finally he heaves a heavy sigh and turns away from the fire.
>> [Artus] says, ‘You are to ask the dead whether I could possibly overthrow the Emperor and rule in his place.’

(About the plot and Gila.)

Artus: Watch the behaviour of your friend Gila. If the priestesses are upset by the response of the oracle, that fact is as important as the answer itself.

Quite a lot more dialogue follows here. Some is available any time a particular topic is in play; some is available only as part of an ongoing conversation thread. In that respect, Versu follows similar conversation threading practices to those used in the Inform library Threaded Conversation and Alabaster (and a lot of my other work).

Finally, we end with specifying conclusions for this scene:

(End on option “Wrap up this interview and go home to think about it” and go to Marcus chooses whether to attend. “After a little more discussion, Marcus tells Artus that he believes he knows what he needs to do. Artus slaps him on the back and sends him on his way.”)

(End if “To obey would be…” has been reached or Artus rates Marcus’s faithfulness as worse than bad and go to Artus reproaches Marcus.)

(End if 70 ticks have passed and there is a lull where Marcus is and go to Marcus chooses whether to attend. “After a little more discussion, Marcus tells Artus that he believes he knows what he needs to do. Artus slaps him on the back and sends him on his way.”)

You will note that some of these are in the player’s control (they can explicitly end the conversation and leave the room), while others are triggers (“end if 70 ticks have passed and there is a lull where Marcus is…” means “wait for a natural end to whatever conversational thread you’re currently on, and then exit the scene”). The author can combine any of these.

If you really want to, you can make a scene that only contains ending choices, essentially forcing a CYOA-style node just in that one location — handy if you want to create an emotional crisis point and then go back to the broader simulation.

In practice, I find this an extremely congenial way to write; perhaps that’s not surprising, as it’s combining systems of both conversation and narrative management that I developed over a long time through a number of different projects.

When I’m creating new content, the scene-containing-dialogue structure means that I can rough in a by-scenes outline that provides the high-level narrative branching structure (and Blood & Laurels is purely branching, though you could also use a salience-based way of choosing the next scene).

Then I think about key beats for that scene: what information does the player have to have before leaving this scene? what decisions must occur here? how can it end? where might it go next? Those beats can then be written as starter dialogue, and the conditions wrapped into the endings.

From there, the scene grows organically, often during iterative replays. What elements feel like natural riffs on the mandatory content? What might the player want to ask follow-up questions about? Where does banter go? I’d have a game that could be played through from start to finish pretty early on — another design practice I really like if I can possibly manage it — but could then flesh it out and replay many times until I liked the way it felt.

The resulting scenes allowed for a very substantial amount of difference in different playthroughs, as well: the player might wind up having a long dialogue with an NPC, going into lots of lore or interpersonal detail, or they might do a just-the-facts version of the same scene where they receive instructions and leave again. But because I’d set the parameters on what had to happen in that scene, I could be confident that it was achieving my essential aims.

The other neat Versu feature that came in here was the concept of memories. A memory was a piece of background narration triggered when conversation hit a particular conversation topic for the first time, which allowed exposition to be interleaved very fluidly into the dialogue. I could write a sentence or two explaining who a character was, and know that the first time that character came up in NPC dialogue, the player would get the necessary background information. Memories could be specific to different player characters as well, which is why the Versu Galatea allowed the interiority of Galatea to feature a bunch of new information that wasn’t exposed if you were playing as one of the other protagonists.

This is a very different way of thinking from the approaches that have to go into writing parser IF, or into the majority of choice-based IF.

For parser IF, you have to structure your story into moments of choice, conflict and revelation, and either tie those into the game map or base on other triggers connected with the rooms-and-objects world model. (The scene construct is just one of several ways to back-form that structure for IF.)

The mental work of converting a plot into a spatial representation is a challenge for a lot of authors, especially ones trained initially on narrative; I think parser IF appeals to a programming mindset not only because it typically requires some coding to implement but also because it require translation from user experience to component systematic behaviors. Writing a short story or novel also requires skill and planning about how to achieve various effects — something programmers and game designers don’t always respect — but it’s a bit more WYSIWYG. At one point I tried to outline how one might map conventional writing concerns to the parser IF space, but there’s a lot to understand there.

Meanwhile, for most choice-based and hypertext IF (ChoiceScript, ink, inklewriter, Twine), you’re explicitly writing each individual choice node and thinking about what the player can do at this exact moment. If you really work at it, you can do enough with variables to represent an environment and objects rather than a series of choice nodes.

That means you get fine control over the composition of individual choices — you can know, for instance, that you want to give the player four options and that you want the last one to be the kicker, the scary or funny option that 99% of players will be drawn to actually choose. But it doesn’t give you much abstract leverage over pacing, and if you want to make sure that the player has encountered a particular piece of information before the story moves on, you have to enforce that rule by hand, by verifying that there are no story paths that don’t pass through that point.

I’m not sure whether to describe Texture as a choice-based system in the same way, but there again, the fundamental unit you’re dealing with is a page, and each page contains certain possibilities that are active only there.

A quality-based narrative system such as StoryNexus is a bit different again, but I don’t think it’s necessarily a lot easier — it basically leaves the entire model problem in the lap of the author. Want some storylets to be available when the player is in a given location? Give the location a quality. Some storylets depend on emotional state? Have another quality. Number of narrative beats that have passed so far? Quality time. It’s very flexible, and in some ways it’s an extremely instructive playground for authors, but it can also be hard to learn, hard to visualize, and a real bear to revise. Fallen London has a wide, wide variety of mechanical structures in its various stories. Some of those issues might be alleviated by a different QBN system, and I think Varytale took a good cut at trying to improve on some of those problems, back in the day. Still, if what you want is manageable abstractions that give you a handle on narrative functionality, QBN is not the obvious solution.

At least for me — I realize this is an intensely subjective matter — Versu-with-Prompter did a great job of letting me express my design in terms of writerly structures (plot beats, important decisions, interiority, character moments, what does character X say when fact Y is revealed). Meanwhile it left to the system problems of transition: what are all the possible ways we might get from subject A to subject B? Where are all the places this conversation might wind down and proceed to something else?

Versu is no longer available, but I learned various lessons from it that have carried over into future projects. The project I’m doing now at Spirit AI is doing a number of other things as well, is not based on any of the Versu code or IP, and is a commercial-grade project rather than a hobbyist one. A scenes-and-dialogue model is one way of creating content in our Character Engine, however. If you happen to be interested in seeing that and hearing about the toolset, I will be discussing it at the London IF Meetup May 31.