More examples of what's easy/hard to implement in different story formats?

[relsqui]

I'm trying to decide what story format I might want to try to learn. Choosing Story Formats sounded like exactly the page I wanted, but it only has a couple sentences about features for some of the formats. For example, "gives readers the ability to save their progress into separate slots" is very helpful because I can think about whether I want to use that, but "advanced functionality built into its inserts and modifiers" is less so because I don't know what that means or what it might let me do.

I could play some stories in each, but I wouldn't know which differences are because of the format and which differences are author choices. (Also it's a big time investment when I'm itching to make something right now, but that might be a me problem.)

It would be fair to punt this to the story formats' own websites, but I checked, they barely explain it either. 😅 So I'm hoping someone with more familiarity could add more specific examples here.

[videlais]

The Choosing Story Formats page could be expanded, it was originally written in 2014 after all, but this overall issue is horribly complex and often fairly specific to a project. Each story format currently in Twine is not unlike its own programming language at this point. Some concepts are available across all them in similar forms, but certain patterns easily available in one might not exist at all in another. As you note, some story formats use the term macros, Chapbook uses inserts and modifiers, and Snowman uses a template system with more or less pure JavaScript. And these are merely those story formats packaged with Twine itself. There are another dozen to 20+ floating around as well.

One approach I could see is linking to sections or pages in the individual documentation of each on common topics and patterns. How functionality (macros, inserts, etc.) are written could be a section. Another on variables. Another on branching patterns using conditional functionality. Much of this already exists as specific examples in the Cookbook, but it could be organized as part of this page.

[relsqui]

Thanks for the quick response! I think those are noble goals, but I also encourage small useful increments -- adjusting which features are called out on that page without increasing the length at all would have been enough to unstick me. (For more detail I could then go read more about whichever one had features I care about.) For that matter, if it's mostly about syntax preference and the underlying capabilities aren't that different, saying that explicitly would've been a helpful addition too. :)

[videlais]

@relsqui In 2014, the story formats of the time, Harlowe, SugarCube, and Snowman, were very similar. A decade later, they have significant linguistic and technical drift. For some things, it could be categorized as a syntactical choice, but for others like, for example, how changing the values of variables in Chapbook versus how the same functionality works in SugarCube is very different. The capabilities, too, are story format locked, depending on what you want. As another example, SugarCube supports using audio via macros, Harlowe does not, and Snowman supports using JavaScript + HTML5 elements to load things. The debugging, "Test from here" functionality, is also very different per story format as well. The same too with if additional buttons exist: Harlowe and Chapbook add a toolbar that doesn't exist in SugarCube and Snowman.

[greyelf]

A slightly more accurate wording of the following...

As another example, SugarCube supports using audio via macros, Harlowe does not, and Snowman supports using JavaScript + HTML5 elements to load things.

...might be...

As another example, SugarCube includes both macros and a JavaScript API for playing audio, Harlowe requires the Author to install a third-party addon to add such macros & APIs to their project, and Snowman requires the Author to use the standard JavaScript + HTML5 elements that a web-page uses to play audio.

[videlais]

@greyelf Classic you.

[relsqui]

Thanks both for the additional context.