Exactly what it says on the tin. What is the difference in the approaches taken by Harlowe and Snowman’s storylet systems, as opposed to TinyQBN?
As a bonus question, how do these implementations of storylets compare to, ssay, Dendry or StoryNexus?
2 Likes
Oh, boy, even though I wrote TinyQBN and played with Harlowe’s storylets, it has been a while so I don’t remember exactly. I wasn’t aware that Snowman had storylets, so I don’t know about the capabilities of those.
I believe Harlowe’s storylets are equivalent in theoretical power to TinyQBN, but you have to do more of the work of selecting and displaying storylets yourself. TinyQBN gives you a little more help with the common use cases there.
Dendry has more built-in capabilities around altering the probability of storylets, I think. And StoryNexus, of course, had a whole built-in UI for displaying stats and inventory, and a system for stat checks and having stats increase as you used them: you’d have to build all those things for yourself in Twine.
Getting any more specific would get very technical very quickly, I think? And I’d say that building something with storylets is more of a design challenge than a technical one: you can probably work around or design around any limitations of the engine, mostly.
But I’d be happy to talk about it more, either publicly or privately. Do you have a specific project you’re trying to build?
3 Likes
I’m in the design phase of a game ATM, one which makes more sense to design using the storylet mechanism. I have experience with Twine (mainly SugarCube), and I’ve looked at some Dendry code. I’m just trying to choose the right tool for the job.
1 Like
I think it probably comes down to which style of code and tooling you prefer. I thought Autumn Chen’s paragraph about Dendry back in the postmortem to Pageant was interesting:
I really like dendry. The syntax looks reasonable; I dislike nesting-heavy structures like choicescript or ink. It has a flat layout, and is organized into scenes which are further divided into content nodes. This organization accords with my way of thinking and writing. The compilation and deployment processes were simple. The domain-specific language was simple but functional enough to do everything I wanted it to do, and javascript could be included for more complex scripting (although I didn’t use custom JS).
Back to my thoughts:
I think Dendry has arbitrary numbers of priority levels: TinyQBN only has a couple. It may also have better tools for managing frequency of storylets? But I’m not quite sure how that works.
Dendry has more of an Ink-like syntax for displaying individual choices (or choices by tag) which still get filtered by their conditions. That’s pretty handy. It’s significantly more clunky with TinyQBN to define choices inline.
Dendry also allows more of a transcript-style output like a parser game instead of having every link go to a separate page: that’s harder to pull off well in Twine.
On the other side, you’re already familiar with SugarCube, and Dendry isn’t very well documented (TinyQBN’s documentation isn’t as good as it should be, but I don’t think it’s quite as sparse as Dendry’s).
That’s about all I can think of to say, without knowing more specifics about how you might want to structure your story… I don’t think there are many insurmountable differences between the different storylet tools?
3 Likes