This is an entry from a list of projects I hope to some day finish. Return to the backburnered projects index.

What is it? Various programming-language-centric approaches to procedural generation. I've done a lot of these, and Potrero and Treant are two of the newest ones, but I'm using this to talk about the whole family of these tools.

My approach here is to build tools for procedural generation as programming languages, and usually specifically as functional or logical languages: the UI is fundamentally text-centric, based on writing bits of structured text, and the operations defined can be broken down into atomic units that can be understood and reasoned about in isolation without having to reason about broader state. Additionally, because they are ideally decidable—i.e. you can ensure that they don't loop forever, but instead will always complete in a finite amount of time—you get a lot of ability to statically analyze them.

I think there's a really interesting design space here, and different experiments have focused on exposing them in different ways. There are some thoughts in common between all of them:

• I think (as mentioned) that decidability is important here, both because “this will never loop forever” is a nice property but also because it opens the way for some sophisticated static analysis, like, “Will this program ever produce output with such-and-such a property?”
• I think mostly-pure functional programming is a useful way to think about these things, where the only side effect is non-determinism
• I think there's some interesting inspiration to be taken from logic programming or answer-set programming (c.f. Smith & Mateas, Answer Set Programming for Procedural Content Generation: A Design Space Approach and also Karth & Smith, WaveFunctionCollapse is Constraint Solving in the Wild)
• I think there's a lot of API work to be done around exposing common resources (like Darius Kazemi's corpora) as “standard libraries” to draw on
• I think there's also a lot of API work to be done around the right primitives for structuring output either textually or non-textually (although I'll freely admit that there's research here that I'm not conversant with!)

So the goal of my various tools has been to chip away at this space and experiment with these various theses!

Why write it? The big tool in this space right now is Tracery. Tracery is a great tool and I love it. That said, I'm very picky about tools.

To give an example of what I mean, here's an example of a Tracery program which creates a brief description of meeting a person:

{
  "origin": ["#[#setNoun#]story#"],
  "setNoun": [
    "[person:man][them:him]",
    "[person:woman][them:her]",
    "[person:person][them:them]"],
  "adj": ["familiar", "strange", "mysterious"],
  "adv": ["warmly", "cautiously", "profusely"],
  "story": ["You meet a #adj# #person#. You greet #them# #adv#."]
}

You'll notice that the syntax is all JSON, with all the advantages and disadvantages that brings: it's a universally available format, which is good, but it's also more finicky and particular, and also now important syntax is embedded in the string literals in a way that's not (for example) syntax-highlighted by default. Note also the "setNoun" rule above: what this does is actually create new rules effectively by injecting them into the set of rules, so depending on which choice is made, it'll define the rule "noun" as being either "man", "woman", or "person", and define "them" as being a corresponding pronoun.

Here's the same generator expressed in Matzo, a dynamically typed programming language for procedural generation that was also the very first tool I built along these lines:

person := "man" | "woman" | "person";
pronoun :=
  { "man"    => "him"
  ; "woman"  => "her"
  ; "person" => "them"
  };
adj ::= familiar unfamiliar mysterious;
adv ::= warmly cautiously profusely;

n := person; fix n;
puts "You come across a " adj " " n ".";
puts "You greet " pronoun.n " " adv ".";

This has a lot of little convenience features, like the ::= taking a set of bare words that are implicitly understood to be a disjunction. (Indeed, you could rewrite the first line of the program to person ::= man woman person; and it would have the same meaning: I wrote it with := to showcase both approaches.) It also has functions—the value of pronoun is a function which branches on its argument—and the fix operation, which takes a rule which otherwise would be vary, evaluates it once, and modifies its value to be the result of that: i.e. after that line, person will still randomly be one of three values, but n will always deterministically be one of those three values.

After Matzo, I worked on a tool called Latka which was similar but with a light static type system. You'll notice this one relies more heavily on things like (structurally typed) algebraic data types and helper functions to assemble sentences, like pa for a paragraph or se for a sentence. You might also notice that fixed is no longer a thing which changes an existing rule, but a property of the binding site of the variable.

let gender = M | F | N
let noun M = "man"
  | noun F = "woman"
  | noun N = "person"
let them M = "him"
  | noun F = "her"
  | noun N = "them"
let adj = %{familiar unfamiliar mysterious}
let adv = %{warmly cautiously profusely}

let main =
  let fixed n = gender
  pa.[
    se.["You come across a", adj, noun.n],
    se.["You greet", them.n, adv],
  ]

These obviously have tradeoffs relative to Tracery, but they more closely match the way I think about these problems and the way I'd naturally gravitate towards solving them. That said, I also don't think they're competing: in fact, one thing I've wanted to do (but never finished a prototype of) is building cross-calling between them: I'd love to be able to directly include a Tracery program in a Latka program and vice versa.

As with other projects I've described, I think that the affordances of functional or expression-oriented programming have a lot of benefits, and I think decidable programming languages are really useful. And of course, one reason I want to write it is that I love random generation of things.

There's a reason this project is also the last backburner post: it's the project I most regret having left on the backburner, and the one I would love to spend more time on soon once I develop motivation to do so again.¹

Why the name? Latka and Matzo were named together but otherwise chosen at random. I was originally gonna call another experimental language Mesa, which is Spanish for 'table' (by analogy with random tables you'd find in an RPG book) but there's already a graphics driver suite called mesa. So I decided to choose the name of a related geographical phenomenon, since a potrero is a kind of mesa. Similarly, the original version of Treant was designed around probabalistic tree rewriting, and treant is a name used in fantasy role-playing games to refer to a public-domain equivalent to Tolkien's Ents.

#backburner #tool #language #procedural

This is an entry from a list of projects I hope to some day finish. Return to the backburnered projects index.

What is it? A video game about procedurally-generated under-equipped spy missions.

The player is a nameless spy with almost nothing on them: maybe a tiny amount of money, an object or two. They have an objective: a document to steal or replace, a photograph to take, a target to kill. They are in a randomly-generated city with a roughly 1980's level of technology: computers exist but are rare, mobile phones aren't practically obtainable, and only some sections of the city are accessible but within those sections you can (with some difficulty) get almost anywhere: apartments, offices, basements, and so forth. Go.

The intention is that there should be multiple ways of tackling the objective, but you need to be resourceful. You need to find your own disguises, hotwire cars or take trains, pickpocket money from people, do research in the handful of places where you can. You have no spy agency to rely on to bail you out or drop you resources: if you get caught, it's over, and all-out firefights are a failure condition. You're on your own, with only the infrastructure of the city to help you.

My mental image here was that this game would have the graphical sophistication of a roguelike: that is to say, very very simple grid-based graphics, no strong detail. The detail should instead be in the density of the simulated urban environment, ensuring that buildings do indeed have dozens of accessible and usable rooms (probably generated on-demand: after all, with that much detail, 95% of the map would never even get accessed!)

Why write it? I can pinpoint the exact blog post that inspired this game, which is this post about the “Bourne Infrastructure”. I read this around the same time that my brother and I had been discussing a very different kind of spy game—the James Bond-inspired kind of spy game, with massive explosions and firefights and stunts and whatnot—and it got me thinking, “What would a Jason Bourne game—one that really captured the feeling of the movies, not just a reskinned stealth game—look like?”

There's a lot of complexity here, and a big part would be managing to implement new and different ways of tackling the objectives. There's also an economy of detail that I don't off-hand know the right way to manage. I want players to be able to lockpick an apartment, sneak in, rummage through a drawer, steal a suit, and go off to blend in at an office, but that could easily grow and grow until there are unwieldy inventories and far too much stuff simulated. Finding out the right amount of fidelity here is key, and I don't yet have an instinct around how to do that.

Something I'm super interested in, though, is using stuff like shape grammars to create the world. It'd be a lot of fun to build the basic mechanics and then just keep revisiting new stuff to add to the world, making the city deeper and denser!

Why the name? It's a temporary name—I don't want to actually name it after a real place!—but it's named not for Schengen, Luxembourg itself, but rather for the Schengen Area since the setting is a roughly-defined European setting.

#backburner #videogame #procedural

This is an entry from a list of projects I hope to some day finish. Return to the backburnered projects index.

What is it? An authoring tool for simplistic shape grammars intended for generative art.

A shape grammar is a tool for building two-dimensional objects. Like all grammars, you can think of a shape grammar as either a recognizer of a language or as a generator of a language, and for our purposes it makes more sense to think of them in the latter sense. Also like other grammars, it consists of a set of rules, each of which has a left-hand side and a right-hand side: generating a language from a grammar is a process of finding rules whose left-hand side matches some part of an intermediate state, and then replacing that part with whatever is specified by the right-hand side. Similarly, some components are considered 'non-terminals', which are symbols that always appear on the left-hand side of rules and are meant to be replaced, while others are 'terminals' which form the final output: once a state contains no non-terminals, we can say it has been fully generated by the grammar.

The biggest distinction between a shape grammar and a traditional grammar, then, is that a shape grammar operates over, well, shapes. In the case of Palladio, the intention was for it to operate over sprites on a square grid. As an example, consider a grammar defined by these three rules:

These rules are very simple: when we see a symbol on the left of an arrow, it means we try to find that symbol and replace it with whatever is on the right-hand side. That means if we see a black circle, we replace it with the symbols on the right: in this case, a specific configuration of a black square and two red circles. Similarly, when we see a red circle, we can choose one of the two possible rules that applies here: either we can replace it with a black square, or we can replace it with a light blue square.

This grammar is non-deterministic, but generates a very small number of possible outputs: rule A will produce one terminal and two non-terminals, and we can non-determinstically apply rules B or C to the resulting non-terminals. In fact, here we can show all four possible outputs along with the rules we apply to get them:

That said, it's not hard to write grammars which produce infinite numbers of possible outputs. This grammar is not terribly interesting, but it does produce an infinite number of possible outputs: in particular, it produces an infinite number of vertical stacks of black squares.

We can't enumerate every possible output here, but you get the idea:

My goal with Palladio was to write an authoring environment for grammars like these, with the specific intention of using them to produce tile-based pixel art pieces. This means not just providing the ability to create and edit rules like these, but with things like live outputs—possibly with a fixed random seed, for stability, and possibly with a large set of seeds, to see wide varieties—and maybe analysis of the output, alongside the ability to export specific results but also the data used to create these.

Why write it? For fun and experimentation! I don't just love making art, I love making tools that make art, and my favorite way to do so is using grammars. Grammars act like tiny constrained programs over some value domain, and you can still bring a very human touch to writing a grammar that produces a specific kind of output.

Doing a tool to support this that's both graphical and constrained to grids is a good way to make it easy to get started with. My plan was even to build tools to spin up Twitter bots as quickly as possible, too, so someone could design a grammar and then with minimal fuss start showing off the output of that grammar on the internet.

My original version (which I admittedly didn't get terribly far with) was written as a desktop app (in Rust and GTK) but I suspect that for the purposes of making it easy to use I'd probably reimplement it to have a web-based version as well, making it easy to open on any device. It'd be nice to also build simple-to-use libraries that can ingest the grammars described, as well, so they can be embedded in other applications like video games or art projects.

Why the name? After the architect Andrea Palladio, but specifically because one of the famous early papers about shape grammars in architecture was Stiny & Mitchell's 1979 paper The Palladian Grammar. Palladio was famously schematic in terms of how he designed and constructed houses, so Stiny & Mitchell were able to take those rules and turn them into mechanized rules which can express the set of possible villas that Palladio might have designed. For a more recent and accessible treatment on the subject, you might look at Possible Palladian Villas (Plus a Few Instructively Impossible Ones) by Freedman & Hersey.

#backburner #software #tool #procedural

This is an entry from a list of projects I hope to some day finish. Return to the backburnered projects index.

What is it? A video game that's been kicking around my head for ages: a roguelite loosely inspired by a childhood favorite of mine, Yoda Stories.

In effect, Tales is a roguelike in the classic vein, albeit with a slightly greater focus on non-violent NPC interaction. Each “run” happens in a different randomly-generated area and is built around a randomly generated task, but that task is gated by a number of smaller intermediate tasks, which might range from fights to sneaking to exploring to simple conversation with NPCs. The tree of objectives is also randomly generated, so the world needs to be explored a bit to fully grasp what's needed: you may need to acquire a replacement wheel for a vehicle, and that wheel may be a gift in exchange for getting rid of some bandits, but discovering both of those requires traversing the world a bit.

By and large I think the ideas described above aren't too interesting: a game like this would mostly succeed or fail based on world generation and the implementation of basic mechanics like combat. My mental image here for the combat is that it would be a simplistic real-time top-down brawler, smooth but not too deep or challenging. I'd want a small variety of weapons or abilities, but not to the point that you'd get the sheer combat depth of something like Hades, mostly because I'm not interested in that kind of depth myself. That simple fluid combat would be augmented with a simple conversation mechanic and a set of world generation processes which could create different kinds of worlds for different runs: dense multi-layered cities, sparsely-populated grasslands, networks of islands with ferries, and so forth.

Beyond the relatively straightforward mechanics, though, there is one interesting design problem I want to tackle with Tales: how to build a mechanic that allows for character progression without necessarily having an overarching difficulty curve. I'd like the level of difficulty of each run to stay relatively static: that is, the game itself should not get harder as you play more unless the player explicitly moves a difficulty slider. At the same time, I'd like to allow for players to gradually gain techniques and talents and customize a character. My current idea is that a character should have a fixed number of points, and before each run a player would be allowed to freely move points around, both into default abilities (like “strength”) and into new abilities which you pick up as you play the game (like proficiency with unusual weapons or the ability to use different non-standard techniques like fast-talking or hacking). Over time, the player can specialize in radically different ways of tackling runs, but without the straightforward consequences of leveling or getting better gear: they are not straightforwardly “stronger”, but rather have sacrificed some general abilities for more specific or unusual abilities. Ideally—although this would require some subtle tuning—this approach would allow a player to explicitly choose to tackle more difficult runs over time by specializing their character with more specific abilities that offer higher mechanical complexity, but that difficulty isn'ted baked-in to the assumptions of the game like it would be for other RPG-like games.

Why write it? There's something weirdly appealing about Yoda Stories. I've seen multiple other people—including Zach Barth of Zachtronics fame, as part of his article on reverse-engineering the graphics of the game—talk about how they remember the game fondly despite it being poorly-reviewed and, quite frankly, bad.

As I mentioned above, the success of a game like Tales would largely be dictated by world generation and basic mechanics. It's worth noting that Yoda Stories failed on both these counts. It had mediocre world-generation: it was a randomly-assembled quilt of pre-created sections, but those sections were assembled mostly at random, which meant there was often no indication you'd reached the end of the world: you'd simply be at the edge of a screen with plain desert and yet magically wouldn't be able to move. Even moreso, it had hilariously bad combat: it was a game with real-time movement, but movement was instantaneous on a square grid, so enemies could pop in and out of existence next to you as you swung your lightsaber.

That said, despite the problems, there was something about Yoda Stories that was still inspirational in a way that the other roguelike-ish games weren't for me. I do love Nethack, but even when first playing it I wasn't immediately compelled to make another. My suspicion is that the world of Nethack is a dungeon, but the world of Yoda Stories at least gestured at the idea of being a world where people lived, with little cities and farms and cabins and so forth. It's also restrained: one feature of Yoda Stories was that the difficulty was built around 'how long do you expect this game to take?' where the options ranged from 15 minutes to an hour, since the goal of Yoda Stories was to create a casual game more like Minesweeper than traditional roguelikes. I think this is still a worthy design goal: more games should be small and focused, with a gentle learning curve and no expectation that you'll play them forever. All this together means that a game which takes the things I like from Yoda Stories, but smooths out the roughest edges and plays up the most interesting strengths, still feels like a game I'd want to play.

Why the name? The name Tales is just a stand-in name. At one point, I was referring to it (in a wild Incal-inspired science fiction incarnation) as The Emissaries of Guenashk, but I later on borrowed that name for a tabletop project which I'm going to write about later this month.

#backburner #videogame #procedural

This is an entry from a list of projects I hope to some day finish. Return to the backburnered projects index.

What is it? A video game: a scifi sandbox farming-sim game after my own tastes, one I've had kicking around in the back of my head for a long time.

The premise of the game is that you're a farmer who has moved to a new, uninhabited-by-sentient-life planet: there's a little settlement, and you get only sporadic contact with the core worlds for supply drops. Your primary job is to start building and maintaining your farm, and for that matter, understanding how and what to farm: the native plants and wild creatures are alien and unfamiliar—and procedurally generated for that save file—and you'll have to use a combination of laboratory analysis and practical experimentation to figure out which plants are edible, which plants are usable for medicine, which plants are usable for building materials, and so forth.

This will involve a combination of infrastructure-building and exploration. Infrastructure-building means, more or less, building out and maintaining a farm, but also expanding the little settlement to support more people, building homes and ensuring there's enough food and supplies for the sporadic new arrivals. Exploration would let you find new plants, new creatures, maybe even new places for settlements. Ideally, exploration will be slow and intentional and a bit difficult but not punishingly so: I plan to eschew any kind of combat, so the challenges would be around exploration and juggling resources like food and shelter, along with dangers like traversing rapids and bouldering up mountains. The world would be finite and exploration won't be a solution to all the problems a player would face: instead, you'll eventually develop the ability to do selective breeding of plants to come up with new, more-useful variants: cross-breeding varieties to select for larger yield or more resistance to climate variation and so forth.

Visually—at least subject to my own ability to implement it—my plan was to create a world inspired loosely by the paintings of Eyvind Earle, with lots of stark geometric shapes and sharp blocks of striking color. The look of the buildings would borrow heavily from the great concept artist Syd Mead and also from the building ideas of the futurist Buckminster Fuller. Of course, this graphical style was more than a bit aspirational, and I confess in my prototypes I never actually got to the point that it looked like it did in my head: I've since considered whether this game would be better served with a Roguelike-inspired grid of simple pixel art tiles, like Caves of Qud or the Oryx tiles for Brogue.

Why write it? My original ideas here actually far predated the survival sandbox games of the present day. When I first entertained ideas about it—in the mid-2000's, when I first wrote the name Albulaan in a notebook—my major inspiration was Harvest Moon: my original desire was to have a Harvest Moon-style farming sim game with procedural and exploration elements, a game where you couldn't simply look up in a wiki (or, at the time, a strategy guide) which crops were the best or where to go to find resources, because those crops and resources were unique to your own save file.

At this point, there are many more games in the genre that actually get closer to the game I want, although not quite bringing the same focus I'd want. There are plenty of more mechanical, infrastructure-based games like Factorio, plenty of more combat-focused survival sandbox games like Minecraft, plenty of expansive procedural worlds like No Man's Sky. I should be clear that the Albulaan of my dreams is not actually like any of these: I'm not interested in Factorio-style factory optimization, Minecraft-style resource extraction, or No Man's Sky-style tech trees. The gameplay of Albulaan should feel a little bit more like a Stardew Valley: daily farm maintenance coupled with some side activities and cheerful chats with settlement NPCs, with a bigger world and a set of traveling mechanics taking the place of Stardew's combat-focused mine levels.

Admittedly, one personal pet peeve I have about many of the games in this same space is that they try too hard to include every possible mechanic and end up with an awkward and subpar version of many of them—like Stardew Valley's clunky and static combat system, or Animal Crossing: New Horizons' tedious attempts at crafting mechanics—and that's one reason why I explicitly described Albulaan above as lacking things like combat mechanics: I genuinely believe there should be more games that don't try to tack on every possible way of interacting with the world, which is why my goal for Albulaan is to do farming and exploring and world-generating well, and that's about it.

Anyway, I do think several of my ideas for Albulaan are still distinctive—like the selective breeding of procedural plants—even if they're less unique than they would have been in 2005. If nothing else, it's still a game that, if someone else created it independently, I would want to play.

That said, I'm also not 100% sure which aspects of this idea will remain intact when I return to it. For one, I've gotten more and more uncomfortable with the colonialist and extractive aspects of some of these games, and I'd love to figure out a way to design Albulaan in a way that can mitigate some of these concerns. The fact that the world is necessarily finite—and consequently certain resources are also finite, and the player must think about conservation and renewable resources—might help here, but it's not a silver bullet that handles all (or even most) of the work of removing the colonialist underpinnings from a game like this.

Why the name? The word al-bulaʽān (ألبولعان), which literally means “the two swallowers”, is the Arabic name for two stars in the constellation Aquarius: specifically Nu Aquarii and Mu Aquarii. My first notes about Albulaan date back to my high school years, when I did some Flash experiments with the intention of creating procedural animals for it: at the time, I chose the name arbitrarily from a list of star names, and I've used it as my working title since.

#backburner #videogame #procedural

This is an entry from a list of projects I hope to some day finish. Return to the backburnered projects index.

What is it? A very simple library and engine for writing storylet-based narratives.

“Storylets” are an approach to writing procedural, interactive narratives. There are a lot of different ways you can approach storylets, but the core idea is that you've got some kind of world state, and based on that world state, you choose a piece of “content”—in Rakonteto's case, a fragment of prose—that you can present to the player. The player can then make choices which change the world state, and that in turn allows the game to present another piece of content to the user.

Probably the simplest way to contrast this to other interactive narrative systems is by comparing it to a Choose-Your-Own-Adventure-like branching narrative system. Imagine that you want to write a story in which the player must go to two different places (A and B) in either order, and only after that can they return to a third, final place (Z). In a pure CYOA-style game, you effectively must have two branches, one corresponding to the sequence A → B → Z, the other B → A → Z, which implies that you must duplicate the content for A and B even if there are otherwise no changes to the visit to A and the visit to B. (And that's just for two places: if we have three places to visit in any order, we'd have to duplicate the content for each of the six possible visit orders!)

In contrast, a storylet-based system would let you represent A and B separately, and each one would end with modifying the world state with information indicating that the location had been visited. Finally, Z would include as precondition that A and B had both been visited. Many storylet systems allow for selecting the most salient next fragment, as well: that means that A and B can also include special content which will be surfaced in the specific situation that they're being visited first or second, but without having to duplicate all the content associated with A and B.

My implementation—Rakonteto—is designed as a textual language for producing interactive prose, loosely inspired by Ink. A given fragment of a story would look sort of like this:

=== [var: expr, var: expr, ...] ===

A fragment of text, to be shown to the player.

+ A choice. -> [var: new_expr, ...]
+ A different choice. -> [...]

The stuff in square brackets at the top is a set of “variables”—properties of the world, so to speak—with their current values. When the underlying story engine needs to choose a new story fragment to show to the user, it looks at each fragment to find whether the declared variables match the current state of the world, and then (using a handful of heuristics) choose a matching fragment to show to the player.

The bits at the bottom introduced with + are choices the use can make, and the stuff in brackets afterwards describes how to change the world-state so that a different fragment can be chosen next. A more “realistic” example might look like this:

=== [has_sword: false, in_location: forge] ===

As you walk into the forge, smoke stings your eyes. A
towering, muscular man with a singed beard is staring
pensively at the embers: as you approach, he is roused
from his thoughts and nods. Without a word, he turns,
walks to the back of the forge, and returns with a
beautiful and freshly polished sword, its surface only
marred by the man's sooty fingerprints.

+ Take the sword. -> [refused_sword: false, has_sword: true]
+ Decline the sword. -> [refused_sword: true]

The world state can include far more variables than are listed, and only the variables mentioned in the choices get updated: the others persist. One thing I hadn't figured out was the correct heuristics for handling selection among multiple different fragments that match to the same degree of “salience”. Another was how to provide tools to make certain common patterns more convenient: for example, I planned to have syntax in which you could include or swap out individual phrases or sentences based on parts of the world state, so that certain bits of customization didn't need an entirely new fragment. I also planned to have some choices “gated” by aspects of the world state, and also syntactic sugar for small branching scenes (so that you don't need to introduce new variables for situations like singular yes/no decisions that only matter within a single fragment.)

The original version was constrained entirely to finite sets of “world state” variables which could range over atomic strings, but I planned to also experiment with constrained integer arithmetic and eventually maybe even composite values like lists or sets.

Why write it? Mostly for experimentation! There were a few specific features I wanted to experiment with.

One such feature was that I wanted to have an engine for storylets which could be quickly and easily turned into something which can be played, sort of like the interfaces provided by Twine or Ink. My goal was that you could write a game and then “compile” it to a standalone HTML document that includes all the JavaScript necessary to run an interactive version of the game. For early playtesting, I also created a tiny command-line driver, which allowed you to choose from a list in order to move forward.

Another feature was an embeddable API. I wanted to be able to take this and link it in to other programs which could interact with it: for example, exposing it as a library so I could integrate it into a Unity or Unreal game (although I'd likely have started by writing bindings in something much simpler, like Löve.) The previous compile-to-HTML feature would let you get stories in front of people quickly, but I wanted to design the system such that you could use it as the “story backend” to a different kind of game, as well.

Finally, I wanted to experiment with debugging and modeling tools. With the state space constrained sufficiently, you could start throwing various solver techniques at a narrative. One reason you might want to do this is reachability: “I have these variables which have different states, and can change in this way. Can I actually ever get to this specific state?” Another is as a kind of automated play-testing. When your story is complicated enough, it might be possible for a player to “sequence break”: that is, to experience the story in a way that you didn't anticipate. I imagined addressing this with a solver as well: you could query your story model and ask questions like, “Is it possible that the player could experience fragment X before fragment Y?” and the tool could either confirm that it's impossible, or show that it is and give you an example of such a play-through.

Why the name? The word rakonteto is Esperanto: it's a diminutive form of rakonto “story”, so it means something like “little tale”.

#backburner #software #language #procedural