Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Using Twine/Snowman as a component of a larger game?

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

  • There is no "Twine playback code". Each story format defines its own syntax and feature set. Twine is only an IDE/compiler.

    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.
  • I would take a look at grunt-entwine and twine-utils. Both are intended to help you with a build workflow involving Twine stories. It depends a little on whether you want your Twine story to be the backbone of your project, or you'd rather glue the Twine data into existing code.

    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.
  • There is no "Twine playback code". Each story format defines its own syntax and feature set. Twine is only an IDE/compiler.

    What about the whole story.show("passage") stuff? I haven't read the code deeply enough yet to know how that is all working...
    klembot wrote: »
    I would take a look at grunt-entwine and twine-utils.

    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.
  • jhocking wrote: »
    What about the whole story.show("passage") stuff?
    That code is part of the Snowman story format's Javascript engine, and not part of the Twine 2 application ('s source code) itself, which I believe was the point TheMadExile was trying to make in their comment.

    In theory you could extract the Snowman Javascript engine but you would also need the relevant html elements it requires to work.
  • greyelf wrote: »
    jhocking wrote: »
    What about the whole story.show("passage") stuff?
    That code is part of the Snowman story format's Javascript engine, and not part of the Twine 2 application ('s source code) itself, which I believe was the point TheMadExile was trying to make in their comment.
    greyelf is correct.

    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.

    greyelf wrote: »
    In theory you could extract the Snowman Javascript engine but you would also need the relevant html elements it requires to work.
    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.
  • greyelf wrote: »
    jhocking wrote: »
    What about the whole story.show("passage") stuff?
    That code is part of the Snowman story format's Javascript engine, and not part of the Twine 2 application ('s source code) itself

    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".
    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.

    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.
  • edited February 18
    I'm pretty new to Twine so I'm not familiar yet with how it draws the distinction of "story format".

    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 :scream:

    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 :wink:


    ¹ With the exception of custom Story JavaScript created as part of the story itself, but that's just inserted as inline <script>.
  • The template within a story format's format.js file also contains place holders like {{STORY_NAME}} and {{STORY_DATA}}, these are used to control where the Twine 2 application inserts the related data into the template when generating the output of the Test, Play, and Publish to File options. The View Proofing Copy works similar except it uses a Proofing Format instead.
Sign In or Register to comment.