Survey of Storylets-based Design

“Sketching a Map of the Storylets Design Space” is a paper by Max Kreminski prepared for ICIDS 2018, an academic survey of the storylet design space. I wanted to point my blog readers towards it, as it covers a lot of interesting territory in the quality-based narrative/salience-based narrative area (and in fact references my post on structures beyond branching narrative). Those of you interested in ways of structuring IF with more procedural complexity than a branching narrative may find it interesting.

The paper offers an overview of major storylet-based tools and works from both indie and academic experiments new and old, including StoryAssembler, StoryNexus, The King of Chicago, Reigns, and Ice-bound Compendium. It does not discuss Varytale, but then Varytale has been unavailable to play with for some years now, so there may not have been an accessible version for Kreminiski to look at since beginning their research.

Kreminski identifies four dimensions for looking at storylet-based systems: how preconditions for storylets are defined; whether individual storylets can ever be repeated; what sort of content is contained within a storylet (linear text? replacement grammars? branching content?); and finally, the “content selection architecture”, or how storylets are chosen as eligible for display.

Kreminski also built a storylet system and a small prototype game of their own, a piece called Starfreighter. (It’s available on itch, if you want to look at it yourself.) The scenario is a fairly standard space-trading story, in which you accumulate crew and cargo and travel through a procedurally generated graph of solar systems. There are several cool presentational aspects here, including the way that you can select place names in your storylet and get extra information and see the location highlighted on the map. The actual content is not very deeply developed — there’s enough here that you can travel from port to port, do some trading, and have your hull damaged repeatedly by space debris, but it doesn’t dramatically develop very much more than that.

The structurally interesting bit about Starfreighter as a storylet system is that it looks not just for specific qualities (like Fallen London‘s “if your Connected: the Duchess is greater than 10”) but for resources that fit particular qualities, and subsequently binds those identified resources to the storylet for purposes of producing the narration. So for instance you might have a storylet “sell [cargo] on [planet]”, which would become available if you had any cargo (say, a crate of exotic matter) and were on any planet (say, Uinox), so that the storylet text would then be realized as “sell crate of exotic matter on Uinox.”

StoryNexus, or specifically the version used for Fallen London, did eventually gain a couple of related features here. One is a fairly basic form of templating that allows the author to change embedded text in a storylet depending on the value of a particular quality. I used that heavily in the Finishing School portion of The Empress’ Shadow: in this segment, there are storylets that describe how you interact with students you’ve admitted to your school. I wanted to use the same storylets to describe common lessons or situations that could arise at the school, but have them narrated differently depending on which students exactly you’d admitted to your class. Using these variables allowed for a bit of extra local customization.

The other related SN feature is the ability to let the player meet a storylet requirement with a specific object of their choosing. So for instance you could say that a storylet was gated on the player having any Enlightening object, but the player could choose for themselves whether that object should be a book, a scroll, etc. In practice, this was a way for the player to choose how to pay certain costs dynamically, though it was never really developed to its full potential. It would also have been interesting if the player’s choice of unlocking object could also have affected how the storylet subsequently played out. As it is, I used this feature in The Frequently Deceased to let the player choose resources to apply to a particular problem, rather than requiring to have one and exactly one thing.

Still, these are rather late-arrival features in SN and not really designed as part of its core functionality — whereas Starfreighter uses the idea of binding to requirements as a fundamental design principle and makes more robust use of the results. This kind of tool lends itself much more naturally to systemic design: with a (relatively) small number of storylets, Starfreighter gives the player enough material to play for quite a long time. By contrast, one of the challenges with StoryNexus was always the time-to-bootstrap. Making a minimally playable experience with SN took ages because one had to create quite a number of storylets to arrive at anything remotely interesting: there’s a good reason why it’s easier to build onto an existing StoryNexus world than to get one started from scratch. Being able to make some core dynamics with highly reusable storylets would let a new creator get rolling much faster.

As another point of comparison, see also Bruno Dias’ Voyageur, which uses a lot of procedural text generation to produce imagined worlds that are richly described.

Kreminski’s article concludes that there’s space for more easy-access tools in this space, in order to promote experimentation from many artists in the same way that Twine gave rise to an explosion of hyperlink-based content.