• Tweet

• Tweet

Continuing our series on interactive fiction, and tips from the masters, this week we have some advice from Sarah Morayati.

Sarah Morayati

Sarah has written several pieces of IF, including Broken Legs, which came second in the 2009 IF Comp. She also collaborated on Alabaster, which won the awards for best writing, and best individual NPC at the XYZZY Awards the same year. She has also contributed an extension to Inform 7. Her official website can be found here.

1. What software do you use to write your IF, and why?

   Sarah: I use the Windows IDE for Inform 7. It’s really quite simple — I prefer Inform to TADS, and assembling an Inform 6 game is, well, its own thing. I’m sure the technology has advanced since I last used it (well, advanced in a way other than Inform 7), but here’s my old I6 coding process: load up a Notepad file with my source code, open a DOS window, code a bit, switch windows, type in the compiling command, switch windows, fix the inevitable bugs, switch windows, repeat until there are no more bugs, repeat everything else. It’s kind of retro-cool using DOS these days, and it’s undeniably cool to see the file containing your story spring up, but all that coolness wears off fast.

   Besides, the I7 IDE has a lot of excellent features — color-coded source text, quick options to compile, replay and release, a manual built in, lists of verbs, etc. I should also mention the skein — I don’t use it much personally, but a lot of people really love it.

2. What’s the first thing you do when starting a new piece of IF?

   Sarah: Apologies for the wonkery, but I copy-and-paste some code. I’m not being flip. There are a few sentences (again, I’m talking Inform 7) that you’ll want to at least consider at the start, before you forget:

   – “Use no scoring.” IF is trending toward works that don’t keep score. Personally, I don’t have much use for scoring, and I’d venture to say that a lot of people interested in the literary potential of IF don’t have much use for it either. But if you don’t explicitly turn scoring off, readers can still call up their non-score with >FULL or >SCORE. It’s irrelevant, and it will confuse them. Best to leave it out.

   – “Use full-length room descriptions.” This requires some explanation. There are three “story modes” in Inform: verbose, which always prints a full description for every room; brief, which prints a full description the first time and only the room name on subsequent visits; and superbrief, which only prints a full description if you explicitly type >LOOK. I prefer verbose mode. Descriptions help me get my bearings, and more importantly, a well-written description evokes all sorts of moods and images that a room name alone cannot. Room descriptions can also change, producing an effect far more striking if you’re familiar with the original text. This piece of code sets the story mode to verbose by default, and I never leave it out.

   – “Rule for deciding whether all includes scenery: it does not.” and “Rule for deciding whether all includes people: it does not.” This is to make >GET ALL less jarring. Normally, this command will try to take literally everything in the room, including anything you’ve defined as scenery (read: lots of unimportant things), not to mention your NPCs. Some people disable GET ALL entirely, but I don’t think you need to go quite that far. These statements are good enough.

   – “The describe what’s on scenery supporters in room descriptions rule is not listed in any rulebook.” This one can be a lifesaver. If you have a supporter (an object that can hold something, such as a shelf or a chair) described as scenery, the story will write another paragraph to say what’s on that object — a paragraph that’s almost always useless from a writing standpoint. You don’t need it. Even the Inform 7 documentation suggests that you add this code. They know.

3. How do you decide that a piece of fiction should be interactive, rather than a traditional story?

   Sarah: A couple things, mostly skill. Some things are just difficult to code. Conversations, for instance, or complex simulations (the classic examples are ropes, fire and water.) Many of these, mind you, are highly rewarding once you crack the code, and readers find them very impressive. But some just aren’t worth the effort and are better treated in static fiction. The key question to ask is: does writing this as IF add anything to the story? If not, it doesn’t mean you can’t try it, but it likely means you should find a way to make writing your story as IF worthwhile.

   I’d be remiss, too, not to mention audience. Right now, a work of IF is primarily going to reach a niche audience, likely one with a less traditionally literary background. This is changing, and it’s changing fast, but it’s still true right now. I don’t say this as a warning; it’s just something to keep in mind.

4. IF takes the practically unique second person perspective. With the reader essentially playing a character, do you expect your readers to roleplay, or do you prefer to give them as blank a canvas as possible?

   Sarah: I never much liked “blank canvas” stories. If we assume the PC is a character, would you make any other character a blank slate? Not if you want the reader to care.

   There’s a lot of discussion on this subject, but the stance I take is that IF makes you a tourist in someone else’s mind. Any text you read will be from that character, whether directly or through free indirect discourse. Done right, this can be fantastic — see Stephen Bond’s Rameses, for instance. Second-person is a barrier, yes, but it isn’t insurmountable. It isn’t even insurmountable in static fiction — the canonical example is Bright Lights, Big City by Jay Mcinerney, but there are others. And true, some of these novels and stories and IF works are utter failures. Some aren’t. Yours could be the latter.

   You don’t even have to use second person anyway. It’s a convention, not a rule. There are ways to change tense, and they’re all much easier than slogging through a story written the way you don’t want it.

5. There are so many items, rooms, and interactions that an author could put in the story and so many descriptions that could go with them. Where do you draw the line?

   Sarah: In general, over-implementation — what some call making stories “juicy,” is better than under-implementation. The surest sign of an amateur isn’t too much writing, it’s too little — important scenery objects going unimplemented, or items getting one lousy sentence of non-description. Don’t despair, though — this usually doesn’t happen when the author’s trying. It happens when the author isn’t.

   There is a line, though, and it’s sometimes hard to spot at first. A piece of advice floating around from Adam Cadre that should help shed some light on this: any text your story displays is essentially a reward for the player typing in a command, so every piece of text has to be worth reading. Your responses can be funny, they could give clues, they could further characterization. What they cannot do is be cursory. When you get to the point, then, where you’re just writing stuff down because you have to, rewrite or rethink. If you’re bored by your writing, everyone else will be bored too.

6. There is potential for a tangled web of intersecting paths through a story. How do you keep track of everything?

   Sarah: This is what people call the ““combinatorial explosion” problem: the more things you’ve got bouncing around at once, the more likely it is that they’ll crash into each other and explode. So corral them if you can. For Broken Legs, I cheated a bit. (Mild spoilers ahead, but nothing catastrophic.) Every turning-point in the story is binary. Alexandra either fails or passes her audition, so at each juncture, there are only two possibilities. Well, OK, that’s not entirely true — at a certain point in the late game, there are about three — but two and three are still very different numbers than 20 and 30. Perhaps real auditions are more nuanced and actually do require 20 to 30 factors, but I wasn’t about to simulate all of that in a year. I cheated in other ways: the puzzles are sequential, so you shouldn’t run into a situation where Alexandra passed but Rosanna failed, and more importantly, I wouldn’t need to write and code that scenario.

   I’ve called this cheating, but I’d like to call it strategy too. Simpler is usually better. In general, simplify as much as you can while still achieving the effect you want. As long as there’s a plausible story-related reason for your simplification — characterization, perhaps, or plot — and you’re not just chopping off paths arbitrarily, you’ll be fine. After all, you don’t have to release your source code, and even if you do, vanishingly few people — few readers, at least, will judge you on it. What readers judge you on is the story you write. Simplicity is still impressive.

7. How do you go about testing your work?

   Sarah: Thankfully, there are no shortage of testers in the IF community. As you write and test more stories, you’ll build up a group of testers you can trust. Before that, though, you can get started by posting on intfiction.org or gametesting.org. If that doesn’t give you enough responses, you can try asking (politely!) people you know in the community. The more testers, the better; you’ll find that some people agree to test your story but quickly vanish from the face of the earth.

   Don’t think, either, that one round of testing is enough. For Broken Legs, I did about four, and other stories have had even more. Even the best testers won’t catch everything the first time around, and more pertinently, sometimes what you thought fixed things in fact completely broke them. One of my intermediate releases was unwinnable (that is, literally unwinnable, not “this is too hard” unwinnable) because of something I changed. Again, keep deadlines in mind, but the more the better.

8. What’s the most valuable mistake you have made writing Interactive fiction?

   Sarah: Writing a horrible first story. There’s no better way to learn a language, whether it’s Inform, TADS or anything else, than by diving in, but you’re going to end up wasting a few weeks or months on something terrible and unreleasable. Mine was a museum crawl that turned into a cave crawl and then back into a museum crawl somehow, with a bloodless conspiracy backstory thrown in because I thought it would add depth. It never saw the light of day. But that’s all right. The effort I poured into learning the code is effort I could then put toward crafting a better story. As cliched as it sounds, it was a learning experience.

   Now that I’ve said all that, forget it all. Delve into code the first time thinking you’re going to turn out something great. You won’t learn if you don’t think, at least at first, that your concept is the greatest story ever. And who knows? Maybe it will be.

9. If there was only one single tip you could give a new IF writer, what would it be?

   Sarah: Read. Read everything. This goes for interactive fiction as well as traditional fiction, nonfiction, etc. And don’t just stop at reading. Watch good movies, listen to good music, fill your brain with ideas and let them bounce and clatter against each other. You’ll be a better writer for it, not to mention a better person.

Further Reading