Mailbag: Development Process for Storylet-based Interactive Fiction

I’ve been a fan of your site and writing since 2009. Two of your older articles have been nagging at me recently — the one about writing prose for IF, and the other about your drafting process (with examples from Metamorphoses and Bronze, respectively).

I have been wondering how they would look updated for writing prose/process for storylet-based designs. I’m having a bit of a difficulty transitioning from the static fiction mindset, with all its attendant shortcomings in the IF context (text not bite-sized enough, difficult to decide on salient information , too much linearity, etc.)

If you had to address these two articles’ topics today, how would it be different? 

This is asking for an update to two articles, and so I’m also going to split out the response.

This piece will focus on the process side rather than the prose question. If you’re writing a game using storylets, how do you plan it, and how do you stay on track through executing it?

I’m also going to put a health warning on this. When I wrote articles in 2009, I was writing for a community of hobbyists creating freeware text-based games. I now write for a broader audience, on the basis of a lot more experience in the game industry.

So to be clear: the process description that follows is intended for an individual or small studio.

Storylet structures are used by many commercial video games — even if they’re not calling the structure by that name. If you’re working on a studio project with a significant team behind it, then that team will most likely have its own tools, design strategies, production schedule, and possibly pipelines for animation and VO. All those things place constraints on how this process can work, and the answers tend to be highly bespoke to studio needs. (I consult! But it’s well outside what can be covered in a mailbag post.)

Finally, what follows is a general discussion based on a range of different work: Failbetter are my current employers, and the work I’ve done for them certainly influences my process here, but what follows is not a description of their approach per se.

Identify Goals

These might be all sorts of things, including but not limited to

  • narrative design goals: “give the player agency over the protagonist’s career”
  • atmospheric, setting, or genre goals: “capture the mood of 1990s Seattle”
  • pacing goals: “make sure the player always has something to do”
  • platform or technology goals: “provide an experience that feels good in VR”
  • commercial goals: “provide a structure that can be extended in future downloads” or “provide good reasons for the player to spend on in-game content”. (Be careful with that last one: it’s ruined many a good game design.)

I rarely start design work on any kind of project without writing the goals at the top of the page for reference. (Sometimes this gets into a formal discussion of Design Pillars, if you work at that kind of studio. Sometimes it’s just personal guidance for oneself.)

Create high-level outline of the story arc(s).

This can vary a lot, because sometimes I’m creating something that’s meant to be a single storyline, with at most a little capacity for side quests or interactions with other stories (such as BEE, or one of the Exceptional Stories for Fallen London).

At other times, I’m building more of a story world with different elements taking place at different scales. In that case, I might start by outlining a couple of example stories that I want this universe to be able to produce.

To outline a story in this context, I

  • give a name to the progress quality (or qualities) I’m using
  • figure in the key story moments I definitely want to see in the story
  • come up with some secondary or subordinate beats that might happen in some playthroughs

Identify recurring patterns and design structures that support them.

Does the player travel through a landscape of randomized vignettes? Live through a number of years with a repeating pattern of festivals and events? Hang around having a conversation until they’ve asked about every topic that interests them, then move on? Explore a fascinating new territory?

These patterns are about gameplay as well as fiction. Do I want the player to gather resources via one activity and spend them to unlock advancements somewhere else? Repeat actions, failing over and over, until they start to succeed? Craft items by combination? Push their luck and take risks? Gradually establish a positive relationship with a particular character as opposed to others? Struggle over a difficult choice, having the opportunity to change their mind many times before committing to a final decision?

Often when I’ve found these patterns in my stor(ies), I’ve already got some experience with a structure that will accomplish what I want.

If not, or if I want to test the feel of a variant, then I might prototype and iterate on that section of play.

Sometimes I do that electronically.

Sometimes, if I’m really not sure yet exactly what I want to get out of the pattern I’m getting, or if I want the design to be especially fiction-led, I’ll do it as a paper prototype, writing storylets down on note-cards and putting stat ranges on them, then playing through a few cycles with those storylets, then editing my stats again, and so on.

Somewhere around here I might also do some pacing diagrams, and/or a spreadsheet list of all the storylets I need to build and the qualities that they will have. Sometimes both. The pacing diagram helps me think as a designer; the spreadsheet list is often important if I’m coordinating the project with a team.

Refine the system of qualities (especially if building something large, ongoing, or designed for multiple contributors)

That is to say: make sure the qualities I’ve defined are fungible enough to carry meaning between many different stories or segments of story.

If there’s actually an economy of qualities — as there is in Fallen London, where players can get qualities that represent inventory in one area and sell them in another — consider the balance of that economy, how much time is invested in achieving particular qualities, etc.

This is the area where storylet design is, I think, genuinely most different from many of the other kinds of narrative design discussed on this blog.

A great virtue of the storylet structure is its openness and modularity, its capacity to include new material written after the fact or even interlock meaningfully with other stories written by other people.

But this does ask that the designer do all the “what stats go with my themes?” thinking you’d expect when building, say, a Choice of Games piece (quoting from their guidelines for “creative stats, consistently applied”):

  • Are the skills balanced, with no single skill being much more useful than the others?
  • Do the stats communicate something about the game’s theme?
  • Do the stats track story effects in useful and interesting ways?
  • Are there meaningful secondary stats which track against the player’s goals?

…plus some of the narrative abstraction thinking you need for a story-rich tabletop RPG.

A quality like “Personal Growth” or “Dramatic Tension” or “Ennui” is way more transferable between different stories — but way less evocative — than a quality like “Number of Times You Fed the Chameleon.”

The trick here is coming up with qualities that feel resonant and expressive, that let you reward the player for one thing and unlock something different-yet-related in a totally other storyline. This can be hard! I love it.

If the player never sees the qualities themselves — if they’re entirely hidden — you can do a bit less of this work. But it’s still non-zero: you are still looking to identify the core concerns of all the stories you’re planning to tell in this world, and how gains and losses in one aspect might transfer to elsewhere.

This Project Horseshoe paper on Everlasting Narrative talks a little about developing interesting symbolic vocabulary.

Implement what remains of the through-line

First the qualities, starting with the progress qualities; then the storylets themselves that get the player all the way through the main story; then any additional elements. This might be a more or less elaborate piece of construction, depending on whether I need to create whole new structure, or am using existing structures with new content, or am instead making something fairly linear.

Iterate, complicate, add easter eggs

Things I expect to do during iteration and expansion:

  • Make sure that there’s enough guidance for the player about how to proceed
  • Add extra story branches
  • Refine the pacing
  • Revise prose
  • Add easter eggs that play off things in other related stories

Typically, though, there’s a lot less to do at this stage than there was when finishing a parser IF game for which a spine had been finished.


I intentionally put this at the end rather than the beginning because I wanted to talk about the design thinking rather than start with a bunch of programs. However, if you want to play with these design concepts yourself and you don’t have the benefit of your own tools engineer who can put something together for you, there are a couple of freeware tooling options.

  • Josh Grams has built an elaboration of Twine that offers a number of storylet features . This is still under some development, as I understand it, but has advanced to where parts of it are usable and documented with tutorials. I have not used it, but I suspect it may be the most accessible solution for people without any code experience or who find Unity daunting.
  • ink is the tool of choice for a lot of mobile and non-mobile text-rich games, and it plugs nicely into Unity. There are assorted ways to make a gameplay front end trigger storylets that are then defined in ink.
  • Alternately, you could do something similar to the ink/Unity pairing I just described, but with Yarn/Unity.

Either of the latter two solutions will likely require you to think about some additional management of qualities in the Unity/C# layer, because you’ll be rolling your own interface.

I do not currently know of a really full-functioning storylet system that is free, beginner-friendly, and at the same time robust and proven enough to sustain a full-size commercial game.


3 thoughts on “Mailbag: Development Process for Storylet-based Interactive Fiction”

  1. Thanks!
    (I think you meant to add to this sentence: “This is still under some development, as I understand it, but has advanced to where parts of it are usable and where others.”)

  2. Could you please specify that Grams’ TinyQBN only works with the SugarCube story format in Twine 2? I’d hate for people to be confused if they were using the Harlowe, Snowman, or Chapbook story formats, for which TinyQBN is not compatible.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: