hugo, >INVENTORY

Future Boy! by Kent Tessman [IF-Review]

[I originally reviewed this game for Mark Musante’s site IF-Review, in 2005.]

Hugo’s Heroes

Kent Tessman is both a filmmaker and a game author, and his latest game, Future Boy!, seems to have started life as a screenplay. I say “seems to” because while there are a lot of references to the “original Future Boy screenplay,” I never found any place in the game or its accompanying documentation that actually explained the story of how it came to be, why it didn’t get produced, and how it morphed from a movie idea into a game idea. Instead, the game just cruises along as if we know what it’s talking about, which we don’t. At least, I don’t.

So the characters and story started out aimed at the silver screen. How do they survive the transition onto the monitor screen? Pretty well, I’m happy to say. There’s plenty of fun to be had in Future Boy!‘s rich and well-implemented world, and the game’s multimedia content is easily the most impressive I’ve ever seen in an independently produced text adventure. If Future Boy! were free, it would be one of the best amateur games ever. However, it isn’t free — Tessman sells it for $25 (or $20 if you’re willing to forego the CD jewel case and booklet), and for me, that price tag demands a higher standard of testing and design, a standard that the game doesn’t always meet. I feel uncharacteristically reluctant to level any aspersions whatsoever at Future Boy!, since it’s so obviously the product of immense craft and dedication by a small cadre of artists. However, the fact remains that I wasn’t entirely satisfied with it, especially its later sections, and despite all the care and attention it obviously received, this game is still a flawed gem.

Still, I come to praise Future Boy! before I bury it (or maybe just toss a few shovelfuls of criticism onto it), so let’s talk about the multimedia, which is just awesome. Future Boy! splits the screen horizontally, with the bottom half dedicated to traditional text output, and the top half occupied by various hand-drawn pictures, some animated and some not. These pictures can be of the current location, as is the case with most multimedia IF, but they also serve to illustrate important objects and NPCs, and they sometimes show animated cut-scenes as well. The art feels enjoyably comic-booky, though amateur — artist Derek Lo is no John Romita, but his drawings do a nice job of evoking both the comedic and the adventuresome elements of the game, effectively strengthening its tone. Moreover, Tessman enhances the comic-book feel by displaying these pictures as independently floating panels rather than trapping them in static frames. The animations are especially cool, combining moving images with sound to marvelous effect, and providing a real reward for the act of puzzle-solving or exploration that triggers them.

Speaking of sound, the game’s sound design is as solid as its visual appeal. There’s zippy original music, written by the multitalented Tessman, who also does voice-acting for one of the characters. All the NPC voice-acting is pretty good in general, and occasionally inspired. Future Boy! reinforces the voice actors’ character-building with color-coded dialogue — red for the red-haired woman and so forth. These multimedia touches lend the NPCs much more distinctiveness and nuance than appears in the typical text game. The one minor quibble I’d make with the game’s sound is its insistence on inserting odd little musical cues and stings at scattered points throughout the interaction, sometimes seemingly at random. These cues make for an interesting experiment in mood-building, but they’re distracting as often as they’re dramatic. Still, they can be turned off, so no real harm done there.

In fact, Future Boy! provides a wealth of options like that, allowing player control over not only traditional things like verbose or brief descriptions, but also over its use of color, images, sounds, conversation menus, footnotes — virtually every special feature it provides. Controls like these are emblematic of the care that went into this game’s implementation, which is quite thorough overall, especially in the earlier sections of the story. One way in which the game wisely supports its location-depicting graphics is to implement all the objects shown in those graphics but not mentioned in the room description, even if only with a “that’s not important” type of message. Loads of other good ideas are put into action here, such as the entertaining plot recap provided after every SCORE and RESTORE command. I also appreciate the friendly “you can’t go that way” messages, which make sure to tell you what exits exist in the current location, and the nifty change in look and feel that occurs during a section of the game that involves hacking into a computer. Perhaps the coolest feature of all is the DVD-style “commentary” option which allows you to play through a version of the game where Tessman and Lo interject various musings and anecdotes on the making of the game at various points in the play session. If any question still remained, Future Boy! should eliminate all doubt that Hugo is absolutely a top-tier system for creating IF, possessing a solid world model and parser, and capable of achieving some really cool effects.

Future Boy!‘s story is pretty cool too. It shouldn’t give away too much to say that you play the roommate of a superhero living in Rocket City, a sort of stylized fictional mixture of New York and L.A. Future Boy (or Frank, as he’s known to you) has powers that are never quite defined but are vaguely Superman-like. However, he acts more like a typical roommate than a typical superhero, sometimes preferring to hang out on the couch watching TV rather than motivate to get the bad guys. So when supervillain Clayton Eno (who seems to have no powers at all besides a host of goofy Get Smart-ish devices and the ability to raise his eyebrows ominously) goes on a rampage, you find yourself drawn like Jimmy Olsen into the plot, and eventually it’s up to you to save the day, with a little help from some NPCs you meet along the way.

These NPCs are an entertaining bunch, with some very funny lines and incidental business for each. I particularly like Gorrd, a giant green — well, play the game and you’ll see. Dialogue occurs via a hybrid conversation system that combines menus with Infocom-style ASK and TELL commands. This system works pretty smoothly for the most part, though I did get seriously tripped up by it once, when a plot trigger was nestled in a menu option; I was forgetting to use the menus due to my old ASK/TELL habits. If the game seems to want to proceed but you can’t figure out how to nudge it along, my advice is to TALK TO everybody. Then TALK TO them again.

Future Boy!‘s heroic (or maybe sidekicky) premise makes for a fun world, and Tessman’s writing helps the fun along. The prose doesn’t particularly call attention to itself, though it’s certainly pretty good adventure game writing — adequate description with a hint or two smuggled in, as well as some good jokes. What makes it such a pleasure is the tone, which stays pretty much perfect throughout the game. Future Boy! is neither high drama nor low comedy, but a pitch-perfect funny adventure in the LucasArts tradition, with aliens who act just like cranky film noir characters, a superhero who spends most of his time slacking, and a villain whose ridiculousness never stops, from his name to his nefarious plans. One of my favorite Eno lines, after he gets knocked to the ground:

Mess with my evil plans, will you? What, did you think I was just going to lie down there on the sidewalk whistling the theme to Three’s Company? Mess with my evil plans, Future Boy. Come and knock on *my* door.

Also, it’s worth mentioning that the spelling and grammar are almost flawless; what errors remain seem like typos rather than genuine mistakes.

The game’s design does an excellent job of gradually opening up new plot and world terrain, and of introducing new complexities as the story goes on. The terrain itself feels convincingly urban — Future Boy! provides the feel of a large city without implementing a thousand locations by setting up several different areas of the city, linked by taxi and subway rides. Also, there’s an optional introductory section, which is very good at establishing the world and giving a sense of how the puzzles will go. In fact, Future Boy! contains a number of newbie-friendly features, such as a GOALS verb to list the PC’s current objectives, and the occasional parenthetical cueing that pops up when the PC seems to have wandered too far afield of those objectives, along the lines of “(Shouldn’t you be getting to work?)” Of course, that cueing can be frustrating if you know what you need to do but not how to do it, but it’s still a nice touch.

Should you find yourself thus stuck, Future Boy! provides an excellent set of in-game hints. These hints are in the classic InvisiClues style, starting with gentle nudges and advancing to outright solutions, depending on how many hints the player chooses to reveal. Also following the InvisiClues style, the hints are liberally strewn with red herrings; in this, they mirror some excesses in the game itself, about which a bit more later. For now, it’s enough to say that the hints are generally well written — with only one exception (when a subject heading wasn’t clear enough, leading me to ignore the hints that I needed) they gave me just enough help to get me unstuck. In any case, I tried to use them as little as possible, so that I could derive maximum enjoyment from the puzzles.

Many of these puzzles are quite enjoyable indeed. Most of the obstacles in Future Boy! offer a reasonable challenge without unreasonable frustration, and a few of them are highly pleasurable and original. Bypassing the security camera and getting the antidote formula are good examples of this, but I think my favorite was obtaining the helicopter key. This was one of those puzzles that I worked on for about a half-hour, set the game aside for a while, then had a flash of inspiration at 2am, fired up the laptop, tried my solution, and it worked. The IF experience doesn’t get better than that.

Other puzzles weren’t so hot, though, and generally the problem was down to a lack of feedback. There’s one puzzle where a critical item for the solution is never mentioned directly in its location’s room description. It’s possible to infer that the item is there, but it was rather too far a logical leap for my tastes. This issue would be solved by just a bit more suggestion in the room description (or possibly an action description) that the item is present. Another puzzle frustrated me by failing to account for some overlaps in its design — there’s an item that demonstrates a particular and significant behavior when taken to certain locations or placed in certain containers. However, placing the item in one of the special containers while standing in one of the special locations should produce another message about that behavior, and it doesn’t. This flaw led me to conclude that the container was ordinary, when in fact it wasn’t. Again, simply providing more sophisticated feedback would eliminate this problem.

Something else that makes Future Boy! more irritating than it should be is its abundance of red herrings. To some degree, these are a side effect of the game’s thorough implementation. Rocket City is a rich environment, with lots of fun jokes and easter eggs, and Future Boy! is designed like an old-style adventure game, meaning that your inventory quickly fills with tons of objects that might or might not be useful. However, there are plenty of purposeful red herrings inserted as well, throughout the game, and because the story is large, by the final scenes it really is too much. The problem becomes especially clear in those final scenes, because the game clearly seems to want a fast-paced climactic conflict, but the overwhelming number of misleading things to try and false trails to follow built up by that point makes it rather unlikely that the endgame will move along quickly.

Similarly, locations can change throughout the game, displaying new properties or objects as the plot moves along, and while this is a fine technique, it later begins to function as another burdensome red herring, when a stuck player travels desperately from one location to the next in hopes of finding something new. I’m not an anti-red-herring guy — I think a few blanks left unfilled at the end of the game lends a pleasing verisimilitude, but as I played through Future Boy! the second time, I was dumbfounded at just how many parts of it ended up having no function in the game’s true solution. In my opinion, scaling back on these would have brought a greater feeling of balance to the game, and made it more fun to play, especially towards the end.

Other weaknesses in the game spring from infelicities in Hugo’s world model and parser. Don’t get me wrong — for the most part, these things are on a par with the best in the genre, and I don’t hesitate to put Hugo on the same level with Inform and TADS for world model and parser quality. However, all systems have their quirks, and one of Hugo’s seems to be a peculiar disregard for scope. I frequently had interactions like this:

>x trash You don't see him.

or this:

>turn around You don't see him.

or this:

>ask coop about fire Coop doesn't seem to have anything to say about van stuff.

What seems to be happening here is that Hugo’s parser is taking the noun it’s given and comparing it to every noun in its dictionary. When it finds a match, the parser gives the response appropriate to the noun matched, even if that noun’s object is nowhere near the player at the time. For instance, “ask coop about fire” is meant to be a question about a concept or event, but the game sees that “fire” is a synonym for “fire extinguisher”, one of the nouns it implements as scenery in the van location, and responds as if I were asking Coop about the fire extinguisher in the van. The problem isn’t quite as clear in the “You don’t see him” responses — all I can surmise is that “trash” and “around” must be synonyms for some NPC. “X traxh”, for instance, gives the response “You don’t need to use the word ‘traxh'”, which is Hugo’s standard response for a word it doesn’t recognize, so it must be that it thinks I’m trying to refer to some character. While I applaud this game’s efforts to provide lots of synonyms for everything, when that technique combines with Hugo’s strangely global scoping rules, the results can be quite disconcerting.

Another parser gripe: the disambiguation could be smarter, though perhaps this problem is just another permutation of the scoping issue. For instance, here’s a response I got while in Frank’s bedroom:

>make bed Which bed do you mean, Frank's bed or the bunk bed?

>frank's It's Frank's bed -- you don't have to make it. Frank probably wouldn't recognize it if you did.

>x bunk You don't see that.

There’s no bunk bed in the room. There’s a bunk bed in the game, but it’s in a totally different location and plot section. Hugo should be smarter than to ask a question disambiguating between one thing that’s present in the current location and another thing that isn’t. If there’s only one object in the area that matches the noun used, the parser should just assume that this is the object intended.

These points are quibbles compared to the game’s most significant problem: it just falls apart towards the end. Well, maybe “falls apart” is too strong, but there’s a noticeable drop in quality in the later parts of the game. For instance, the first two-thirds of the game is roughly broken into chapters, and the appearance of a new chapter title is always cause for excitement, and a feeling of accomplishment. However, in the final sections, the chaptering just stops, with even major accomplishments going unmarked. In addition, the bugginess quotient is considerably higher in the last half of the game than it is in the first half. For that matter, I found it rather too high in the first half, at least for a commercial release. What it feels like to me is that Future Boy! just runs out of steam a while before it ends. As a game author, I can relate to this syndrome (boy, can I ever), but it’s still quite disappointing, especially (again) in a game I’m paying for.

Along with some critical bugs in the final puzzles, at least one of these puzzles has, in my opinion, and extremely implausible solution. Elsewhere, game-logic that has held since the beginning suddenly deteriorates or even reverses itself at the end. These bugs and design flaws, combined with the game’s wide and open geography and its severe propensity for red herrings, created a real flail-a-thon for me as I struggled toward its conclusion. Needless to say, the excitement that should have been racing through me as I reached the story’s climax and conquered the last obstacles was drained and deflated by the time I finished them.

I guess the bottom line is that I expect more when I pay more. If I downloaded a game like this from the archive, I would be both more impressed and more forgiving, because this would be one hell of a game to get to play for free. When I’ve paid, though, I find myself looking through “customer’s eyes,” and I expect to see no bugs or serious design flaws. As good as this game is, it doesn’t reach those standards. It’s probably true that Future Boy! is superior to many games that were commercially released at twice the price, but that doesn’t let it off the hook. (It just means that those other games deserved, and probably got, even sharper criticism.) But because the author of this game belongs to a small, friendly community of which I’m a part, I find myself asking whether it’s fair to apply those standards in this case.

In the end, I’ve decided that it is, but I hope I’ve drawn enough attention to this game’s many strengths to make it clear what an impressive accomplishment it is, despite its problems. Tessman continues to release patched versions of the game, which makes me hopeful that many of its bugs will eventually be squashed. For adventure game fans, Future Boy! may be a little pricey, but it is worth playing.

Getting Back to Sleep by Patrick Evans as “IceDragon” [Comp04]

IFDB page: Getting Back to Sleep
Final placement: 33rd place (of 36) in the 2004 Interactive Fiction Competition

Oh boy. Its time for one of my least favorite comp traditions: the homebrewed game. Traditionally, these games have parsers which lack the amenities provided by any major IF development system, and Getting Back To Sleep is no exception. What does it lack? Well, SAVE and RESTORE, for starters. Oh, and SCRIPT, which means that you’ll be seeing no quotes from the game in this review. Rather than making notes at the prompt as I usually do, I had to keep switching to a separate file to keep my notes, and felt slightly annoyed each time.

Let’s see, what else? UNDO, OOPS, and lots of other modern features, and by “modern” I mean “standard as of 1985 or so.” Those weren’t there. Nor was VERBOSE mode, which sucked for me, since I always play in VERBOSE mode. Instead, I had to keep typing L every time I wanted to look at the room description. Except that L doesn’t work either! Yeah, you have to type out LOOK each time. You also can’t abbreviate INVENTORY to I, though at least you can abbreviate to INV. Why one abbreviation is present and not the other continues to mystify me.

Here’s a good one: the parser is case-sensitive. It understands “look” but not “Look.” For a long, scary moment, I thought there was no way to see room descriptions a second time. The parser also breaks my Third Law of Parsing, which is “Parsers must not ask questions without being prepared to receive an answer.” GBTS is guilty of asking questions that look like disambiguation (“What do you want to get?”) without being able to handle a one-word answer at the next prompt.

It’s not that I think creating a homebrewed system would be easy. I’m sure it’s a hell of a lot of work. But why you’d put in all that work, coding (according to the readme) over 10,000 lines of C# in a state-of-the-art programming environment, to create something that wouldn’t have even passed muster as a text adventure twenty years ago… that escapes me. I could see trying it if that was your only choice, but there are multiple very good IF development environments, all of which produce output that’s playable on way more platforms than GBTS is, all of which offer all the features I described in my first paragraph “right out of the box”, and all of which are completely FREE!

It kind of feels like building your own piano while Steinways are being given away around the corner. It’d be one thing if your piano was going to be just as good as the free ones, but when yours has only 20 keys, no pedals, no black keys, and is wildly out of tune, how can you expect your performances to be any good? One of the sadder parts is that the readme proudly states that this homebrewed system has “the flexibility and freedom to accomplish what no other interactive fiction system can do: the game lives in real time.” Well, I can’t speak for TADS or Hugo, but Inform most certainly can do that. Hell, ZIL could do it. Border Zone had it in 1987.

Of course, GBTS would have its problems even if it were created with an IF development tool. It’s one of those games where you might see shelves full of stuff, and X SHELVES would give you a dull description about the stuff being a lot of supplies and junk. X SUPPLIES gives you the same description and X JUNK isn’t even implemented, so you move on, only to find out later (from the walkthrough) that SEARCH SHELVES would give you a special key for one of the game’s many locked doors. Many many first-level objects are unimplemented. Its/it’s errors infest the prose. There’s a sorta-maze, with a randomly appearing object that is vital for solving a puzzle. There’s tons of stuff like that. The story itself is fine, though highly derivative of Planetfall. But the game is an experience to be missed.

Rating: 3.2

Zork II [Infocom >RESTART]

IFDB page: Zork II
[This review contains lots of spoilers for Zork II, and some for Zork I as well. Also, I wrote an introduction to these Infocom >RESTART reviews, for those who want some context.]

Dante and I fired up Zork II right after finishing Zork I, and yep, it’s another text game from the early 1980s. There’s still no “X” for “EXAMINE”, still lots of obviously amazing things described as “nothing special”. We were more ready for that this time, which perhaps threw more light on the next layer of dissonance between that era of text adventures and the mid-’90s renaissance: the specific affordances introduced by the Inform language and libraries.

>COMPARE INFORM TO INFOCOM

Dante cut his IF teeth on Inform games, so he found interactions like this pretty annoying:

>put string in brick You don't have the black string.

>get string Taken.

>put string in brick Done.

Inform would have simply handled this at the first command with the bracketed comment “[first taking the black string]”, then moved right on to “done”. (Some later Infocom games took initial steps down this road too.) Furthermore, we couldn’t refer to the resulting compound object as a bomb, even though it was clearly a bomb — granted, that’s not something Inform would have done automatically either, but it is a pretty frequent occurrence in modern text games.

Another instance Inform handles nicely but Zork II does not:

There is a wooden bucket here, 3 feet in diameter and 3 feet high.

>in You can't go that way.

>enter You can't go that way.

>enter bucket You are now in the wooden bucket.

Again, Inform would have simply filled in the blank with “[the bucket]”, unless there were multiple enterable objects or map vectors in the player’s scope. And even then, it would have asked a disambiguating question rather than simply complaining, “You can’t go that way.” In fact, we could go that way.

Finally, Inform provides authors with a couple of easy facilities for avoiding “I don’t know the word [whatever]” when the player tries to reference nearby nouns. Those two magical tools are scenery objects and aliases. Thus, where Zork II gave us this:

Cobwebby Corridor A winding corridor is filled with cobwebs. Some are broken and the dust on the floor is disturbed. The trend of the twists and turns is northeast to southwest. On the north side of one twist, high up, is a narrow crack.

>examine cobwebs You can't see any cobwebs here!

Inform would have allowed an author to create a scenery object called “cobwebs”, and give it aliases like “webs”, “broken”, and “cobs”, so that even if she didn’t want to write a description of them, references to any of those nouns would result in a message along the lines of “You don’t need to refer to that in the course of this game.” That object could appear in multiple rooms, which I’m guessing is the flaw Zork II ran into here, since it clearly knew the word. I should also mention that it’s not just Inform that helps with extra objects, but the more relaxed memory constraints of the .z5 and .z8 formats (not to mention Glulx) compared to the .z3 that Zork II inhabits. Those early Implementors were trying to fit so many clowns into one tiny little car.

In any case, it’s worth a moment to just meditate in gratitude to Graham Nelson and his helpers for creating so many little helpful routines to smooth out the IF experience. Text adventures are forever changed, for the better, as a result of that language and its libraries. (That’s not to take anything away from TADS or Hugo, of course — I’m just thinking of how z-machine games specifically advanced.)

While the early z-machine had some pretty austere limits, some other limits were built into the Zork II experience by design. I’m thinking here of the inventory limit and the eternally damned light limit, which was even more frustrating here than in the previous game. I dunno, I suppose it’s possible that there was some technical root for the inventory limit, but it sure feels like it’s imposed in the name of some distorted sense of “realism”, a notion which flies out the window in dozens of other places throughout the game. Even if we accept the magic, the fantasy, and the allegedly underground setting (with features that feel less and less undergroundy all the time), there are just many things that make no physical sense, like easily scooping a puddle into a teapot. We can do that but we can’t carry however many objects we want to? (Again, Inform rode to the rescue here with the invention of the sack_object.)

That light limit, though. There’s no technical reason for it, and it caused us to have to restart Zork II TWICE. Not only that, it’s even crueler than its Zork I version, both because there is no permanent source of light in the game (unlike the lovely ivory torch from part 1) and because there are so many ways in which light can be randomly wasted by events beyond the player’s control. Chief among these are the Carousel Room and the wizard.

Zork I had a Round Room too, and it was entirely harmless. The Carousel Room is another story. It’s the kind of thing that sounds like a fun way to confound players, and it is, but in the case of my playthrough with Dante, we didn’t defeat it until very late in our time with the game — probably about the 75% mark of the time we spent on the game overall. That means a lot of our transcripts consist of us trying to go a direction, failing, trying again, failing, rinse, repeat, all the time ticking through that light limit, since of course all the rooms involved are dark. And it’s not as if the game makes it obvious what or where the puzzle to stop the room even is.

By itself, this direction-scrambling behavior would be quite annoying. When coupled with the fact that our light source is on an unalterable timer, it’s infuriating. Now add to that an NPC who can come along and waste your time with spells like “Float”, “Freeze”, or “Feeble”, all the time wasting yet more light, and you have one deeply frustrating game mechanic. This is that hallmark of early text games, where forced restarts were seen as adding to the “challenge.” A challenge to one’s patience, certainly. As before, Dante sat out those replay sessions.

>EXAMINE WIZARD

Since we’ve arrived at the topic, let’s talk about the Wizard of Frobozz. As has been extensively documented, Zork began life as a mainframe game, too large to fit into the microcomputers of its day, so when its implementors formed Infocom to sell it on the home PC market, they had to split up the mainframe game into pieces. That meant that the nemesis of the original game, the thief, appeared and was dispatched in the first installment of the home-version trilogy.

The thief was compelling. He could pop into your world at the most inconvenient times and create havoc, but you also couldn’t finish the game without him. With him gone in the first game, who would serve as the new adversary? Enter the Wizard. Dante was excited the first time the Wizard showed up — “It’s the title!” he said. The Wizard is a compelling character too — unpredictable like the thief but with a much larger variety of actions. He can cause a wide range of effects, but sometimes he screws up and doesn’t cause anything at all. Other times, he thinks better of meddling, and instead “peers at you from under his bushy eyebrows.”

When the wizard would show up, and the game would unexpectedly print out a stack of new text, our pulses would quicken, thinking that we’d stumbled onto something exciting. This effect reminded me to tell Dante about the days of external floppy drives — when I first played Zork II, the entire game couldn’t fit in the computer’s memory, so whenever something exciting was going to happen, the game would pause and the disk would spin up, so that the new data could be read into memory before it was displayed to the player. The excitement that accompanied that little light and whir — for instance, when leading the dragon to the glacier — was equal to any thrill I’ve subsequently gotten from a video game.

Of course, in the case of the wizard, it would turn out that nothing cool was happening. In fact it was just the opposite — we were generally about to get stymied in some amusing but nevertheless aggravating way. The wizard obviously gets more frustrating as he keeps repeating and repeating, but the variety and comedy in his spells, not to mention that sometimes he fails completely or casts something you don’t hear, really helps temper the annoyance. That said, this game is rich enough to encourage a flow state, and when the Wizard shows up to somehow block your progress, it really disrupts that flow.

Those blockages are ultimately detrimental to the game, on a level I doubt its authors were even thinking about. Parser IF is full of pauses — an indefinite amount of time can pass in between each prompt. However, the player is in control of these pauses’ length, and when we’re barreling through a game, either replaying old stuff to get somewhere or carried on the wings of inspiration, the pauses hardly feel like pauses at all. It’s more like an animated conversation. When the Wizard comes along, though, he’s a party-crasher who grinds that conversation to a halt. Suddenly we are being forced to pause, and cycle through more pauses to get through the pause.

Perhaps in some games, such a forced break would create contemplation, or an opportunity to step back and think of the bigger perspective. That wasn’t the case in Zork II, at least not for us. It just felt like our conversation had been interrupted, and we had to wait for the intruder to go away before we could continue having fun. This feels qualitatively different from the thief, whose arrival would shift the tension into another register, and whose departure may have resulted in loss of possessions, but never in paralysis that simply drained precious turns from an implacable timer.

On the other hand, the wizard has some excellent advantages over the thief. Infocom didn’t make the wizard part of the solution to a puzzle, the way the thief was, since that would have been redundant. In Zork I, the thief would foul up your plans, and had to be eliminated (though not too soon) in order to progress. Instead of this, Zork II themes its entire late game around fouling up the wizard’s plans. This conveys the sense that unlike the thief, the wizard has a separate agenda, one that isn’t centered around the player. That adds a small but significant layer of story to this game that isn’t present in its predecessor.

The way we frustrate the wizard is by getting into his lair, and doing so is one of the game’s most satisfying puzzles. The locked, guarded door to the lair starts with an arresting image: “At the south end of the room is a stained and battered (but very strong-looking) door. […] Imbedded in the door is a nasty-looking lizard head, with sharp teeth and beady eyes. The eyes move to watch you approach.” Getting past this door means disabling both the lizard and the lock, and each requires solving multiple layers of puzzles. For the lizard, it’s solving the riddle room, then finding your way to the pool, then figuring out how to drain it. For the key, it’s getting rid of the dragon, then rescuing the princess, then figuring out that the princess should be followed to the unicorn.

Then, of course, there’s the step of determining that the key and the candies are the necessary ingredients for the door. We tried many things before that! (In the process, we found one of the weirdest Infocom bugs I’ve ever seen — more about that in a moment.) And yet, even after solving it, we didn’t even have half the points! Experiences like this are what make Zork II feel so rich. Layering of puzzles, and then opening up an even bigger vista when they interlock, makes for a thrilling player experience.

Okay, so as promised, the weird bug with the lizard door:

Guarded Room This room is cobwebby and musty, but tracks in the dust show that it has seen visitors recently. At the south end of the room is a stained and battered (but very strong-looking) door. To the north, a corridor exits. Imbedded in the door is a nasty-looking lizard head, with sharp teeth and beady eyes. The eyes move to watch you approach.

>look through mouth You can't look inside a blast of air.

>examine air There's nothing special about the blast of air.

A blast of air??? What in the world is this? Dante and I never figured it out. There’s never a blast of air anywhere in the normal course of gameplay that I can find. Yet there it is in the Guarded Room, invisible but waiting to be found, apparently as a synonym for “mouth”. It gives all the usual stock responses — e.g. “I don’t think the blast of air would agree with you” as an answer to “EAT AIR”, but is simply inexplicable. Stumbling across it was one of the weirder moments I’ve ever had with an Infocom game.

There were some other amusing bugs as well:

>put hand in window That's easy for you to say since you don't even have the pair of hands.

>roll up newspaper You aren't an accomplished enough juggler.

>throw bills at curtain You hit your head against the stack of zorkmid bills as you attempt this feat.

>put flask in passage Which passage do you mean, the tunnel or the way?

We played the version of the game released in Masterpieces of Infocom — at the time that compilation was released, Zork II was 14 years old, and had sold hundreds of thousands of copies. The fact that these bugs remain is a consolation to every IF author who eventually abandons a game, its final bugs unsquashed.

>EXAMINE PUZZLES

Blast of air notwithstanding, that lizard door isn’t the only great puzzle in Zork II. The hot air balloon is another all-time winner. Figuring out the basket, receptacle, and cloth is fun, but once the balloon inflates, its ability to travel within the volcano feels magical. That balloon/volcano combo is one of the most memorable moments in the entire trilogy, and the whole section — including the bomb, the books, and the way it ties locations together — is a wonderful set piece.

The dragon puzzle is another great one. For us, it wasn’t so much a “How can we lead the dragon to the glacier” as it was a “Whoa, the dragon is following us. Where can we go?” I quite like that Zork II allows both of these routes to arrive at a solution. The placemat/key puzzle, while less flexible, is brilliant too, though it feels rooted in a time when people would have seen keyholes that a) could be looked through and b) might have keys left in them. Such a real-world experience was simply not in Dante’s frame of reference. In fact, I remember struggling with that puzzle when I was a kid, too — my dad stepped in and helped me with it, possibly aided by having lived in the kind of house where this could be a legitimate solution to an actual problem.

There are also some lovely structural choices in Zork II. The sphere collecting and placement is a great midgame — getting each one is exciting, and putting them on the stands feels appropriately climactic for the end of the second act. Similarly, the demon is a good creative variation on Zork I‘s trophy case, one who offers a marvelous sense of possibility once he’s satisfied.

We tried a variety of things with his wish-granting power, some rewarded and some not. We focused at one point on the topiary, one of the most enticing red herrings in the trilogy. We kept thinking there must be something to do with it. But “demon, destroy topiary” and “demon, disenchant bushes” got us nowhere. On the other hand, “demon, kill cerberus” was rewarded with comedy, if not progress:

“This may prove taxing, but we’ll see. Perhaps I’ll tame him for a pup instead.” The demon disappears for an instant, then reappears. He looks rather gnawed and scratched. He winces. “Too much for me. Puppy dog, indeed. You’re welcome to him. Never did like dogs anyway… Any other orders, oh beneficent one?”

Our first successful try was “demon, lift menhir”, which certainly got us where we needed to go, but much more wondrous was the notion of the demon granting us the wizard’s wand. Several times, Zork II had given us that wonderful IF experience of a broad new vista opening in response to overcoming some obstacle — the balloon and volcano is a prime example, as are the riddle and the Alice areas. When we obtained the wand, it felt like another whole range of possibility opened up. This sense eventually shrank, of course, but it didn’t fully go away either. For one thing, just the ability to “fluoresce” things and end our light source torture felt like a miracle. Of course, it screwed us up for the final puzzle, but more about that a bit later.

We also tried “demon, explain bank”, which didn’t work, but I sure wish it would have. As had many adventurers before us, we struggled mightily with the Bank of Zork. We eventually blundered around enough to get through it, but at no point did we feel a flash of insight about it, or an epiphany of understanding. I hesitate to call this an underclued puzzle. I think it’s just bad — maybe the worst puzzle in the trilogy. Dave Lebling later revealed that even other Infocommers couldn’t keep it straight.

The oddly-angled rooms are another infamous Zork II puzzle, in this case infamous for requiring knowledge of baseball in a way that excluded non-Americans. I contend, though, that this isn’t even the worst part of the puzzle. Even if you do understand baseball, and even if you do make the connection between those rooms and a baseball diamond, the puzzle is still unreasonably hard to solve. Say somebody told you in advance that this is a baseball-themed puzzle, and that to solve it you’d have to traverse through the rooms like you’re running the bases. What would you do? If you’re anything like me, you’d envision the typical diagram of a baseball diamond. It looks like this — the first hit on a Google image search for “baseball diamond”:

If you conceive this diagram as an IF map, the pitcher’s mound is north of home plate, and the other bases extend in cardinal directions from the mound. So starting at home plate, to run the bases, you’d go: NE, NW, SW, SE. Right?

Well Zork II, for reasons I don’t understand, tips the diamond on its side. To run the oddly-angled bases, you have to pretend that home plate is west of the pitcher’s mound, and therefore travel SE, NE, NW, SW. That reorientation delineates the difference between “Oh, ha, it’s a baseball diamond!” and “How in the hell is this a baseball diamond?” So take heart non-Americans (and Americans who don’t know the first thing about baseball) — that “inside baseball” knowledge isn’t nearly as helpful as you might think.

The other puzzle that really stymied us was the riddle. For those who haven’t played in a while, the riddle is this:

What is tall as a house,
round as a cup,
and all the king’s horses
can’t draw it up?

This was an interesting one for me to observe. I remember solving it quite readily when I played Zork II as a kid. For whatever reason, the words just clicked for me. Dante, on the other hand, really grappled with it. He took about thirty different guesses over the course of our playthrough before I started feeding him hints. The guesses fell into a few different categories:

- Contrived answers: a gigantic egg, an osmium sphere (because osmium is so dense)
- Jokey reference answers: the Boston Mapparium (an enclosing stained-glass map globe that he learned about from Ken Jennings), an enemy city support pylon (referencing The City We Became by his fave author N.K. Jemisin), a geode (from the same author’s Broken Earth trilogy)
- Logical guesses, albeit not very Zorky ones: power pole, pipe, subway
- References to this game or the previous one: rainbow, tree, menhir, dragon, xyzzy, the letter F, barrow, glacier, carousel, lava tube, gazebo, cerberus, balloon, hot air balloon, cave, carousel room, mine, coal mine
- Just off-the-wall pitches: hill fort (a Celtic thing inspired by “barrow”), tentacle, squid, octopus

Finally I started hinting around pretty heavily to think about holes in the ground, but even then he said “hole”, “bore hole”, and “quarry” before he got to “oil well”, which wasn’t even the game’s intended answer but which still provoked the success response because it contained the word “well”.

Riddles have a big risk/reward proposition as an IF puzzle. If you solve one, you feel so chuffed and clever. But if you don’t solve it, you may just be stuck, especially in the absence of any other hinting mechanism. Perhaps in the days where players were willing to sit with stuckness for extended periods of time, the calculus was a little different, but now puzzles like this flirt with ragequit responses, which I would argue has turned into a failure on the game’s part.

The final puzzle of Zork II felt like a mixed bag to us. It’s intriguingly different from Zork I, which basically led you to the ending after you’d deposited all the treasures. In Zork II, you can get all the points but not be finished. Indeed, the response to “SCORE” at this point is:

Your score would be 400 (total of 400 points), in 753 moves.
This score gives you the rank of Master Adventurer, but somehow you don’t feel done.

There’s one more puzzle to solve, and for us it was difficult enough to require a hint, something we’d managed to avoid for the rest of the game. Nevertheless, we ended up satisfied, feeling that it was tough but fair — essentially it requires being lightless, something that willingly surrenders in the battle we’d been fighting the whole game. We completely missed the hint — a fairly obscure phrasing on a can of grue repellent — and therefore floundered.

For us, the barrier to solving this puzzle was the flip side of the sense of possibility that the wand allows. For example, the ability to make things fluoresce with the wand so fascinated (and relieved) us that we never walked in there without light. Our continued frustration with light limits also made this behavior very enticing. On top of that, it seemed like no coincidence that “Feel Free” was a double-F, like a more powerful version of the wizard’s spells. Oh the number of places where we pointed the wand and incanted “Feel Free”, to no avail. On the other hand, having solved this puzzle with hints prepped us to solve on our own a very similar puzzle in Enchanter, but that’s a topic for another post.

I think I’ve spent more time in this post criticizing Zork II than I have singing its praises, so it may be surprising when I say that this is my favorite game of the trilogy. I have plenty of affection for parts 1 and 3, but to me this is where the best parts of Zork fully jelled. The humor works wonderfully, the imagery is fantastic, and the structure mixes richness and broadness in a way that makes for wonderful memories of gaming excitement. And sure, its bad puzzles are bad, but its good puzzles are great — deeply satisfying and marvelously layered. Zork I established the premise, and Zork III deconstructed it, but Zork II fulfilled it, and in the process provided me with many happy hours that I loved revisiting with Dante and his fresh eyes.

SURREAL by Matthew Lowe [Comp01]

IFDB page: SURREAL
Final placement: 45th place (of 51) in the 2001 Interactive Fiction Competition

The author’s notes for SURREAL contain the following statements: “I am currently fourteen years old and I enjoy playing text adventures.”; “SURREAL is the first text adventure I have ever written so I hope that it’s alright.”; “I hope you like it.” So now I’m in a bit of a pickle. I didn’t like the game, because it had lots and lots of problems. But I hardly want to crush a first-time author, especially somebody so young who enjoys text adventures not as nostalgia, but on their own merits.

So this seems like a good time to reiterate my general reviewing philosophy: basically, I’m here to help. I never want my reviews to come across as nasty jabs, and if they do, it’s because of my own deficiencies as a writer and critic. Instead, I hope that these reviews offer worthwhile feedback to authors, and that they communicate some of my ideas and knowledge about IF. The point is not to smack somebody down for writing a bad game, but rather to report on my experience with that game so that the author’s next game can be better. Now, that being said: SURREAL was not a strong game.

Let’s talk first about the writing. It’s pretty apparent that the game’s landscapes are inspired by the Myst series, and that’s not always such a bad thing. There are moments throughout where a vivid picture arises from a paragraph, or even a sentence. However, grammar is a serious problem through the entire game. Poor grammar is a writer’s bane, because as a rule, it impedes the communicative arts; the prose in this game is no exception to that rule. Take these sentences, for instance:

You are standing in the fresh outdoor air again, a spray of salty water hits you in the face. The weather has taken a turn for the worse as dark clouds roll across the sky like and army of black horses marching to war.

The first sentence is a run-on, meaning that it’s really two sentences held loosely together by a comma. What this does to me as a reader is basically to pull the rug out from under me. I read the first part of the sentence, then hit the comma, which signals to me that I’m about to read something related to the first clause, probably either a dependent clause or an appositive. Instead, I get hit with another independent clause, and consequently I have to stop and try to figure out what the connection is. A moment later, I realize that there is no connection, because it’s just a run-on. But by then it’s too late — I’ve already been thrown out of the prose. All this happens very quickly, but the result is devastating to the story’s power, because it makes me remember that I’m reading words on a screen rather than inhabiting a surreal world.

The second sentence has a more obvious problem: instead of “like an army of black horses”, it says “like and army of black horses.” Typos like this are similar to heavy static on a TV screen. If we’re looking closely, we can see what’s supposed to be there, but after a while, it hardly seems worth the effort. Words are the game’s only conduit to our minds, and if the words don’t make sense, the game doesn’t either. There are also several NFIEs, but I have taken a deep, cleansing breath and promised not to rant about those.

Implementation is also a serious issue. The game is apparently programmed in GAGS, a precursor to AGT. Now, why in 2001 someone would want to use such a primitive development tool is a complete mystery to me. Even if one is too intimidated to broach something like Inform, TADS, or Hugo, there are plenty of newbie-friendly languages that are far more robust than GAGS. That choice of tool alone limits the game’s audience severely, since it’s only playable via MS-DOS, and even among DOS users, there are plenty of people who are unwilling to put up with a rudimentary parser and absent features from a modern text adventure.

On top of that, some of the most important items in the game are unimplemented, even with a “That’s just scenery” sort of description. No matter how much one loves text adventures, parser-wrestling is just not fun, and tools like GAGS make for lots of parser-wrestling. There is promise in a game like SURREAL, but it’s a promise largely unfulfilled. My advice to the author is to learn a high-level IF language (it’s not that hard, really!), review basic grammar, employ proofreaders and beta testers… and write again!

Rating: 2.5

Wrecked by Campbell Wild [Comp00]

IFDB page: Wrecked
Final placement: 39th place (of 53) in the 2000 Interactive Fiction Competition

There are several points in Wrecked where the game collars you to proclaim just how awesome its development system is. For example, you meet someone who (surprise surprise!) just happens to be coding an ADRIFT game on a nearby computer. Ask her about it, and she’ll say to you, “I’m making an ADRIFT adventure. I’ve tried using Inform, TADS and Hugo, but I’d say ADRIFT is by far the best.” In another location, you can gain some points with the command “write graffiti,” something I would never have thought to do without the handy walkthrough to prod me. The graffiti the game chooses to write? “ADRIFT rocks!”

Apparently, Wrecked suspects that its own merits are not enough to convince you of ADRIFT’s supremacy, but that if it just shouts slogans at you once in a while, that might do the trick. For me, the former was true, but the latter, predictably, was not. I’ve already catalogued the shortcomings of ADRIFT in my review of Marooned, so I don’t see the need to rehash them here — the bottom line is that ADRIFT isn’t a bad system overall, and has some nifty features to recommend it, but its parser (which is MORE IMPORTANT THAN NIFTY FEATURES) is substandard, its model world needs work, and it’s still lacking in key functions like UNDO and SCRIPT. A random NPC might think it beats Inform, TADS, and Hugo, but a quick conversation with this NPC demonstrates that her powers of discernment are, after all, rather limited. The game’s self-hyping moments are offputting, as it would have been if Graham Nelson had chosen to have “Inform RUELZ!” scribbled on the side of the house in Curses, or if the spaceship in Deep Space Drifter had been named the USS TADS Is Supreme.

On the other hand, Wrecked is definitely a better showcase for ADRIFT than is Marooned. Those extraneous newlines that I blamed on the ADRIFT system in my review of Marooned turned out to be that game’s doing — they’re nowhere to be found in Wrecked. Many more first-level nouns are implemented, making the auto-complete option work much better, though it still doesn’t work flawlessly. Also, there’s no starvation puzzle in Wrecked, which sets to rest my fears that such a puzzle is standard issue in every ADRIFT game.

However, just being a better game than Marooned doesn’t make Wrecked a great game in itself. One part of the reason why I didn’t care for Wrecked is that it just feels very dated to me. It’s an old-school adventure, something that might have fit comfortably into the mainstream circa 1983 or so. You know the kind: you find a bowling ball with a button on the side, and when you push the button, the ball opens up to reveal a sapphire bracelet, which you then give to the sailor on the dock, who will reward you with a chicken pot pie that you can feed to the vicious warthog, allowing you to sneak into his lair and retrieve the bag of marbles, etc. etc. Everything is pretty much thrown together without any rhyme or reason, loosely grouped together under a threadbare rubric of plot and setting. Like I said, old-school. Unfortunately for Wrecked, the old school of IF lost its accreditation some time ago. To my mind, senseless grouping of stuff without any indication of internal consistency is something IF has outgrown, like mazes and starvation puzzles. Seeing it in a year 2000 competition entry isn’t going to score a lot of points from me.

However, even if I were willing to set aside the deep flaws in both the parser and the design of the game, there would still be the matter of the bugs. Most severe among these is the game-killing bug I encountered about an hour and 45 minutes into the game: despite all conditions being correct, I was unable to complete a critical puzzle, even though I knew from a previous play session that it was possible to complete this puzzle. Because ADRIFT makes a habit of overwriting old save files with the current save unless you explicitly tell it to do otherwise (by selecting “save as” from the menu bar — typing “save” will overwrite without prompting), I would have had to start from scratch and wind my way once more through all the nonsensical contortions required by the game’s plot, and there was no guarantee that I wouldn’t encounter the same bug again.

That bug ended my dealings with Wrecked, but there were other errors along the way. The voice was in first person, but would occasionally slip into second person. Sometimes the game failed to recognize rather important objects. In one supremely frustrating section, the game adamantly refused to recognize the word “keyhole,” despite a promiently featured keyhole in the location; it responded to all commands along the lines of “put key in keyhole” with “I can’t put anything inside the small key.” In short, between the bugs, the parser, the hype, and the lack of any kind of logic, Wrecked wasn’t a lot of fun, and it’s not likely to win many converts to ADRIFT. No matter how many times it insists that ADRIFT rocks.

Rating: 4.0

Escape From Crulistan by Alan Smithee [Comp00]

IFDB page: Escape from Crulistan
Final placement: 43rd place (of 53) in the 2000 Interactive Fiction Competition

When the IF competition started, it was meant to be a mechanism for encouraging people to produce more Inform games, and not incidentally more Inform sample source code. After much haranguing on the newsgroups, it was agreed that TADS authors ought to be able to participate too, and the two types of games were grouped into their own separate divisions. After the games came out, we realized that not much new Inform source code had been released, but that the comp was definitely a major hit.

In a unifying spirit, the next year’s comp dropped the language specifications; the gates were opened to any kind of IF game. Since then, every single year the comp has seen at least one “homebrewed” game — that is, a game written without the aid of a major IF language such as Inform, TADS, or Hugo. And not one of those games, not one, has had a parser and model world to match that which comes automatically with the major IF languages. Some have had their own nifty features, to be sure, but the core of IF (and the biggest programming challenge as well) is the parser and model world. When that is lacking, the game is just not going to be good, no matter what else it has going for it. If you’ve guessed by now that Escape From Crulistan is no exception to this trend, congratulations.

Please pardon me. This is something like my 47th comp game. I’m running low on sleep. I’m cranky, and my mood was not improved by the extremely frustrating two hours I just spent with a game that responds like a lobotomized Inform. The first command I type when I’m playing a game for review is “script”, so that I can have a transcript to refer to as I write the review. The next command I type is “verbose”. When the game recognized neither of these, I began to get a sinking feeling.

My subsequent experiences didn’t make me feel any better at all. Experimentation soon revealed that the game only recognizes an extremely limited set of verbs and nouns, far too few to provide any sense of smooth gameplay whatsoever. Now, as I often say when I review homebrewed games, I admire what it did achieve. The desire to write an IF engine from scratch is foreign to me, but I certainly can respect it in others, and it would take a better programmer than I to create even the parser in Crulistan, let alone the strong parsers of the established IF development systems. Nonetheless, achievement though it is, Crulistan‘s parser is woefully insufficient. When you’ve just gone through several dozen games whose parsers have a very high level of quality by default, stepping into Crulistan feels like a jail cell in more ways than one.

Perversely, rather than drawing attention away from these limitations, the game’s design seems instead to want to emphasize its flaws. It consists of a string of situations which require very specific solutions, and the game usually neglects to implement any alternatives, even if just to tell the player that they won’t work. For example, the initial puzzle of escaping from a cell might seem to hinge around going through the window. Yet by no combination of verbs and nouns (and believe me, I tried a lot of them) can you convey to the game that you want to try this. It’s fine if the game doesn’t want to allow it, but not even to implement it? Inexcusable.

Then, when I finally did figure out how to escape the cell, then spent another half-hour trying to guess the right sequence of commands (with very little useful feedback from the game) for the next section, I found myself outside the prison, and the game, unbeknownst to me, was in an unwinnable state. I only learned this after much frustration and failed brute-force attempts at puzzle-solving sent me back, in desperation, to the initial scene. Turns out there are two ways to escape the prison, but only one of them will allow you to proceed further in the game. The game gives no indication whatsoever of this situation, and because so little is implemented, I found it easy to believe that the “wrong” solution I had found was the one and only solution to the prison puzzle. So, the one time an alternate solution was implemented, it was only an extremely elaborate red herring — what an infuriating design choice, especially in a game where so few things work.

Once I did get further, I almost immediately found myself stuck in another situation where the solution was a mystery and the game didn’t recognize 90% of the things I tried. Compounding this problem, no walkthrough is provided. In fact, when you type “help”, the game chides you, “Oh come on now. This game is ridiculously easy.”. Yeah, if you wrote it, maybe. Then again, the author credit seems to allude to the disavowal that film directors sometimes issue on projects that have escaped their control. Of course, with an IF game, there’s really nobody to wrest control from the author, so this allusion is puzzling to say the least. But nobody can say it’s not justified.

Rating: 2.1

Skyranch by Jack Driscoll [Comp99]

IFDB page: Skyranch
Final placement: 37th place (of 37) in the 1999 Interactive Fiction Competition

In my head, I’ve started this review a dozen different ways and discarded them all. The unused versions were rejected for being too caustic, too angry, or too harsh. During this current attempt, I will try to keep a leash on these energies, though they’re chomping at the bit (if I may mix my animal metaphors.) I want for these reviews to be helpful, not hurtful, and I want to keep my criticisms constructive. In that spirit, I offer a couple of changes that could (and should) be made to make Skyranch a playable game:

The game should be reprogrammed until it meets a minimum level of coding quality. I would put this minimum level right around the functionality provided by, for example, an Inform shell game (i.e. the bare-bones version of the library before the game author has added any real code.) To detail all, or even many, of the ways in which Skyranch fails to meet this standard would take more time than I want to devote to this game. One example: the game should recognize verbs like “ask” and “examine”. The game’s error messages should be helpful, rather than flippant parser responses like “What?” or “So… what are you saying?” Many authors meet this minimum standard by using a text adventure creation tool such as Inform, TADS, Hugo, ALAN, etc. to create their game. This isn’t strictly necessary, of course, but if a game is programmed from scratch, it had better be at least as good as one that was created with such a tool.

The prose should be rewritten until it consists of correct English sentences. The current writing in the game is pretty abysmal. Mistakes are so legion that the text is often confusing, sometimes completely incomprehensible. Until a text game is written in English, it won’t be any fun for me to play, because English is the only language I read fluently.

Until these two basic conditions are met, Skyranch won’t even be worth discussing, let alone playing.

Rating: 0.9

SNOSAE by R. Dale McDaniel [Comp99]

IFDB page: SNOSAE
Final placement: 32nd place (of 37) in the 1999 Interactive Fiction Competition

By the time I hit the end of the two hour mark on SNOSAE I was just laughing. Most of my second hour I was basically cutting and pasting commands from the walkthrough, stopping only long enough to read the text and save the game from time to time in case I screwed up. Even so, when I reached the time limit I still had over half the walkthrough to go! If this is a two-hour game, The Brothers Karamazov was a short story. I doubt I could finish the entire thing in two hours even if I had already solved it once. Without the walkthrough I don’t think there’s a player in the world who could finish it in two hours. Now, whenever I make sweeping statements like this I always regret it, and no doubt somebody will follow this up with a post saying “Gee, I had no trouble at all. Finished it in 45 minutes flat!” But let me put it this way: I spent a half hour on the first puzzle (of about a zillion in the game), and only cracked it because of a pretty left-handed hint in the documentation.

That first puzzle reminded me of a game on the archive called +=3. Dave Baggett wrote that game to prove that a puzzle could be entirely logical but also completely unsolvable without hints or random guessing. The puzzle in +=3 is this [and spoiler warnings are beside the point here]: You have to cross a troll bridge, and nothing in your inventory satisfies the troll. The only thing that will satisfy it is if you remove your shirt and give it to the troll — not that the shirt was mentioned in your inventory or that the game gave you any hint the PC is wearing a shirt. A similar thing occurs in the opening sequence of SNOSAE — you have to cut some wires, but you have nothing in your inventory. There are also no takeable objects in the initially limited landscape. None at all. It was only in desperation that I was combing through the game’s documentation and saw that the game allowed the command “LOOK IN”; the docs suggested that the command was useful for pockets. For laughs more than anything else, I tried “LOOK IN POCKET” and what do you know, the game told me “In it you see: A small pair of nail clippers.” Turns out that I’m wearing coveralls, and these coveralls have a pocket — they just aren’t mentioned in the inventory anywhere. Sure, the coveralls are mentioned in the opening text included in the readme file, but I maintain that they are absolutely indistinguishable from a simple scene-setting detail, and that when they don’t appear in the game the player cannot reasonably be expected to know that they’re really there anyway.

Many of the puzzles after this are of the “save-and-restore” variety. “Oh, that killed me without warning. Well, let’s get a hint from this death message and restart.” These sorts of tactics really raise my hackles as a player, because they use the IF conventions I’ve learned against me, and give me no warning they’re doing so. When I solve one, I don’t think, “Aha! I feel so clever now!” I think, “What an irritating puzzle.”

Puzzle expectations aren’t the only IF conventions overturned in SNOSAE. For one thing, it’s a DOS-only program, a PC executable with an apparently homemade parser. Now let me be clear that I always believe in giving credit where it is due for these sorts of efforts. I can’t imagine wanting to build a parser and game engine from scratch, but I recognize that for some it’s a fun exercise, and I certainly understand that writing an IF game from “the ground up” is more work than writing the same game using an established IF language and libraries. On the whole, SNOSAE doesn’t do a bad job, but as usual it’s not up to the very high standard set by Inform, TADS, Hugo, and their ilk. There’s no “SCRIPT” capability, which makes the reviewer’s job much tougher. The “OOPS” verb is missing, which is a minor inconvenience. “UNDO” is also missing, which is a major inconvenience, especially considering how thoroughly this game is infested with instant-death puzzles. On the other hand, there are also some cool things about the interface. It uses colors to nice effect, putting room descriptions in light blue, commands in dark blue, inventory listings in white, etc. It also displays the available exit directions as part of the prompt, like this:

INTERSECTION OF FOUR HALLWAYS: You're at the intersection of four hallways. Down each of these hallways you can see a door. There's a ramp going up into the flying saucer. n,s,e,w,u>

I liked that, although I found it didn’t really add that much to the gameplay experience. There’s also a very cool command you discover about 1/3 of the way through the game which speeds navigation significantly. But all these frills didn’t make up for the missing “UNDO”, especially when the game kept cavalierly killing me off.

The one unblemished positive that SNOSAE has going for it is its sense of humor. This is a game that knows it’s a wacky romp and acknowledges it frequently, usually by breaking the fourth wall and displaying awareness of itself as an adventure game. This tendency is evident almost immediately, when the game describes a door thus: “There doesn’t seem to be a lock on the door! All adventures should start out so easy.” That isn’t anywhere close to the funniest example of the game’s writing, but I couldn’t make a transcript of the thing, and there’s no way in hell I’m slogging through 500 commands again just to find a funnier example, so you’ll have to just take my word on it. I was laughing for much of the time I played SNOSAE, and only part of the time was it at the ludicrousness of entering this game in a competition for short IF.

Rating: 5.0

Down by Kent Tessman [Comp97]

IFDB page: Down
Final placement: 20th place (of 34) in the 1997 Interactive Fiction Competition

Because it’s hard to discuss Down without discussing its premise, this entire review should be considered spoilery.

Well, Down is the first Hugo game I’ve ever played, so I know that many of my initial reactions to it were actually reactions to the Hugo engine and interface itself. These first reactions were mainly positive. I used the DOS version of the Hugo engine, and found that its presentation was clean and asethetic. There were some nice effects available from using colored text, and an attractive menu system. Room descriptions looked good, with bold titles and slight indentations at the start of their descriptor sentences. Having sized up this interface and found it good, I was ready to enjoy Down, a game written (as I understand it) by the same person who created Hugo itself.

Unfortunately, I ran into difficulty right away. The game presents a puzzle within the first few moves, announcing that the player character’s leg is broken, making walking impossible. OK, so what’s the logical solution? How about crawling somewhere? Regrettably, “crawl n” brought the response “You’re not going to get anywhere on just hands and knees–you’ll have to try and figure out some way to walk.” OK, shoot. So I can’t crawl anywhere either. I spent the next 20 minutes trying to figure out how to leave the initial location. Finally, frustrated to the breaking point, I turned to the walkthrough, only to find out that what I needed to do was “crawl west.” Hey, wait a second! I thought I wasn’t going to get anywhere on my hands and knees! I guess I can after all. The game has several instances of this kind of problematic prose, making it difficult to progress without a walkthrough.

However, the story is worth experiencing, walkthrough or not. The author presents a very realistic and highly compelling puzzle-solving situation: you are the survivor of a plane crash. You must help your fellow passengers and somehow prevent the plane from killing you all when it explodes, as it inevitably will. This situation is a natural one for interactive fiction: you must traverse a limited area, under pressure from a time limit, solving very real puzzles with dozens of lives in the balance. Even though there are some problems with the prose and puzzles, it’s still a memorable feeling to crawl through the wreckage, a situation made even more evocative by the fact that it really could happen to most anyone.

Prose: The prose often does a nice job, especially with broad, sweeping tones such as setting up the feeling of urgency associated with the plane and with rendering the human tragedy caused by the crash. It’s in smaller moments that it fails, and the failure is not so much one of tone or voice as it is one of diction. The words chosen are simply not the correct ones to convey what turns out to be the case. For example, a seat is described as “almost against the wall,” but when you look behind it you see a small boy. Well, to me when something is almost against the wall, the distance in between is a matter of inches, certainly not something a child could fit into. Down would have benefited from words more carefully chosen.

Plot: The plane crash is definitely a very strong foundation upon which to build a plot, and Down exploits many things about that situation quite well. Interestingly, however, there are some narrative hooks on which resolution is never delivered. For example, I fully expected to be able to radio for help from the cockpit, so that my fellow survivors and I could get the medical attention that we need. Instead, there wasn’t even a radio mentioned. Also, you meet two passengers (husband and wife), one of whom is injured and bleeding badly. I thought perhaps this was a puzzle, and that I needed to help stop the bleeding. Not the case — apparently they were just there for scenery. The man never gets help from his wound, even at the end. I found this ending unsatisfying, though that’s not necessarily a bad thing. It makes sense that even after serious heroics, survivors of a plane crash would still find themselves in a very difficult situation, but it’s not the kind of resolution I’m used to.

Puzzles: The puzzles in general didn’t make a whole lot of sense to me. I liked the splinting puzzle, since it was logical and fit well into the story’s flow. However, other puzzles like that of the tree lodged in the plane didn’t ring true to me. Would you really set a huge fire inside something that you thought might explode? Wouldn’t you spend your time helping other passengers take shelter in the woods instead?

Technical (writing): I found no errors with the writing.

Technical (coding): The game’s implementation was solid as well.

OVERALL: A 6.3

E-MAILBOX by Jay Goemmer [Comp97]

IFDB page: E-Mailbox
Final placement: 27th place (of 34) in the 1997 Interactive Fiction Competition

Well, if there’s a prize for shortest competition game, E-MAILBOX will win it hands down. Clocking in at just under ten minutes, it barely gets off the ground before telling you either that you’ve won or that you’ve just met your death by having your body’s cells torn apart from one another. Not much of a menu, but at least either way the end comes quickly. The game purports to be “A true story based on actual events that occurred to a real individual,” but is written in a broad, exaggerated tone that is probably meant to be burlesque. It’s funny, in a limited kind of way, but it’s hard for the game to do very much when it ends so quickly.

One thing that it does do well is proves that an AGT game can hold its own in a modern competition. E-MAILBOX is short, yes, but it’s fun while it lasts. I used Robert Masenten’s AGiliTy interpreter for the first time, and found that it produced output that was well-formatted, easy-to-read, and even sometimes (gasp!) aesthetically pleasing. The game achieves a few nice special effects — nothing that couldn’t have been done with Inform or TADS (I don’t know enough about Hugo to say one way or the other) but nothing to sneeze at either — and generally works imaginatively with the text format. Of course, one wonders whether E-MAILBOX was kept so short in order to disguise the limitations of its programming system. There is virtually no navigation within the game, and the very linear design prevents most parser experimentation. Thanks to the handy AGT counter, I know that E-MAILBOX has a grand total of 4 locations, some of which only respond to one command. This game is a brief bit of fun, but the jury’s still out on whether AGT can match up to more modern systems when it comes to more substantial works.

There are some interactive fiction games that are epic, and may take even a great player a three-day weekend to complete (without looking at any hints, of course). Then there are those which could take up a day or two, and those (many of the competition games, for instance) which might fill a long lunch break. Play E-MAILBOX over a 15 minute coffee break. You’ll have some fun and still have time for a brisk walk.

Prose: I found the prose in E-MAILBOX to be pretty over-the-top. As I say, I think it was intended as burlesque, but its outrageousness seems forced. It comes across as the prose of a voice which is promising, but has not quite fully matured. It’s not exactly the sophomoric arrogance of something like Zero Sum Game — more an overly sincere zaniness.

Plot: The plot is so short and simple that it’s hard to tell much without giving away the ending. Basically, it centers around trying to send an email message. (See, I told you: short and simple.)

Puzzles: Well, I never found anything that I thought really qualified as a puzzle. The actions necessary are either entirely obvious, or entirely obscure but well-prompted by the parser.

Technical (writing): I found no errors in E-MAILBOX‘s writing.

Technical (coding): As I said above, the game does a nice job for something so short. The author makes an AGT game fun to play, which in my experience is no small feat. A well-implemented piece of work, short work though it may be.

OVERALL: A 5.8