Tag: interactive fiction

As I mentioned a few months back, I’m writing interactive fiction now. I’ve been planning one called The Anitra Incident, which I envision as a kind of prequel to my Orphans of the Stars novel series. (The second, which I’m actually in the process of writing, is…something else that I’ll never attach my real name to.)

In the previous post, I looked at what I consider the top four tools for creating interactive fiction: Inform 7, Twine, Ren’Py, and Ink. I think I made it clear then why I felt Twine was the best choice for what I’m writing. Now that I’ve been working with it for a while, I have some thoughts to share. These are more of a ramble than even my usual posts here, so bear with me.

Ditch the editor

Twine’s biggest draw is that it has its own editor, with a nifty little drag-and-drop visual tool to organize your stories. It looks good, and it helps to get people interested in creating, rather than whining about how they don’t want to have to learn anything.

But it sucks.

Yes, the editor works just fine for small-scale constructions. Twine divides its stories into passages, which are just that: bits of text that can be anywhere from a few words to an entire chapter, with all the necessary logic for interactivity sprinkled in. A big story with a lot of branching points, arcs, and the like is going to have hundreds, if not thousands, of passages. (Case in point: my unnamed side project has 232 total passages already, and that’s not much more than a set of locations and a handful of conversation scenes.) Trying to keep all that straight will quickly become impossible.

On top of that, the editor’s structure makes it difficult to write code. There isn’t much room for "metadata" on a passage; for the most part, that’s limited to a series of tags, which you have to edit using the "chip" style of tagging that web devs love for some inexplicable reason. But that means you have to put all the code in that little box, even if you’re using a tool that expects tags. In my case, that’s TinyQBN, a library for implementing what the creators of Sunless Sea call "storylets".

I could rant about the editor for another few posts, but I just don’t bother using it, so I won’t bother discussing it further. Yes, setting up a custom workflow is a bit more difficult. Yes, it’s worth it in the end. After doing the work, I can now write my story in Vim and my code in, er, Code. And it all comes out the same, except that I also have better handling of external JS libraries, static analysis tools that can run automatically, and so much more that I’m used to from my life as a developer.

People are stupid

Which brings me to my next point. The average Twine user is not a professional developer or a professional author. Worse yet, neither are the Twine power users. As far as I can tell, I’m just about the only one using Twine who does both. Believe me, it shows.

Most Twine tutorials are written for someone who has never so much as looked at code, and who barely even knows what fiction is, let alone how to write it. I don’t know why Twine’s community targets journalists as its intended audience, but that’s how it is.

For someone who knows both fields, it’s just frustrating. I’ve already read the intro material. I know what a macro is. But no one out there is creating any resources for the intermediate or advanced users. How should I structure a story in terms of source files? What are some common design patterns in interactive fiction, and how do I apply them in Twine? When should I break a scene across multiple passages, and what’s the best way to handle that?

I get that much of writing fiction is an art. I’m well aware that there’s no one-size-fits-all method for creating a novel. But to assume that everyone is forever going to be stuck at the beginner stage is doing the rest of us a disservice. I’m aware that zoomers, degenerates, and progressives (the main components of the intfiction.org "community") don’t know how to learn; people who look to Tumblr for knowledge and wisdom have shown pretty definitively that they have neither. Surely somebody out there cares about the rest of us, though.

If not, maybe I should work on that myself.

Wokeness taints everything

Allegedly, the interactive fiction community is thriving, and Twine is a big part of that. In reality, there’s not much of a community. Much like any other hobby (people don’t generally make a living off adventure stories, unless they work for Failbetter), the anti-human rot of progressivism infects every large gathering that would have the chance to become a community. Those of us who prefer free expression to censorship are, as usual, labeled extremists for the radical view that words are just words. Strange for a hobby built around words, but that’s the whole point of the woke ideology: to tear apart any gathering of like-minded individuals by setting them against one another.

So there’s an interactive fiction forum, but it’s so heavily censored that you get banned just for saying something that someone might think is "bad" in some ill-defined way. There’s a group on Reddit, but that’s…well, Reddit. It’s the Mos Eisley of the internet. Your other major option is Discord, which might be even worse!

Interactive fiction started in the days before the web. It became popular because of technologies like Usenet, where you were expected to be civil, yes, but you weren’t coddled. To have its gathering places be nothing more than wastelands of diversity, mere online versions of Portland and Detroit, is just sad.

(This isn’t specific to Twine, mind you. The Inform community goes even farther. They not only stand against freedom of speech, but also anonymity.)

Tech is tech

Beneath it all, Twine is nothing more than a very weird SPA framework. Sure, you have to compile the source, but the end result is an HTML page and a bunch of assets. It’s like Svelte in a way, except that (as far as I’m aware) the Twine authors don’t openly support child trafficking and religious persecution. As a developer, I think looking at it as a web framework has helped me better understand how to use it as an authoring tool.

This is where my earlier point about getting rid of the Twine IDE as soon as possible comes back into play. Once you abandon that crutch, you realize just how much freedom you have, with all that entails. For my current story, I’ve added the Pure CSS library to help with some layout issues. On my initial draft of The Anitra Incident, I’d used Moment.js for timekeeping; now, somebody finally made a decent native date system macro that does most of what you’d need in a story.

The output is HTML, meaning that you get to use CSS for styling, Javascript for scripting, and all that good stuff. People have managed to integrate Phaser, a 2D sprite-based game engine, into Twine stories, and I’ve been looking at how they did that. I wouldn’t be surprised if somebody even tried combining Twine with React and a full-stack framework. (Come to think of it, that’s not a bad idea. Okay, maybe not React, but Vue and Nuxt…)

One true format

Twine comes prepackaged with a number of "story formats", which are combinations of style templates and authoring DSLs. I briefly went over them in the previous post on this topic. In short, Chapbook is new, and mostly unused. Snowman is not much more than raw Javascript with a parser.

The other two are the most popular: Harlowe and Sugarcube. Harlowe is the default format in the Twine IDE, so it’s the one most newcomers learn first, but I think that’s a horrible decision. If you want to do anything even remotely complex, you’ll quickly run into the limitations of Harlowe. Far worse, however, is the fact that those limitations are by design. The authors, much like Apple, go out of their way to break any attempt at getting outside their sandbox.

In other words, there’s really no reason not to go straight to Sugarcube and stay there. It works. It’s not difficult to pick up. Most of the libraries out there are for it. (A few are format-agnostic, I’ll admit.) And you won’t be supporting the intentional hobbling of technology.

Conclusion

To sum up, then, what I’ve learned about Twine from using it is that it’s a great tool for what it does. It has some extraneous bits, and these are unfortunately the same bits that newcomers are pushed towards. If you’re willing to take the time to set up your own dev environment, use Sugarcube and a compiler like Tweego, and live with the fact that you’ll get no help from the community beyond "here’s how to make text red" and "here’s how to let your players make up their own words to use as pronouns", you won’t have any problems.

Writing a novel is a lot of work. Writing a program is a lot of work. Trying to do both, which is all interactive fiction really is, can be a monumental undertaking. But it’s fun, too. That’s what I’ve discovered in the past few months.

I’ve always been one to do things just to say I did them. It’s why I became an author, why I ran for office last year, and why I still, despite having failed on multiple occasions, try to create electronic music. (Now I really want to get back into LMMS…)

I’ve also felt that teaching programming is an important goal. Not because I believe everyone should, or even can, become a developer, but because the critical thinking, reasoning, and logical skills necessary to write code are in short supply throughout society these days. If young people learned a little about programming, my thinking goes, that would better prepare them to look at every other part of the world in the same way.

These two desires of mine combine in a few very narrow ways. I’ve tried writing pedagogical programming languages, for example, and I’ve urged those I feel most receptive to try out Scratch, Grasshopper, and other teaching tools.

For the most part, that hasn’t worked. But lately I’ve been getting back into the idea of creating interactive fiction. For those who don’t know, this is a nebulous catch-all term for visual novels, old-school text adventures, and a few other types of games. (For those who disagree with me calling them "games", you’re wrong, because they’re games by any reasonable definition.)

Interactive fiction isn’t so much a genre as it is a medium, but all types have something in common: they use programming to turn simple prose into something a player can interact with. Some work by presenting the user a list of choices. Some, like the older text adventures, are played by typing commands. This isn’t so much a dichotomy as it is a spectrum; "choice-based" games can incorporate a parser. Thanks to the power of programming—every Turing-complete language is equally capable—there are no absolutes.

But there are differences. As I prepare to write, and in some cases rewrite, my first piece of interactive fiction, The Anitra Incident, I’ve studied the tools available, searching for the ones that fit me best, and the ones that work for the needs of the story. In that process, I’ve come to see four of them as standing above the rest, each for a different reason.

Inform 7

Inform 7 is the king of "parser-based" interactive fiction. It continues the tradition of old-fashioned text adventures like Zork, occasionally updating them to work better with modern computing. Programming is done through a natural-like language intended to vaguely resemble English prose. Games are compiled to an antiquated virtual machine and run through an interpreter that can be anything from a web browser to a native app to an executable on an old Amiga floppy disk.

Until last year, I wouldn’t even look at Inform 7 for development, for one very specific reason: it was closed-source. I don’t use closed-source tools for any other part of my development (Python, Vim, Clang, Git, open-source VS Code forks, and every other tool I use, they’re all freely available), so I was happy to finally have the chance to explore Inform when it was released under the Artistic License in 2022.

The good:

• Being mature is a good thing in programming, and resisting the temptation to add faddish things just to keep up with trends is a noble goal. Inform has, as far as possible, perfected the parser style of interaction.
• Inform serves as a de facto introduction to text adventures, so it has a large community, with lots of extensions and examples to draw from.
• Tools like Vorple allow the intentionally limited language to access the rich multimedia features of modern web browsers, which opens up a whole new world of interaction.

The bad:

• The Inform 7 programming language is just different enough from English that you can’t really write it as prose, and it’s peculiar enough in its function that you can’t take it as just another programming language.
• While the primary documentation is vast, it’s also horrible. The developers’ guide, called Writing With Inform, is baroque to the extreme, and it’s written in a stuffy British style that gives me the impression of a Brontë character sneering at the rabble who would dare to write code.
• The community seems to embody that same style, turning their noses up at the perceived limitations of non-parser adventure games.

Overall, Inform 7 isn’t bad. It excels in a very narrow niche: anything that resembles Zork, Colossal Cave Adventure, and old text adventures of that sort. If you want to write something that isn’t based around puzzles, rooms, and the guess-the-verb game of using a text parser, though, you’re going to fight the system every step of the way. And you’ll be doing it without much help.

Twine

Twine is, in many ways, the opposite of Inform 7. It’s been around a long time, but it embraces the open community that comes from having open source. Instead of being based around a parser, it uses the concept of passages, linking between them mostly through player interaction. (That makes it "choice-based", in the parlance of the interactive fiction community. Problem is, "choice-based" is used mostly as a slur, from what I’ve seen.)

For programming, Twine allows a variety of "story formats", which all work around a core set of capabilities. In the default installation, you have four options:

• Chapbook, which I’ve never used
• Harlowe, hobbled by design to the point of uselessness
• Snowman, a too-thin veneer over Javascript
• Sugarcube, an HTML-looking middle ground

I chose Sugarcube because of the way it comes closest to the sweet spot of being powerful and extensible while also providing a decent standard library.

There’s an editor for Twine, but you can also use the Tweego compiler and just write your games in a text editor or IDE, which is what I do. Output is an HTML file plus some ancillary Javascript and CSS, reminiscent of a single page app of the kind you’d make with React or Vue.

The good:

• Twine is easy to get started with. The editor is friendly, and the output looks nice even by default.
• Sugarcube is actually decent, as long as you treat it like any other templating language. Think of it like Jinja, for example. The built-in macros, for the most part, cover what you’re going to need, but making your own isn’t that hard.
• The Twine community is almost as big as Inform’s, and there are a lot of tutorials for getting started.

The bad:

• You’ll quickly outgrow the editor, but setting up a Tweego dev environment isn’t trivial.
• Although the community is big, the differing story formats mean it’s also fractured. So you’ll often find someone asking exactly the question you were going to ask…but they’re using Harlowe, so the answers they get won’t help you.
• As with Inform, the documentation assumes you’re a programming newbie, and there’s little out there for those of us who know how to write code (and prose, for that matter!) but want to know how to write this kind of code.

My overall opinion of Twine is positive. I think it’s the best gateway to interactive fiction for two reasons. One, it’s more accessible than Inform, in both development of the game and playing it. Two, Twine offers more room to grow, at least if you’re using Sugarcube or Snowman.

Ren’Py

Ren’Py describes itself as a "visual novel engine". Visual novels are probably the most popular type of interactive fiction nowadays, especially in the anime fandom. In fact, some big indie games in recent years, like Doki Doki Literature Club, are nothing more than visual novels. Of all the ways, to create this type of game, Ren’Py tends to get the most press, so I’ve taken multiple looks at it over the years.

Programming a Ren’Py novel is done using a Python-based DSL that directly exposes the tropes of the medium. So, for example, you can define characters, and then the game will show them when showing their dialogue. The final result will be a native executable that runs on the platform of your choice, and there’s a web export currently listed as beta.

The good:

• Ren’Py is simple to get started with. The tutorial is actually a complete visual novel, and it has more content than some I’ve seen.
• The engine is geared toward multimedia. You don’t have to worry about "What if the player’s using an old version of mobile Safari?" as with Twine, or Inform’s "What if they want to play on a C64?" You just use your art and assets like you would any "real" game.
• Python is, in my opinion, one of the easiest programming languages out there, so extensibility is not that difficult.

The bad:

• The documentation is horribly lacking. Outside of the basic tutorial, there’s almost nothing official to go on, apart from API docs.
• Ren’Py is very much a visual novel engine, and it shows. If you want to write anything else, you’re going to struggle.
• The English-speaking community isn’t as big as that of Twine and Inform; many, if not most, developers are Japanese, meaning that language barriers are always going to be in the way.

I can’t really recommend Ren’Py for general use, but if you want to make a visual novel, it’s unparalleled. Well, I assume it is. As bad as the documentation is, it’s sometimes hard to tell.

Ink

Ink is the fourth and final option I’ve considered. Calling itself a "narrative scripting language", Ink’s niche is in the Choose Your Own Adventure and "branching narrative" space. In that sense, it can be seen as a very simplified Twine. But it’s also designed to be embedded. Unlike the others on this list, where you’re expected to make a game in them by extended their capabilities, Ink expects you to extend it by putting it in the game you’re making.

That’s a big difference, and it’s why Ink is so hard to classify. On one hand, it can be seen as little more than a dialogue library for games. On the other, it has enough power to create interactive fiction by itself. The Ink compiler offers a web export option, and that qualifies as a game in its own right. The JSON export option, however, is probably the one most games that aren’t intended to be interactive fiction will use.

The good:

• Ink’s syntax is very clean and sparse, so the "I know I can’t code" people have little to worry about.
• The embedding option is the killer feature for non-solo work, because Ink is by far the easiest to integrate with any other game development engine/library/whatever.
• Also unlike the other options on my list, Ink has corporate backing while still being open source. That means there’s always going to be some quality control, if only because the game studios using it will expect it…and pay for it.

The bad:

• Ink is only really good for branching narration and dialogue. That severely limits its niche when using it alone.
• The engine integrations are pushed really hard, but Unity is the officially-blessed one. If you’ve followed Unity news lately, you know that’s a disaster waiting to happen.
• Outside of Ink’s developers, there’s not much of a community.

Of the four options on this list, Ink is the best if you’re working directly with anything else. Want to make a Godot game with some CYOA-style interaction? This is the top choice. But anything more complex isn’t going to be done with Ink alone, and learning an entire game engine, with all that entails, is probably too much for a single dev working on a passion project.

Conclusion

Those are my thoughts on four of the most popular interactive fiction development systems. I have other thoughts on the medium as a whole, but I’ll save them for later.