Here is the revelation I’m sharing today:
You didn’t start testing early enough. If you think you did, you’re not testing the right things.
I don’t mean just implementation and technical issues, although the statement is true enough for that as well. You really can never have enough time to root out obscure bugs and corner-case responses, un- or poorly-implemented items, and so forth. But even if you managed do do a perfect job at that, there’s a whole other component to your interactive fiction work. Are you testing that other component?
Your interactive fiction game is, as the quote from Graham Nelson goes, a crossword at war with a narrative. Discussions of testing usually center on fixing programming bugs, which all fall on the crossword side. Sometimes there’s discussion of “polish”, which is generally understood to mean cleaning up grammatical errors, misspelled words, and awkward phrasing. That’s more on the narrative side, granted, but it’s not heavy lifting by any means. If your underlying story has flaws, that kind of “polish” is on the order of rearranging the deck chairs on the Titanic.
So let’s say you’ve been writing a game for the past six months to a year. You’ve built some cool technical features, crafted some intricately-coded puzzles, and written a lot of room descriptions, response messages, and NPC actions and dialogue. The Comp is coming up, and you have a month left to go. You’re close to feature-complete and the game is winnable, so you package up a beta version and send it out to some willing or coercible testers.
The transcripts start coming back, and the game has quite a few bugs. More than you expected, really, but although some of them look pretty bad and have significant in-game effects, when you drill into them you find they’re not that hard to fix. Your construction is basically sound, and it looks as if you have plenty of time to root out the remaining problems and lacunae in implementation.
And then a transcript comes back from someone who knows how to write and how to critique writing. She isn’t concerned with the bugs she’s running into, but she thinks your scenes are unfocused, your main character’s personality is unclear, his backstory is ambiguous if not self-contradictory, and that the pacing of the action is too slow.
Wait a second, is that legitimate for a beta tester to report? Aren’t they supposed to just find bugs?
Actually, she’s worth her weight in computronium. She is finding bugs. The problem is that they’re bugs in your writing, and by the time you’ve written months worth of text in your story, it can be daunting to go back and make the kind of fundamental changes that a poorly-chosen authorial voice might require. Even correcting pacing and plot issues can be major undertakings, as they might require structural changes to your story that have serious technical repercussions.
Others have addressed this, most recently Aaron Reed in his new book Creating Interactive Fiction with Inform 7. What he advocates there, and what the methodology Emily Short calls the “transcript fully, then implement” approach facilitates, is to get feedback on your story and writing early on, almost from the beginning of your project. By doing this, you can get a better feel for how your story is going to come together without having to start major textual surgery one month out from your release date.
It’s not rocket science — this is something that print authors have known about forever — but it may not come naturally to authors arriving at interactive fiction from the programming side. Even though code review and beta testing are fundamentals of software development, programmers don’t always think of collaboration in the context of writing. In the non-interactive sphere, writing critique groups and authors’ circles are very common, both in the real world and online.
My testing experiences this year have certainly woken me up to the value of early feedback on story issues and writing quality — you can’t make a truly great interactive fiction without competent execution on both sides of the Fundamental Divide. I think all IF authors, but particularly new ones with a great idea and lots of enthusiasm who want to enter their first Comp, should keep this in mind and take both time and pride in polishing their narratives as much as they do in burnishing their crosswords.
