Experimenting in IF

Experimenting in IF

When was the last time a piece of interactive fiction blew you away with the fact that it was even possible? What was the last game where you thought, “I can’t believe that was made in _______?”

Parser interactive fiction has a long, if currently stagnant history—something between a tradition and a parlor game—of mangling the standard text-adventure format to recreate Space Invaders or Sokoban or Super Mario Bros.-style platformers. Twine, too, has plenty of experiments, from creating elaborate in-game spy puzzles to glitching out Hugo’s House of Horrors.

But you don’t have to want to make a flashy gimmick to make innovative IF. Nor do you need to be an expert hacker—coding skills certainly help, but are more learnable than you probably think they are. What you do need is a certain level of determination (perfectionism and stubbornness also help), and a desire to break things for fun and innovation. A few tips on how:

Start with a story or game idea, not with a platform.

I have never sat down and thought, “I’m going to make an innovative piece of IF.” Nor have I thought, “Now I’m going to make a Twine,” or “I’m going to try Ink now.” Or rather, I have thought these things—and it went nowhere. It’s like thinking “I’m going to use a stove today” without a recipe: All you do is burn gas.

More subtle, but often more pernicious, is that a platform is only as good as the ideas you bring to it. When you think “I’m going to make a parser game,” you start designing around a platform’s limitations—or probably just what you think are its limitations—and not around an idea. And people respond to ideas, not tools.

So ask yourself: In an ideal world, if you could magically make your finished story appear, what would it do? How would it progress? How would it be structured? This stage is just brainstorming. Some of what you envision might be impossible. Some may not be the greatest way to tell your story. Some of it might get tossed out for scope. But more than you think will be possible, and maybe even easier than you expected.

Figure out how “breakable” your system is.

Of the more common non-commercial IF platforms:

• Some platforms, like Texture or ChoiceScript, are relatively limited. The system does one set of things, and if you want to do those things, that’s great. But if you want to do other things, you’re out of luck.
• Twine is theoretically very customizable with CSS and JavaScript; however, some story formats make this much harder than others. On the easier end of the axis is Snowman, explicitly designed for those familiar with code. On the other end is Harlowe, where it’s possible to incorporate JavaScript (most of Human Errors does), but it requires digging through many files of deliberately undocumented code.
• There is a lot going on in Inform 7 just out of the box, and it’s versatile enough that you can theoretically work in it for years without ever touching some of its features. (I tend to use scenes and text substitutions often.) If something really seems impossible, and you can’t figure out any way around it, you can dip into Inform 6, the more traditional programming language behind the scenes. Finally—and much of this is new—you can add multimedia, tooltips, and even JavaScript code directly within Inform.
• Platforms like Ink and Undum, being open source, are as customizable as you have spare time and desire to disembowel someone else’s code.

Don’t reinvent the wheel.

Your ideas, of course, can be anything you can imagine. But the mechanics to implement those ideas are often fairly simple: tracking a few variables, triggering a few lines of code. Even something as simple as tweaking the default CSS can make your story appear far more innovative than it would otherwise.

Remember, you’re not tinkering for tinkering’s sake—you’re doing it to get your story to work the way you want it to work. And chances are, someone else has also wanted their story to work that way. If you want a certain text effect, is there a macro or an extension to do that for you? If you want to track how often a reader interacts with a particular passage, or has “seen” a piece of text, or has moused over something, JavaScript examples abound.

Often, you can just look directly at what others have done. CSS code on websites can be viewed via most browsers’ Inspect Element feature, Twine stories can be loaded into the online editor, and many parser games have their source code available. Obviously, the idea here is not to plagiarize others’ work. But it can help you see that a lot more is possible than you may have thought.

Test even more thoroughly than the thorough testing you were already planning.

The more you experiment, the more you delve into things your system might not be designed to handle. Plan for this. Sometimes this can mean adding fail-safes—if you’re tinkering with a passage manually via code, are you loading the right thing? If your game has a finite amount of text, is it possible to run out, and have you provided a buffer of extra text and/or a way to generate more?

Do extra testing on your custom mechanics, of course, but also test the story as a whole, thoroughly. When you break one thing, other things tend to break as well. (An example: Inform 7 executes an unexpectedly huge number of rules when processing commands. Any one of those rules can be the thing that, purely hypothetically, makes your story crash instead of ending.) It’s a bit of extra work, but you’ll never know when it might be worth it.