Splashdown - Post Mortem

by Paul J. Furio

Splashdown was my first completed work of Interactive Fiction, and my first entry into the Interactive Fiction Competition, an annual competition for authors of this largely non-commercial genre of computer game entertainment.

As a child, I had played the works of Infocom, starting with Planetfall on my Commodore 64. I fondly remember attempting to create my own text adventures in BASIC, with absolutely no knowledge of basic programming methods or data structures. In college, I had discovered Graham Nelson's Inform package, and had created a few small test games, but nothing substantial was ever completed.

It wasn't until years after graduation, when I had become a professional game developer at Amaze Entertainment in Kirkland Washington, that I purchased two copies of the printed and bound Inform Designers Manual, fourth edition, and my interest in creating my own interactive fiction adventure took off once more.

By the end of 2003, I had resolved to enter the next years IFComp, and while deeply entrenched in the development of an XBox game at Microsoft, I began to consider a plan of action. After seven months of spare-time development, play testing, redesign, and bug fixing, Splashdown was complete, and was submitted to the competition.


What Went Right

1. Achievable Goals

My three main goals were to create a game that was fun for me to play personally, fit the "feel and style" of an Infocom game, and would place in the top 10 of the Competition.The first was fairly simple, since I knew best what kinds of games I enjoyed, so it would be simple to satisfy myself.The best games, in my opinion, were playable by anyone of any age who had some basic knowledge of science, literature, and history, which ruled out adult-themed games and deeply intellectual political allegories.I aimed for a puzzle heavy game with a simple, straightforward plot, and some clever humor.Luckily, this matched the second requirement well, since many of Infocom’s classic games were puzzle-fests that were also filled with clever humor.

Placement within the top ten was the more difficult challenge, and it was obvious that I wouldn’t know if I had succeeded until the end of the competition.However, by aiming for a reasonable level of polish and a concise game, based on previous years entries, I felt I could outmatch about 60-70% of the competition.

2. "Feelie" Documentation

Infocom was famous for the extras that shipped with their games, currently known as "feelies." These ranged from Wizards Supply Catalogs to glow-in-the-dark Magic Stones, and besides enhancing the notion that the game existed outside the realm of the computer, they often contained clues or hints as to how to win the game.They also set the mood for the title, whether serious or humorous, and served as an excellent lead-in while the player booted up for the first time.

Several of the reviewers commented favorably on the documentation, which consisted of a title page, a travel brochure for an interstellar colonization company, an instruction manual (copied from the public domain "A Beginner's Guide to Playing Interactive Fiction"), and a sample walkthrough. As the format of this document mirrored Infocom’s own, it provided a reference point for the game.It also was a fairly straightforward and easy to produce addition to the game with a high "bang for the buck" payoff. After a day of photo editing and typing, it only required minor proofreading before being complete.

3. The Right Scale

The Competition rules state that each reviewer must score a game after playing it for no more than two hours, thus I knew I had to design a fairly tight game that could be completed within the time limit.This meant limiting the number of rooms and puzzles to something reasonable.

Following the advice in the Structure section of Graham Nelson’s The Craft Of Adventure, I planned a reasonably linear game beginning with only five rooms in a topographically straight layout (each room only lead to two others, with no loops). This lead to a wide "middle game", where most of the puzzles were located, with 18 rooms located on only three different floors, with a central hub room on each level, and simple cardinal directions between each room.

As for the middle game, there were only four genuinely difficult puzzles, and a handful of simple ones of the "get x, use x" variety. With only one red herring item in the whole game (the oxygen mask), the main challenges consisted of understanding and operating the computer, getting to and activating the generator, filling the ballast tanks, and launching a working beacon. The end game relied on the fact that the player had been keeping a good map, and featured several different endings depending on how well the player had performed.

Originally, the design called for a morality play where the player and his robotic sidekick, Spider, would have to decide which one of them would surface with the colonists and which one would stay behind on the flooding ship. Midway through development, I realized that coding up the extra paths to make these choices work would be more difficult than I had originally assumed. I also could not think of a reasonable way to direct the player to do "the right thing" when separated from Spider, in order to avoid wandering randomly around the ship when faced with this decision. Finally, I wasn’t confident that I could make Spider a sympathetic enough character that the player would want to sacrifice his own life to save a robot (even though the sacrifice would be rewarded), so this part of the story was cut. In hindsight, I think streamlining the game in this manner only improved the game play.

4. Using Inform and IF-IDE

Since I already had experience with Inform, and knew I wanted Splashdown to be as close in feel to an Infocom game as possible, it seemed only natural to use Graham Nelson’s programming language and compiler to create my entry. I wasn’t interested in rolling my own parser or basic state machines from scratch. Years of professional software development taught me to reuse existing code where possible. I also didn’t see the need for graphics or sound, as would be provided by Gluxe or HTMLTads, so Inform was perfect for a text-only adventure.

At one point, I had used Microsoft’s Visual Studio environment to program Inform, but the keyword color coding was not designed for Inform files, and it seemed like too much of a hassle to modify Visual Studio to work in this context. It was with pleasure, then, that I found IF-IDE, developed by Michael Perlini. This development environment allowed me to work quickly and easily with my code base, and was enough like Visual Studio that I immediately knew my way around.

By using Inform and IF-IDE, I could focus on what made Splashdown a game, and not worry as much about low level bugs, or systems programming.

5. Getting a "Grammar Freak" as a Play Tester

My main play tester, Anna, works at the Seattle Times online division, and her dream job is to become a copy editor. Thus, I was delighted when in addition to throwing genuine game play bugs my way, she helped me track down a slew of grammatical and spelling errors in the game. When trying to code up a working state machine, I didn’t always notice that I had spelled "maintenance" wrong in several places.

Even though the game went into the competition with several typos, it was vastly improved over its July Alpha release, and I feel that Anna’s work was largely to thank for these fixes. I know I’ll be bringing her on to play test any future games I might make.


What Went Wrong

1. Inadequate Play Testing

As useful and thorough as Anna was, she was nearly the only play tester that I had. By May, I had enlisted roughly half a dozen friends and acquaintances who agreed to play test Splashdown. Most of the conversations went like this: "You’re writing a text adventure?! Dude, I loved Zork, I’ll totally test it for you!" Of course, when they actually received a beta of the game, it sat, unplayed, and my email requests for bugs went ignored by most testers, only two of which actually submitted bug lists. Even attempts at bribery, in the form of Starbucks Gift Certificates, were useless in motivating results.

To be fair, many of these people had day jobs, and several of them were professional software testers, so to ask them to test software in their spare time perhaps was too much. Still, they shouldn’t have signed on if they weren’t going to actually play test the game, or they should have had the courtesy to decline later on when they knew they would be too busy.

In hindsight, I should have utilized the play testing resources of the IF newsgroups. Originally, I did not want to spoil my potential pool of judges, but I realize that a handful of testers would not have detracted from the voting populace in any great numbers, and that they would be more experienced in testing this type of game, as well as finding all the obscure bugs that IF gamers know to look for.

I also should have used the Inform option to output the printable text in the game, and handed that off to Anna to proofread all at once, but this is a minor point easily corrected for the next title.

2. Not Enough Polish

The lack of testing lead to a lack of polish in the game. From my professional experience, I know how important polish is to making a title feel finished, and I attempted to add as much as I could. However, with the time limit pressing on, and show stopping bugs to fix, the efforts spent polishing the game diminished greatly.

Much of the polish was added at the beginning of the game, as experiments in coding. The names on the cryotubes, for example, were actually part of a Parse_Name() function, which read the names out of an array of strings. While efficient, I didn’t code this routine well enough to allow for the use of the name ‘tube’ or ‘tubes’ in addition to ‘cryotube’, which bothered several players.

In another instance, the pebbles outside the ship were an implemented scenery object, but the scraps and debris in the Aft Catwalk were not. Since the player visits the Aft Catwalk very early in the game, they should have received more attention, but they didn’t because the outside of the ship was coded early in the process.

Various other verb and noun problems cropped up, all of which I felt would have been addressed by more thorough play testing.

3. The Computer

With over 700 lines of code alone just to handle this object, it was perhaps the most complicated item in the game. It seemed natural to have a main computer that ran the ship, and a voice activated system seemed the most straightforward method of interaction, since players would not have to keep track of switches, knobs, or buttons.

However, I think my background in software development clouded my view of how most people interact with computers. Firstly, the notion of a priority queue for the power management was confusing to my play testers, and seemed confusing to some of the reviewers. The intention was, upon discovering the computer, that the player would raise the priority of the Mechanical Systems to allow the operation of the elevator (and thus, allow moving the hose between floors), and then deactivate all other systems in order to conserve battery power. This double interaction required a knowledge of queues, the interaction of the power system with the other ships systems (as communicated by the screens), and the notion that the ship could function with several systems deactivated. Perhaps all of this required too much outside knowledge for a good puzzle, or the clues were not communicated well.

Secondly, while the syntax presented on the Help screen of the computer was straightforward to myself and presumably other programmers ( COMMAND <OPTION>, where the word within the brackets denotes a word to be replaced ), it was probably not as evident to people unfamiliar with this format. This lead to some frustration in operating the computer, and made an already complex system more complex than it needed to be.

Finally, because of the lack of polish, the computer didn’t have alternate names, such as ‘comp’, which would have allowed for testing the capabilities of the computer with far fewer keystrokes. Some shortcuts were enabled (such as allowing the use of ‘show’ in place of ‘display’ as a command, and not requiring the word ‘screen’, so that COMPUTER, SHOW HELP was as valid as COMPUTER, DISPLAY HELP SCREEN), but not enough to make this system as easy to use and as simple to learn within the two hour timeframe of the Competition.

In my aim for complexity, I overreached at the cost of fun, and that was a critical mistake.

4. Shipboard Directions and Incomplete Verbs

Because Splashdown takes place entirely on a crashed ship, I decided to forgo the normal cardinal directions (North, South, East, West), and use the shipboard directions Fore, Aft, Port, and Starboard. These directions mapped one-to-one with the normal cardinal directions, but it seemed that this was either lost on some players, or poorly communicated, even though it was in the online hints. One play tester repeatedly attempted to use the command "forward" to continue moving in the last direction specified, which of course didn’t have the expected result. While technically correct, I think that future games will stick to compass directions, and any ships will specify in their descriptions that "the fore of the ship lies to the north," or some such text that clarifies directions for the ease of the player.

There were also inadequate verbs for some options in the game, notably the heat pack. In the back of my mind, I knew that ‘activate’ was inadequate for this item, but it was such a low priority that I never got around to adding more options. Also, ‘remove’ should have been a synonym for ‘detach’ with regards to the hose, but again, it was a feature I never got around to adding. I hate playing guess-the-verb as much as the next guy, and will make a conscious effort in the future to be more on top of these issues.

5. Doing What Has Been Done Before

My goal to create an Infocom-esque adventure succeeded, but perhaps a little too well. It was a safe bet to go for a "crashed ship with sidekick robot" adventure, but there were several review comments that it wasn’t anything truly fresh or new. As my freshman effort, I was apprehensive to generate anything genuinely new for fear of alienating the judging pool, but in hindsight, I played it too safe.

The convention and environment of text adventures are probably familiar enough to draw in interest, and presenting a more unique universe, while riskier, has a better shot of being a standout title than just another game on a crashed spaceship. Roger Ebert has commented that movies allow us to see worlds that have never existed before, and I believe that games hold the same opportunity. It’s my goal for the future to bring forth worlds that are more dynamic and fresh, and with this title behind me, I’m confident that I can achieve that goal.


Splashing Down

All in all, Splashdown was an excellent experience for me as a designer and developer. It seemed to generate a generally positive, if not outstanding, response from the reviewers, and many players commented that with a little polish the game could be re-released as a much more playable version.

The lessons learned from Splashdown will doubtless be applied to future works of Interactive Fiction, and they can only improve my craft and programming skills. In addition, the warm reception to this outsider in the IF community was greatly appreciated.

Myst was not the first game released by Cyan, although it was their breakthrough, nor was Doom the first title from Id Software, even though it launched a global franchise. Each team had a break-in phase, where they found their footing, explored their space, and grew as designers and developers. I can only hope that Splashdown serves as my first baby-steps to better game development, and that my future works can approach the quality and fun of those games that have come before me.


return to the main splashdown page