At last year’s Oklahoma Video Game Expo (OVGE), I officially debuted my first full-length text adventure. Hangar 22, written in Inform 6, was a light-hearted text-based work of interactive fiction that involved aliens, tacos, and a talking GPS that sounded like Sir Mix-A-Lot.
Over the past 30 years lots of people have written lots of great (and lots of not-so-great) text adventures and works of interactive fiction, so completing one does not make me an expert or authority on the matter. I did, however, jot down a few notes about writing text adventures as I was working on the game. I know it’s been awhile since I released Hangar 22, but I decided to go ahead and compile those thoughts into a single post and cast them out onto the Internet anyway.
So here they are.
Three Phrases.
For me, I found that creating a work of Interactive Fiction involved three unique phases, each of which requires unique skills. There’s the “game design” phase, a decidedly right-brained phase of the process during which characters, adventures, puzzles and solutions and dreamed up. The second phase, “programming,” is an almost entirely left-brained function. Once the story makes sense and the programming is “done” (har har) you move to the “testing” phase, which requires not only making both literary and programming corrections, but dealing with other people as well. They say one of the reasons it’s difficult to edit your own writing is because it’s difficult to quickly flip between left-brain and right-brain functions. When creating a text adventure, especially during the later phases, I found myself doing it repeatedly until I was mentally exhausted.
Creating Worlds
When Leonardo Da Vinci painted “The Last Supper” he didn’t have to worry about who prepared the food. He didn’t have to worry about what anyone standing outside on the street was doing, what outside sounds could be heard from inside the room, how the food smelled or whether or not the bread was stale. And yet, these are the types of things that Interactive Fiction authors continually have to deal with in every game they write.
Text Adventures take place in virtual worlds that, assuming some connection to reality exists, must adhere to common universal rules. For example, in Hangar 22 I created a mailbox outside the protagonist’s home for no other reason than the fact that most homes have mailboxes outside them. But there’s more to it than that; to make the mailbox seem “real” I had to program it to open and close. Then, I had to add logic rules to prevent things larger than the mailbox (including the player) from entering the mailbox (because, as I found out, your beta testers will try such things). I suspect I could have spent weeks detailing the parts of the mailbox down to the screws holding it together, a level of obsessive madness comparable to detailing in paint the wood grain pattern on the underside of the chair Jesus sat in during The Last Supper. The virtual world I created in Hangar 22 is little more than a caricature of reality that’s not too terribly difficult to break. I believe, if you really wanted to, that you could gather every single carryable item in Hangar 22 and stuff them all into the mailbox. At some point though, I (as a programmer) had to draw the line between just how much detail and realism to build into things in my virtual world that really didn’t matter.
Playing God for a bunch of Demons
If you’ve ever uttered the phrase “That’s why we can’t have nice things,” you know what it feels like to have your text adventure beta tested. Trying to guess what testers and players alike will (and won’t) try can become the ultimate game of cat and mouse. In the first beta release of my game, someone carried the front door off my house, ate the alien they were supposed to be rescuing, and parked their virtual El Camino in the aforementioned mailbox. And that’s why we can’t have nice things.
The more objects that go into a game, the more ways there are for those objects to interact with one another. Put a knife in your game and you can expect at least one player will just become Stabby McStabStab and go around attempting to slash everything in sight. Drop a book of matches into a game you’ll have to come up with a laundry list of excuses as to why the player shouldn’t go around burning down your entire virtual landscape. This can be handled directly (“The cat is not flammable.”) or through suggestion (“You decide against burning that.”), but when you don’t want the player to do something that makes sense (burning a piece of paper, or starting a fire in a fireplace, for example), you had better come up with a damn good reason as to why you won’t let a player do such a thing.
Balance and Fairness
Before writing a book, authors must consider their target audience. Obviously, a mystery novel intended for small children would be written differently than one written for adults. As I began writing Hangar 22 I realized that I didn’t have a target audience in mind. Ultimately I decided to make my game for beginner players. Not only did I build in a custom hint and cheat section, but I also “led” players by the hand through most of the game. Before killing players, I warned them. If an item wasn’t important, I told them so. I’m sure most advanced players would/will find my game silly and simple to breeze through. But even with that being said, I think it was important to pick a demographic and stick with it.
I also made a conscious point to make sure all the puzzles in my game were fair. At one point in Hangar 22 you cannot advance unless you look like an astronaut. The game will even eventually nudge you, letting you know that astronauts typically have space suits, gloves, and helmets. Each of those items is obtained in a different manner: one has to be found, one is obtained by solving a puzzle, and one requires a creative substitution. None of them are particularly difficult to obtain, and (again, considering my target audience) my goal wasn’t to stump players for any length of time. There are plenty of games out there that will stump you for hours or days or weeks; while playing through my game, I wanted players to, upon encountering a new puzzle, slap their foreheads and say, “Oh, *I* get it!” I’m not saying that’s the right way to design a game; I’m just saying that’s how I made mine.
Would I Do It Again?
I’ve been asked by several people, “are you planning on writing another text adventure?” The truth of the matter is, I don’t know.
Between beta testers, fellow forum members, and friends, I’d guess the number of people who played Hangar 22 was well under 50. Probably well under.
I’ve always been the type of person that lives off of feedback from my work, whether it’s my website, my podcast, my books, or whatever. I greatly enjoyed the feedback I received from the dozen or so people who helped me test the game, but after that, the feedback stopped.
The one exception to this was a very awesome transcript posted by ClubFloyd, who played my game as a group and posted the transcript online. This was by far the coolest thing to come out of me releasing Hangar 22. Even if you have no interest in playing my game, you can go through it by reading their transcript. Throughout it you can see the players did what I wanted them to, went where they were supposed to, and laughed where they were supposed to.
I started work on another text adventure, but my interest began to wane mostly because the game itself wasn’t funny and didn’t really lend itself to humorous writing. Based solely on the ClubFloyd transcript, I might write a sequel to Hangar 22 someday, but … it’s just a lot of work for something that only a few people will ever see. About once a week I get e-mail from someone who has just read Commodork, a book I released in 2006 and that people are still buying and reading. I doubt that five years from now, I will be receiving feedback regarding Hangar 22.
If it weren’t for that ClubFloyd transcript and the feedback and support I got from Ice Cream Jonsey and Roody Yogurt, I’m pretty sure my answer would be no. Right now though I’ll go with a definite maybe, if the right plot idea popped into my head.
