When the 7th Casual Game Design Competition was announced, I had no intention of entering it. While all of the competition entries were supposed to be text adventures (yay!), the competition’s theme was “Escape” (sigh), and authors were encouraged to set the entire game in a single room (boo!). At the time I was in the middle of playing a lot of “Escape the Room” games because Eli demanded them. There was no way I was going to write one of those. What frustrates me most about Escape the Room games is their illogic and their story-less, motivation-less settings. You’re in a room; fiddle with objects until you find the way out. Bleah. No thank you.
Of course, one week later I had an idea compelling enough that I had to use it: what if the player were trapped on a space station, and had to escape or die? This grabbed me for a couple of reasons. One, I’ve never played any IF set in a real space station in zero-g. Two, a broken space station is one of the most inimical settings I can think of. It would help motivate the player, making them really want to escape. Other than by typing QUIT, I mean.
I spent some time considering the likely audience. The heavily-trafficked website running the competition would likely draw in players who weren’t as familiar with IF and its conventions, so I decided to make a small puzzle-centric game. The size limitation would let me polish the game’s interaction as much as possible and give me enough time to implement newcomer-friendly touches like progressive hints. The focus on puzzles would fit with the Escape the Room genre, making the gameplay more familiar to the audience.
So, then: could I write a good interactive fiction Escape the Room game? There’s already been one attempt at parodying the genre, but I didn’t want to take that approach. I wanted to make the genre’s clichés fit naturally within my chosen setting and add more story, motivation and characterization. I started by listing every Escape the Room cliché I could think of. Codes. Combining items to grab out-of-reach objects. Color-coded DVDs or keys or books. Removing screws with screwdrivers. Computer screens or keypads. It became a challenge to fit in as many tropes as possible, both from Escape the Room games and from IF. Amnesia? Sure! Give the player a concussion with a soupçon of both post-traumatic amnesia and retrograde amnesia.
Once I had a list of Escape the Room tropes, I expanded the story. I set the game a few decades from now and settled on a team of astronauts from the UK to further tweak expectations. I knew the story would come through in flashes, slowly spooling out until, by the end, players had all of the pieces of that puzzle. Doing so took advantage of IF’s focus on story and provided a second motivation for playing the game: to figure out what the hell was going on. (I didn’t do this as well as I should have, and I left at least two pieces of the story too implicit to be easily understood. Ah, well; next game, perhaps.)
There are roughly seventy ways to write a text adventure for every one author, though Emily Short has enumerated five approaches. I ended up doing two things that made my life much easier: I graphed out the puzzles and I wrote a complete transcript of the game before I began coding.
The puzzle graph let me see how puzzles linked together and let me tweak dependencies for play balance. Using Lovely Charts I arranged the puzzles and the objects until I was happy with the game’s flow. I knew I wanted the player to be able to work on multiple puzzles at once, so that stuck players could move on to other puzzles. This goes against the usual linear gameplay of Escape the Room games, but I can’t always be a slave to fashion.
Making a transcript first was the best decision I’ve made this year. By writing a transcript, I forced myself to think both as an author and a player. It made it easier for me to anticipate unusual commands and alternate command phrasings that players might use. Instead of writing prose in discrete chunks, coding object after object, I wrote fluidly. I didn’t have to stop writing to think, hey, just how am I going to implement a chain that can be tied at both ends? Overall it made the game far more polished right from the get-go than I was used to. I didn’t hew exactly to the transcript during coding, but it gave me the spine of the game and a lot of usable text.
This level of planning helped me tremendously. Looking at my SVN log, I started coding on December 19th and by January 8th I reached the first beta build. Speaking of SVN, I highly recommend authors use source control. Source control helped me keep track of changes I was making, and at one point let me track down a bug where I had broken previously-working code. I used TortoiseSVN on Windows, though there are plenty of good options. I also placed my SVN repository, the files that keep track of the changes, in a Dropbox-synchronized folder. Dropbox is an online service that synchronizes files among computers that you own and keeps a copy in the cloud. (That sound you hear is Jason Scott grinding his teeth.) Dropbox gave me automated backups not only to Dropbox’s computers but also other computers I had access to. I felt much better knowing that I wasn’t one hard drive crash away from losing all of my work.
Overall, writing Fragile Shells was the smoothest IF-authoring experience I’ve had. I’ll definitely be using a variant on this approach and workflow for my next game.
