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.