Yeah, I think you have a good handle on that.
Hmm. I just went back and I guess it’s not explicitly stated in the four articles from the turn of 2019 into 2020, but IIRC from Twitter at the time, the motivation for that article series was that lots of people had been doing this kind of design for years, but each in their own little bubble, so she was trying to propose and publicize terminology for anything that fits this large umbrella, to show people that they have common ground and get them talking to each other.
So “storylets” isn’t supposed to be a prescriptive term, dividing people into in-groups and out-groups, it’s supposed to be a rallying point. The author of SugarCube described storylets with characteristic tact as “simply an event system with fruity nomenclature” (which is a perfectly reasonable way to look at it) but the fruity nomenclature is the point.
What are different ways to write tooling for stories made of events that know when they’re supposed to happen and how they affect the world? What are common design challenges and solutions across different varieties of these stories and systems?
This is probably the same as what David was getting at, but I think you can approach storylet design from two directions.
One being the “card deck” metaphor, where you take the whole set of all events, or cards, or storylets, or whatever you’re calling them, filter out all the ones whose conditions aren’t currently met, and then present (some subset of) the currently possible events to the user. There are lots of ways to do this, and I suspect any tool should either take an opinionated stance “this tool randomly selects one event and plays it” or try to be fairly open, maybe to the extent of allowing custom code. That gets hairy fast and different stories might want different things. You might want to sort by some sort of relevance and offer the user the top three. You might want to choose several completely at random. You might want priority so you can lock the player into an urgent chain of events (you’re being chased by a dragon, you can’t just ignore it and go play a game of tennis). This is probably the more flexible in the long run but also more intimidating to get started with?
The other approach is that you can start from a branching and add “guards” (conditions) on choices so they only appear at the appropriate time. Ink does the lower end of this design space really well. To extend that kind of design farther you might be looking at ways to group choices separately from the dialogue so you can pull in sets of choices that might be relevant to a particular situation. Dendry is a good example of this: you make simple lists of choices as with Ink (it uses the hyphen as a bullet point) and then you can name choices directly or pull them in by tag so you might say - #greetings
and it’d offer all the greeting choices that fit the current situation.
And finally… since the tag category pages on Emily’s blog seem not to be working properly right now, here’s a quick list of related articles over there:
Bruno Dias’s May 2017 article Attempted: Building a general-purpose QBN system might also be useful to anyone trying to design a system. I disagree with his conclusions, or at least I think his conclusions reflect that he didn’t have the technical expertise to implement good answers to these questions rather than indicating that good answers don’t exist. But it’s a nice breakdown of some of the questions to ask.
Then the cluster a couple years later: