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:
- You want to write an IF engine because writing an IF engine sounds like fun.
- 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:
- 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.
- Your engine helps IF players because it is easier to play games that have been created with your engine.
- 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.
- 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.