December 2023: Inkle is Probably Better than Twine

I've already tried Twine in this series, and toward the end of the venture, I had this cluster of nodes which were interconnected. At the time I had already settled on a structure that would branch out and return to a single ending node, before moving on to the next "chapter". Because of how these nodes are managed, it quickly becomes impossible to properly debug it, opening up the need for play-testers, even if the scope of the project is fairly limited. I think having a rigid project structure enforced upon a developer by the framework is a good way to kill involvement in a project, since there will always be structures that are demanded by the type of project, or the developer, that will end up in conflict with it. It's even worse, if switching between pieces of code is not easy, and that would be my primary issue with Twine.

Inkle doesn't seem to have that problem, but comes with its own caveats. It's not really meant to be deployed on its own, but it seems a lot easier to manage the code, giving you the option to treat it modularly. The testing also seems a lot more accommodating, live-reloading the code without the need to compile it into an .html file each time. It's already helpful in debugging. Unfortunately the cycle tags, which had me originally pick sugarcube 2, don't quite work the way I'd like them to work, but maybe I can find a way around them. I have a few things planned out that will involve an interactive fiction portion, so I thought I'd check this out, before I start committing to either option.

Originally I stumbled across Inkle by looking for an interactive fiction editor for android - I haven't found one yet. I did however think that Inkle seems like a good solution for somebody who doesn't like the html format. I don't love JS, but it's leagues better than cobbling together html and a css stylesheet in my book. Inkle comes with an programming interface, which - oh wonder - has a good reason to use it. The .ink files can be edited in whatever editor you like, which I like for multiline edits. Twine wasn't quite so easy, because of the way it handles pages after choices, so for a proper writing experiences, there's really no alternative to the GUI. The twine GUI leaves a few things to be desired, but that's also kinda inherent to the format of twine. It being based on html so heavily as it is, means that the program is static once started. Inkle is more dynamic, which does lead to a lot of flickering while editing the active node, but at least does live refreshes, which is so much better for debugging purposes.

Now, Inkle is meant to only do the interactive text bits in a larger program. That means that there's no native text input options, and that means that for projects that I would like to tackle, there will have to be a python or JS framework around it. Fine by me, kinda.

Writing Inkle is fairly straight forward. Most of it is text, and reroutes, which are done with arrow tags. If somebody has seen twine before, then this requires only minimal adjustment. Some HTML tags can be implemented in-line, and there's logic options. However, variable handling is a little odd to me. Almost all of the variables will end up being global, and persistent, meaning that it's going to get real cluttered real quick. However, that's kinda what Inkle was made for, as stated in their documentation. The docs also make the concession that this will always be the case for interactive fiction, because we track information differently from computers. So that's what we do.

My first attempt at writing Interactive Fiction was a pure python CLI kinda affair, which worked exactly the way I wanted, but quickly became a huge mess to maintain. Something that can handle classes and variables is a really great tool to have in the background, if you want to implement more complicated concepts. I don't want to get into my writing too much this month, mostly because that's nothing new, and also because we just came out of NaNoWriMo. I'm more focused on the programmatical aspects of the language. I'd love to explore the integration with proper scripting language, but the best way for that seems to be Unity integration, and I'm not learning a game engine in less than five days time.

Because twine handles most things using tiles, and triggering the code only on loading a tile, there's going to be a bunch of basically empty tiles if there's supposed to be something like a primary gameplay loop. Interactive Fiction doesn't necessarily need one, but it's just much more fun from the design perspective if there is one. I also like separating huge variable assignments out into its own block, so I don't have to look at it when writing the text. It's probably the same part of my brain that needs different desks for different activities. Inkle only checks for whether a node has exit, so it can be integrated into a flow when it's called - kinda like a function. In a way, every story node is a function, which means I can make some silent nodes that only exists to assign variables, like when assigning pronouns. In an optimal scenario, I could introduce some of the functions to handle stuff like dealing with plural pronouns. For example, textually there's going to be a difference in whether a character has "he/him" pronouns or "they/them", when something is described. It'll be "He closes the door" or "They close the door". I suppose, past tense will eliminate this problem in most cases, but I prefer present tense for Interactive Fiction, unless I have a proper framing device ("He closed the door" vs. "They closed the door"). The basic way to handle this problem would be to write a logic bracket along the lines of this:

{pronoun_nom == "they": close | closes}

This works, if I tag the pronoun specifically, or I'll have to introduce a new variable that tells me whether the pronoun uses a plural form. Since I can't prompt the user for text inputs anyways, it suffices to do it this way for now. Where this is different from a function is that I can't write a node that takes the base form of the verb as an argument and append an "s" if needed, and then return to the node where it was called. I can pass an exit as an argument, but returning to the previous node will reload it completely, entering an infinite loop. I'm guessing these are tasks that are best delegated to programs outside Inkle.

The logic brackets are otherwise relatively easy to handle, and can do most of what you'd realistically need. There's even scalable random number generators somewhere in there, which one could use for aforementioned gameplay loop. I'd like to highlight something else though. The writing process changes depending on the medium, and on twine it felt scattered, and very different from the usual way I would ever write a sequence of scenes. That's because I had to map out tiles graphically, if I ever wanted to find stuff again, which - considering the amount of debugging I had to do - was a reasonably important aspect. Letting me put as much as I liked into one file let's me write as if I were doing a playthrough of each possible path. I might reuse a few pure logic nodes and pass the appropriate exit, but that doesn't really interfere with the writing process at this point. Retaining the structure I had decided would be good for Interactive Fiction when I checked out twine, would provide very natural "writing checkpoints", where I would have to connect all paths up to a "joining node", at which somebody with a release schedule would post a patch. I don't, so I won't (yet), and there's no file this month either, just because I might want to tinker with it, and come back, when maybe I've learned Unity engine.