Let's get started.
Experimenting in IF
2019-06-12 · by Katherine Morayati
tagged Blog / Non-Fiction
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.
- 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.
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.