When to Write Your Own Interactive Fiction Engine

Many experienced programmers start down the homebrew engine path because they want to make IF games. (Which is wonderful! Hooray for interactive fiction!)

But if you want to make a first-person shooter, it’s not necessary to start by rolling your own 3D renderer. And if you want to make an interactive fiction game, ┬áthen it’s not necessary to roll your own engine from scratch.

There are two basic reasons to write your own IF engine:

  1. You want to write an IF engine because writing an IF engine sounds like fun.
  2. You want to write an IF engine because you see an opportunity to improve upon existing IF authoring tools.

Reason 1 should always be true. If you don’t want to write an IF engine, then you shouldn’t write an IF engine (with rare exceptions, like a class assignment). And for many people, that will be enough. But if you want your engine to be used by other people, then it’s worth digging deeper into that second reason.

Many successful engines already exist

If you want to write a new IF engine, take a hard look at the competition.

From the 1990s until early 2006, a variety of IF parser engines jostled for popularity. Inform 6 and TADS 2 were most popular, but systems like Hugo, Alan, and ADRIFT were also commonly used. But in 2006, Inform 7 revolutionized parser game creation with its natural language approach to IF (in which sentences such as “The Mortuary is a room” and “An ornate vase is a container in the Mortuary” are valid code) and became the most popular parser engine. Quest also appeared in 2006 and has attracted a swarm of authors thanks to its novice-friendly visual scripting interface.

If your interests are choice-based, the competition doesn’t get any easier. Twine is the easiest game engine to learn (IF or otherwise) and perhaps the most popular IF engine in use right now. ChoiceScript is the go-to for interactive novels that are pure text. Ren’Py is a powerful and popular engine for creating visual novels. All of these systems are supported by thriving communities and extensive documentation.

If you have an idea for something that doesn’t operate on a standard parser or choice-based model, then you’re in less competitive territory. But there are still a number of successful systems here, such as Texture, which uses a drag-and-drop interface to connect verbs and words, or StoryNexus, which allows authors to build games in the style of Fallen London. There’s also Seltani, which is a multiplayer choice-based/chat room IF system. (Seltani is the canonical example of risk in unusual IF engines. On the one hand, it’s unique and fascinating, but on the other, very few stories have been created in Seltani due to insufficient author interest.)

For more notes on some existing engines and their various strengths, see Emily Short’s article “Writing IF”.

For a much more comprehensive list of IF engines, see Another Interactive Fiction Engine List.

Your engine needs to offer something different

Why would someone use your IF engine in preference over every other engine out there?

If you want your tool to be adopted by other interactive fiction authors, then it needs one or more of the following characteristics:

  1. Your engine helps IF authors because it is easier to make games using your engine.

This is where Inform 7 and Twine excel. I7 attracts authors because of its natural language approach and its excellent IDE (interactive development environment). Twine provides visual scripting and the fastest zero-to-game experience for authors without previous programming experience. Both of them are backed by extensive documentation and have massive communities willing to help new developers.

But every popular engine has specific strengths that appeal to various authors. To name a few examples, Quest provides a visual scripting approach for parser games; Texture’s mobile-friendly interface caters to devs who are writing games on the go; and some people prefer TADS 2 or TADS 3 over Inform 7 because TADS behaves far more like traditional programming than I7 does.

  1. Your engine helps IF players because it is easier to play games that have been created with your engine.

How could one engine’s games be easier to play than another’s? For years, the ability to play IF in a browser was a killer feature that provided strong incentive to write games on that platform. These days, most IF games provide some kind of browser support, such as Parchment for Z-code (the Infocom file format, which several IF engines use) or the native HTML/Javascript format of Twine, but there are other ways to make games easier for players. Accessibility is an ongoing concern that affects many people, as noted in this intfiction.org post about how various IF systems interact with screen readers (from 2013, so some information may be outdated, but improving accessibility remains a concern.) And I personally would like to see more parser engines with automatic abbreviation support (e.g., “luxe” rather than “Luxembourg”).

  1. Your engine offers features that are unusual or unique.

By their nature, any of the hybrid parser/choice engines have unusual features. But there are other kinds of features that a new engine might offer. For example, Ren’Py has extremely good support for images, sound, and animation because Ren’Py is primarily used to create visual novels. On the other hand, Unity developers are likely to use ink or Fungus because they are choice-based IF systems with Unity plugins. If there’s something you want to do in a game that no existing system can provide, it falls into this category, too. For example, The Ice-Bound Concordance is one of the coolest IF games that I’ve ever seen, and it couldn’t have been created in any existing system.

  1. Your engine offers realistic commercial opportunities for IF authors.

Writing IF is time-consuming, and it’s not a good way to pay the rent, so authors are automatically interested in IF engines that offer a realistic way to get paid for their work. Right now, ChoiceScript is the most viable system for IF authors hoping for a reliable paycheck, as the associated Choice of Games company has an established audience and will pay royalties on interactive novels written in ChoiceScript. (StoryNexus and Varytale were two other systems along similar lines, but the first no longer offers commercial payouts to participating authors and the second shut down before leaving beta.)

Successful commercial games have also been created with Ren’Py, Twine, and Inform 7, but publishing alone involves far more than just creating a game, since it also requires dealing with marketing, PR, social media, platform submissions, and so on. When a corporate-owned IF engine includes marketing support, an existing audience, and a track record of success, it will be extremely attractive to authors.

Every successful engine started as someone’s homebrew project

Homebrew engines have a shaky reputation because many homebrew engines offer experiences that aren’t as robust and reliable as those offered by established systems. Or, to put it another way, it’s easy to get excited about reinventing the wheel, but unfortunately many people forget that the final product should be round.

But all “homebrew” means is “an engine you made yourself that other people aren’t using”. When Graham Nelson wrote Inform 6 and then Inform 7, it wasn’t because someone came down and anointed him the Parser Poobah. When Chris Klimas created Twine, it wasn’t because he’d been hit with a bolt of lightning. They’re just designers and programmers who had great ideas and executed on them effectively.

If you have a great idea, and you’re a designer and programmer (or can build a team that includes them), then don’t let the existing landscape disappoint you. Digital interactive fiction is a very young medium, and you might have the seed for the next groundbreaking new technology. Take your idea seriously, execute on it effectively, playtest a lot, and you might change the landscape too.

But if what you really want is to make a traditional IF game, then the tools already exist. Don’t put yourself through reinventing the wheel if you just need something that rolls.

Bookmark the permalink.


  1. What a timely post as I was just doing this myself!

    The reason I have been writing my own is because I want to be able run it as a webpage, but have all players stats and info saved to a central database so that stats can be shown a bit like in tell tale games. You made this choice and 20% of other players did as well.

    Do you know if there are any engines out there that would provide this functionality out of the box – I have no desire to create one from scratch if I don’t have to!

    • Good question! No, to my knowledge, there is no engine that offers this functionality out of the box. Most interactive fiction engines produce standalone files (browser-playable or otherwise) with no expectation of server-side support. It would be nice to see one that did.

      I’ve dabbled in the share-your-data space myself (see: This Is A Real Thing That Happened, written in Inform 7) but only thanks to Dani Church supporting me with Javascript and a server.

    • Conceptually, you could use Inform 7 + Quixe (and soon fyrevm-web) to do this with the caveat that you’d still need to build the backend DB and API processing. Once I have fyrevm-web running as a UI templating system, the plan is to implement a sort of WordPress for I7 stories…and this would include a standard API for storing data from game play. But that’s months away if not a year+.

    • This article applies to me too, as I am building a custom HTML-based engine (the Elm Narrative Engine). It has a unique approach to authoring and playing stories, but perhaps the most powerful feature it offers is that it is extremely flexible. The logic, content, and view are fully decoupled, so while it does not support what you want “out of the box”, it is very easy to embed the engine into your own “wrapper app” that adds the stat syncing. You would still need the backend and api, but you wouldn’t have to worry about any of the IF functionality.

      Take a look and see what you think: http://elmnarrativeengine.com. I am actively working on v3.0.0 which has some huge updates, including a visual editor and debugger. Since the engine is new and your feature idea sounds like a useful plugin that others may want, I’d be happy to work with you to set up a proof of concept if you are interested.

      • I’m rather impressed with this. Even with the simple demo story, the interface is very clear, and gives a good impression of progression through the story. I’ll look forward to seeing more when a fuller story is implemented!

Leave a Reply

Your email address will not be published. Required fields are marked *