I just started using Twine and was pleasantly surprised to see there's a way to control things pretty directly using JavaScript. Since I am an experienced programmer, I switched to Snowman and have mostly figured everything out already, but I'm wondering if anyone has any tips about using Twine as the dialogue engine for a game I'm writing in JavaScript. I assume it'll be importing Twine's playback code into my game, instead of using the HTML file Twine publishes.
Comments
Chris will probably have his own thoughts on this, but I'll toss in my two cents.
If you only need/want Snowman's template system, then it may be easier to include Lodash or Underscore in your project as Snowman uses Underscore's template system.
If you need/want the rest of what Snowman offers, then forking its repository to pare back the published file to only what you need for inclusion into your project would probably save you a lot of time in the long run.
In the first case, where you're augmenting a Twine story, you can easily use entwine to merge in external JS and CSS to a final product. The second case would take a little more work. You could use twine-utils to parse your Twine story into JavaScript objects and then use that as an input for whatever build process you already have set up.
What about the whole story.show("passage") stuff? I haven't read the code deeply enough yet to know how that is all working...
ah interesting, I didn't know about twine-utils. I'm definitely doing more of "glue the twine data into existing code" so I'm gonna check that out.
In theory you could extract the Snowman Javascript engine but you would also need the relevant html elements it requires to work.
As an example, SugarCube v2's core navigation API is Engine.play(passage). Harlowe undoubtedly a similar navigation API, though I don't know what it is offhand and it may not even be publicly accessible.
While the Twine 2 story formats do share various commonalities each is a separate application onto itself and they do not share code or APIs.
As for Twine itself, the only thing it really does when compiling your project is to inject the passage store and a few other pieces of information into the chosen story format template.
Indeed. That was the thrust of my earlier comment about forking its repository and paring back the story format to the bare essentials. Though, perhaps that didn't come across as clearly as I'd hoped.
ah okay, that makes sense; I'm pretty new to Twine so I'm not familiar yet with how it draws the distinction of "story format".
Thanks for pointing that out! I'm gonna look into the twine-utils klembot pointed out though, because if it comes down to forking the repository and doing a lot of under-the-hood hacking, I'd rather just build my own dialogue system from scratch. That was my original plan (basically what's described here) but I started thinking it might save me time to incorporate Twine into my game.
I'm no expert, so I may have this wrong or be oversimplifying, but—
The story format is The Entire Engine of a Twine story; in the browser, there's no functionality that doesn't belong to the story format, no JavaScript that the Twine application adds onto it.¹ Twine 2 (twine.exe, if you like) is effectively an authoring tool for producing markup that a Story Format can parse.
When you publish your final story, the file includes all your passages in custom HTML tags and a script tag that containing the story format: that's all. At runtime, the story format reads the passage data stored in the DOM and decides how to display it. Theoretically, you could hand-write the HTML passage markup in your own file and a proper linked story format would play ball.
Hope that's helpful, and not redundant with what's already been said. Doubly hope it's correct
For what it's worth:
It may still save you time to use Twine if you use it as a prototyping tool with a nice GUI for managing your dialog data. With Snowman you can easily use passages as modular units of content, or as composable components: if you wrote your dialog system with Snowman as a framework, using passages for storing dialog text or simple UI systems, you could get the bulk of your code working and testable in Twine, and just port the relevant bits to the rest of your game when they're ready.
But that's just me armchair-workflowing, maybe in practice that wouldn't actually be much help
¹ With the exception of custom Story JavaScript created as part of the story itself, but that's just inserted as inline <script>.