Phantom: caverns of the killer by Brandon Coker [Comp05]

IFDB page: Phantom: Caverns of the Killer
Final placement: 31st place (of 36) in the 2005 Interactive Fiction Competition

Right up front this game starts sending out the red flags. There’s the fact that its title isn’t in title case. There’s the fact that the debugging verbs are left on. (Not that I remember how to use them decades later.) And then there are the opening sentences:

Legends speak, of a great egyption warrior. Who rose in the military ranks faster that any other.

So, whew, just very rough right away. I dialed my expectations down, way down, and kept playing. Here is an advantage to playing the comp games outside the comp period — it had been about 6 months since I played Dreary Lands. Consequently, my patience account had built back up, enabling me to battle through the terrible writing and nonsensical milieu, looking for some things to appreciate.

The impression I got was of a very, very young author (or at least one who hadn’t done a lot of writing or received a lot of feedback), more attuned to the programming part of IF than the writing part. This is a demanding medium, in that it requires authors to be skilled in two traditionally separate areas — prose storytelling and coherent code. Phantom has its problems with the latter (though much less so than, say, Dreary Lands), but falls down very badly on the former.

The result is a game that tries to horrify, but keeps stumbling into unintentional comedy. Horror in particular is a tough genre for an author lacking basic skills, though it’s apparently an attractive one for such authors as well — see Exhibit A, Rybread Celsius. In order for a reader to be scared or creeped out by a fictional world, she’s got to be able to suspend disbelief about that world, and under an avalanche of prose errors, it’s pretty difficult to suspend disbelief.

Another obstacle to believing in Phantom‘s world lies in the weird numbers that occasionally pepper the text. For example:

>open black box
The box opens but a hand comes out grabs your face and squeezes the blood from your veins.1

“1”? I mean, the death message is a little comical as it is, what with the way a hand to the face somehow causes circulation problems, but the “1” afterwards is clearly just a mistake, or maybe a debugging leftover. Given that there’s a “2” that appears after the winning ending, I’m guessing this has to do with the game setting Inform’s death message flag, and maybe printing it out either by mistake or as a way of making sure the right message prints, or something.

Then again, it’s not just death messages — there’s also this:

You can see a Large emerald here.
1

>x 1
(the Large emerald)
A very large finely cut emerald.

Really not sure what’s going on here, but it did give me a good chuckle.

In any case, Phantom seems like a well-intentioned attempt by someone who does not have control of his tools. I’d prescribe some intense focus on learning basic English mechanics, hopefully with instructional support, and a lot of beta-testing to root out weird code behavior, in order to produce a much improved next game. Or at least, that’s what I would have prescribed 17 years ago — I guess now I’ll just call it general advice.

Rating: 3.6

Future Boy! by Kent Tessman [IF-Review]

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

IFDB Page: Future Boy!

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.

Beyond Zork [Infocom >RESTART]

IFDB page: Beyond Zork
[This review contains many spoilers for Beyond Zork. I’ve written an introduction to these Infocom >RESTART reviews, for those who want some context.]

To play the next game with the Zork brand, Dante and I jumped forward five years, from 1982 to 1987. By this time, Infocom was well-established and successful, but it also found itself reckoning with trends in the computer game industry that threatened interactive fiction, and prominent among those was the CRPG, the Computer Role-Playing Game.

>CONNECT IF TO RPG

As I said in the Zork I review, Zork was created in the shadow of Adventure, which itself was in the shadow of Dungeons and Dragons. Adventure co-creator Will Crowther was partly inspired by his experiences in a D&D group — one which apparently included Zork co-author Dave Lebling! — to combine his caving experiences with his gaming experiences. Zork, in turn, included randomized combat with the troll and thief, though it turns quickly away from the D&D model into something more static and puzzly.

In the meantime, game developers continued to make inroads on replicating the D&D experience via a computer. The Ultima and Wizardry series got their starts shortly after Zork I was released, mapping the initial territory of the CRPG. These games were much lighter on description and puzzles than Infocom’s work, but they offered the joys of hacking and slashing your way through hordes of monsters, and gradually increasing in power as you do so. It took quite a while for a game to surface with the actual D&D license, but the way having been paved by the CRPGs of the early and mid-Eighties, it was only a matter of time before two of the big geek trends of the era combined.

That first D&D game was called Pool of Radiance, which brings us in a rather roundabout way to Beyond Zork. This game is Infocom’s attempt to bridge the gap between IF and CRPG, and in fact it includes an actual pool of radiance. The connection seems far too on-the-nose to be coincidental, but it’s true that the D&D game didn’t come out until 1988, whereas Beyond Zork was released in 1987. Perhaps Brian Moriarty, the author of Beyond Zork, knew the D&D game’s title in advance and decided to write an anticipatory homage? In any case, while Beyond Zork tries to bridge a chasm betwen two genres, it also itself features a chasm whose bridge cannot be crossed. Moriarty’s subconscious may have been telling him something, because the connection between IF and CRPG is a pretty uncomfortable one, at least in Beyond Zork.

Like most RPGs, this game starts out by asking you to build a character, and Dante and I obligingly did so. We named him Azenev. (If you know Dante well, you might guess that this is an N.K. Jemisin reference, and you’d be right. It’s a backwards spelling of a character name from Jemisin’s The City We Became.) We built Azenev from six attributes: endurance, strength, dexterity, intelligence, compassion, and luck — a pretty close mapping to D&D‘s strength, intelligence, wisdom, dexterity, constitution, and charisma. Here’s where Problem Number One surfaced: we had no idea which attributes would be important. We tried to make him pretty balanced, though Dante felt like luck could make a big difference in everything, so we poured some extra points into that.

Well, it turns out that luck doesn’t seem to make a substantial difference in very much of anything, so Azenev version 1 met his demise almost immediately. One would hope that with a balanced character you’d be able to survive and thrive in an RPG, but not in this one. Apparently endurance is the key stat, given that attacks reduce it and you die when it runs out. So we rebuilt Azenev with more endurance and less luck, but still didn’t fare much better, because of Problem Number Two: monster mismatches.

In a typical RPG, be it computer or tabletop, your character starts out weak — level one. With a character like this, you can’t go out and fight dragons or ogres, so a well-designed game throws you some monsters you can handle — maybe big spiders, or little goblins, or medium-sized rats. When you conquer those, eventually you level up, and can face the next tier of danger, continuing through that cycle until you finally can smite mighty dragons.

Image from the Beyond Zork feelies, describing the cruel puppet and the dust bunnies.

Beyond Zork allows players no such accommodation! You start at level 0 (even weaker than level 1!), but you can encounter powerful adversaries at any time, with no real way to tell how powerful they are, except how fast they kill you. One of the first monsters we ran into is called a “cruel puppet”. It’s an entertaining enough creation — a marionette-looking thing that drains your endurance with vicious insults. But it is in no way appropriate for a zero-level character to face. Dante and I died over and over and OVER to the cruel puppet. We died after using a healing potion. We died after figuring out how to wield our weapon. We died after leveling up our character. We died after upgrading our weapon. We died after retreating to heal and then coming back. We just. Kept. Dying.

This is not fun, but I think I understand why Moriarty designed the game this way. He was wrestling with the tension between Infocom’s bias towards large-world exploration and the RPG’s tendency to tailor the story and encounters towards the character’s level. In addition, he was trying to reconcile IF’s narrative qualities against “crunchy” RPG mechanics that show you things like the level, attack power, defense strength, and health of everybody in the fictional world. Getting to explore the whole world right off the bat meant that we could easily and quickly wander way out of our depth, and leaning towards IF narrative meant that we had none of that crunchiness available to tell us that we’d need to be much more powerful before venturing in.

Defining the problems suggests the solutions. Maybe the game could have scaled encounters to character level, so that any monster you meet is just powerful enough to present a reasonable challenge. Maybe it could have shown more stats on monsters — as it is, the only way to tell a monster’s health is by examining it, and not only does that cost you a turn where the monster can attack you, it also gives vague descriptions like “gravely wounded” and “seriously wounded” — which is worse? Or maybe it could cordon off areas of the game until you’re powerful enough to face them. The trouble is, Infocom likes to cordon off game sections with puzzles, and your ability to solve a puzzle has little bearing on the power of your character.

There is an area where Moriarty blends all these things quite successfully: the cellar of the Rusty Lantern inn. You enter this cellar in search of a particular bottle of wine, and the cook slams and locks the door behind you. In the course of exploring the cellar, you’ll encounter low-level monsters that can be defeated by a weak character, treasures that can be sold to buy better gear, magic items that also upgrade you, and a means of improving one of your character’s stats, in this case dexterity. Staying alive in the cellar and getting out of it require puzzle-solving, and when you emerge you’ll likely have leveled up, improved your stats, and acquired some good loot. It’s very satisfying!

I’m inclined to think that maybe Beyond Zork should have forced that sequence first, or at least steered us toward it much more emphatically, rather than letting us traipse around a bunch of set pieces that were much too hazardous for us. In fact, if the entire game had been structured as a series of these compact mini-games, with interconnections between them and a common landing place to buy gear, that would have gone a long way toward settling the conflict between the IF and RPG conventions.

However, that on its own wouldn’t have been enough to deal with Problem Number Three: challenges that depend on stats. In trying to meld RPG mechanics with traditional IF, Moriarty runs into serious friction between the two, created by basing story barriers around the character’s attribute scores. In a tabletop RPG, each character has strengths and limitations, but multiple characters bind themselves together into a party who balance each other out. In IF, the character is solo, but typically not bound to attribute scores, so they are a purer proxy for the player’s puzzle-solving. So in a solo RPG, the PC’s limitations remain unchecked, which risks making certain barriers difficult or impossible to pass. Solo CRPGs typically manage this by adding numerous NPCs to the player’s party. Solo tabletop RPGs are certainly possible, but they require a DM or an adventure that is flexible enough to shape the story around that one player’s character. Beyond Zork does neither of these things, and therefore the elements never quite jell.

For example, if your intelligence score is too low in Beyond Zork, you’ll be unable to read the magic scrolls that are critical to solving certain puzzles. There’s no brainy wizard in your party to help out, so a low score in that stat means you’re just out of luck. (Your luck stat does not help.) Now, there are ways to possibly make up these deficits, and in the case of intelligence, one gets provided for free, though Dante and I still lost access to it, for reasons I’ll explain later. For other attributes and weaknesses, though, the improvements tend to cost money, and the game’s major source of money is locked behind its worst puzzle. More about that later, too. Other times, the improvements are locked behind layers of puzzles, none of which are terrible but due to the interwoven nature of everything, it’s very difficult to get past those puzzles until you’ve defeated the enemies that you needed the improvement for in the first place. The strength-enhancing morgia root is a perfect example of this — only available after large portions of the game have already been conquered, by which point it makes little difference.

Cover of Beyond Zork

There’s a Problem Number Four, or perhaps Problem Number Zero, because it’s fundamental to the others: hidden mechanics. If you’re playing a tabletop RPG, the rules are available. Sure, the DM may have some nasty surprises in store for you, but everybody is playing from the same set of books. Now, there’s a discussion about metagaming to be had here. Metagaming, for those who don’t know, is the term for when a player makes decisions based on information that would be unavailable to that player’s character, such as, “I’ve read the Monster Manual, and I know that the cruel puppet has 200 hit points, so my character runs away.” This sort of thing is emphatically frowned upon in RPG circles. So it’s fair enough to say that the game master (or game designer as the case may be) must keep some things hidden in order to keep the narrative’s boundaries logical. However, at least for Dante and I, understanding the mechanics behind this game’s pronouncements would have saved us a lot of frustration.

For instance, there’s a scrystone (read: crystal ball), about which we’re told: “Visions of things yet to be lie within its depths, for those with enough wit to see them.” When we look into it, we just see an “unintelligible swirl.” Well that sure sounds like we need to boost our intelligence stat, and hooray, we know just what to do — let’s buy that Potion of Enlightenment and drink it. So we do that, it boosts our intelligence stat, we look in the scrystone again, and… our boosted intelligence makes zero difference. Now, behind the scenes, it turns out that the scrystone requires an extremely high intelligence, and there is only one item in the game that provides that kind of massive boost. Without understanding that requirement, though, we were left to feel that the game simply misled us, and that improved intelligence is not the way to solve the puzzle.

>KILL INVENTORY LIMIT

For our entire playthrough, we found ourselves frequently guessing blindly at how our stats were affecting gameplay. For example, would this game’s extremely annoying inventory limits have been relieved had we had more strength or dexterity? Because if so, boy oh boy would I have maxed those stats. I ran into more infuriating inventory limit nonsense in this game than in any other Infocom game before or since in this >RESTART series. Here’s a prime example — we’re wandering through the market when somebody drops a “fish cake”. We’ve read in the feelies that eating fish increases intelligence, so we want that thing. But…

>n
"Oof!"
The street hawker you just bumped into glowers. "Watch where I'm goin', will ya!" You clumsily help to pick up her spilled wares; she stomps away without a word of thanks.
As you dust yourself off, you notice something lying in the dust.

>get fish cake
Your hands are full.

>put all in pack
The scroll of Fireworks: Done.
The potion of Forgetfulness: Done.
The rabbit's foot: Done.
The staff of Eversion: Done.
The scroll of Mischief: Done.
The bit of salt: Done.
An alley cat races between your legs, snatches the fish cake and disappears into the crowd.

ARGH! Tightly timed object availability plus clunky inventory mechanics equals super frustrated IF player. (Also, I wonder how it is that I help her to pick up her spilled wares if my hands are so full?) By this time in our play session, Dante and I had made a fair bit of progress but hadn’t saved recently; we just didn’t have the appetite for replaying through all of it just to make sure we bumped into a totally sudden and arbitrary encounter with our hands free. We decided to just forego the intelligence boost, since we were at least able to read. That did make for a moment, though, after the potion of Enlightenment failed to help us read the scrystone, where I wondered through my curses if we had been blocked from winning the entire game due to a frickin’ inventory limit early on.

You may note that the game provides a pack. This is very helpful! However, Infocom never quite got to the point that Graham Nelson reached in the Inform libraries, where not only does the player carry a sack object, but the game automatically handles all the tedium of putting something old into the sack when the PC picks up something new. Consequently, we’re unable to grab that fish cake even though we know exactly how to do it.

We ran into this very same issue when trying to accept the goblet from the Implementors. A group of gods tries to hand us a holy object, and Beyond Zork is hitting us with, “Your load is too heavy.” By this point, we were carrying enough around that even the pack didn’t help. (That’s right, it too has a limit.) The Implementors get more and more annoyed at our “contrariness” in not picking up the goblet, and they eventually force it into our hands, only for it to immediately clatter to the ground again. The hilarious part is that if anybody should understand why we can’t pick it up, it should be the Implementors! God how I would have loved it if one of them had said, “Oh hey, looks like his load is too heavy. Let me just do away with that problem forever so he can take this nice goblet.”

Instead, the pack helped just enough with the problem of carrying things that we weren’t using our previous Zorky method of leaving a bunch of stuff at one location, but it didn’t help so much that we didn’t still find ourselves unable to pick up things in timed situations. In fact, about three-quarters of the way through the game, we did resort to our old Zorky ways, leaving a pile of objects at the Hilltop starting location.

Part of what made our inventory so dang full was the profusion of items in this game. Magic items abound — scrolls, potions, and all manner of point-and-enchant doohickeys. There’s a cane, a wand, a rod, a stick, and both a staff and a stave. The identity of these items changes from one playthrough to the next — you might find a stave of Sayonara in one game, but if you restart you could end up with a stave of Dispel. That’s one of several ways that Moriarty brings in the RPG trope of randomness.

The "Southland of Quendor" map from the Beyond Zork feelies

Of course there’s the randomized combat — get lucky enough with your hidden dice rolls and maybe you can overcome that strong monster in your way. (Not the cruel puppet, though. Never the cruel puppet.) But even beyond that, items are randomized, and the very landscape is randomized. Though the general layout of regions in Beyond Zork is a constant, the internal geography of those regions varies by playthrough. The geographical randomization works pretty well, thanks in part to the handy onscreen map provided. For each region (forest, swamp, jungle, etc.) Moriarty provides a grab-bag of locations with evocative names and descriptions, and then the game decides randomly (within set parameters) how they’re laid out in relation to each other in that region. Then within those locations, items and monsters are also placed randomly. This can sometimes affect difficulty, such as when two key areas that interact in a puzzle get randomly placed far apart, but for the most part it just adds flavor.

Randomization of items can be a little more frustrating, as it can determine whether a certain item is just lying on the ground, or whether it costs money in a shop. In the latter case, you have to defeat some monsters and gain some treasures in order to purchase said item. As I’ve mentioned, that’s not always so straightforward a task with an under-leveled character.

>CRY ABOUT TEAR

Now that we’re back to the topic of purchasing, let’s dig into the puzzle that nearly ruins this game: the Crocodile’s Tear. In my first encounter with Beyond Zork, as a teenager in the 1980s, this puzzle really did ruin the game for me — I abandoned the whole thing after a long struggle. Abandoning a game was quite a last resort in those days, as it had cost a lot of money to acquire, and I had pretty much unlimited time to spend on it. But after a year (not exaggerating) of on-and-off struggling against this puzzle, I simply could not find a way through it, and there was no Internet full of answers to consult. By that point, I was too disgusted to consider buying Invisiclues. I felt like somehow the game wasn’t playing fair with me, and I turned out to be correct.

When Dante and I encountered the puzzle, there was no question that we’d get through it, just a question of whether we’d need to consult hints — easy enough to do in the 21st century but still a sign of failure on someone’s part, either the game’s or ours. But like my teenaged self, Dante could not solve the puzzle on his own, and I must have repressed the solution, because I needed a hint too.

I’ll break this puzzle down, but first a little digression to give some background. Recall that one of the PC’s attributes is a compassion score. This seems like a bit of an odd stat for an RPG — it’s certainly not any good in a fight, and it doesn’t seem to help with using magic or solving puzzles. (Turns out it matters in the endgame, but there’s obviously no way of knowing that until you reach it.) You can boost your compassion score, though, by doing compassionate things, like rescuing a unicorn locked in a stable, or saving a minx (cute cat-like creature) from a hunter. These scenes are written and constructed beautifully, particularly the minx. Rescuing these poor creatures and raising our compassion is far more heartstring-tugging than anything in the original trilogy. (It helps that we have a very fluffy cat at home, who does not say “minx” but might as well.)

Keep all that in mind as we talk about the Crocodile’s Tear. The Tear is a legendary sapphire, found in Beyond Zork‘s jungle section. It’s worth much more money than all the other treasures in the game put together. You find it attached to a huge stone crocodile idol, at the back of the idol’s gaping maw. Trouble is, when you climb the lower jaw to get to the jewel, the jaw tilts like a seesaw, making it so that you can’t quite reach the treasure, and when you lean too hard, the jaw tilts backward and drops you into the idol’s interior.

So far, so fair. Maybe we need a stick to reach to the gem, or a projectile to knock it loose, or a counterweight to allow us to keep climbing the jaw after we pass its fulcrum. We tried all these things, in many permutations. We were especially hopeful when we acquired a sea chest, which is definitely both heavy and bulky — I’ve got the painful inventory management transcripts to prove it. We set that sea chest on the maw — which the parser allows without complaint — but it did absolutely nothing to counterbalance us. Sigh. Finally, after lots of failed attempts at getting this jewel, we turned to the hints, and were shocked at the intended solution.

Pages from the Beyond Zork feelies describing the hungus and spenseweed.

See, nearby the idol (well, nearby or a ways away, depending on how the jungle region was randomly laid out) is a heart-rending scene. A mother hungus (part hippo, part sheep) is with her baby. The baby is trapped in a pool of quicksand. The mother gazes anxiously at the baby. She bellows impotently, and the baby responds. If you should walk away, the baby hungus bellows mournfully. Well, the answer to this one is obvious. We’ve got a stick of Levitation, so we point that at the baby hungus, and this happens:

The baby hungus bellows with surprise as he rises out of the quicksand! Sweat breaks out on your forehead as you guide the heavy burden over the mud and safely down to the ground.
The ungainly creature nuzzles you with his muddy snout, and bats his eyelashes with joy and gratitude. Then he ambles away into the jungle to find his mother, pausing for a final bellow of farewell.
[Your compassion just went up.]

Fantastic! We’ve raised our compassion again. What does this have to do with the Crocodile’s Tear, you may be asking? Well, it turns out that the solution to that puzzle is to attack the baby hungus while it’s stuck in the quicksand. (Strangely, attacking the baby hungus does not make your compassion score go down, though it surely should.) That gets the mother mad enough that she’ll chase after us, and if we climb onto the stone maw, she’ll stand on the other end, counterbalancing it so we can get the jewel.

We found this outrageous. The notion of attacking a baby animal in peril is so completely against the grain of everything else Beyond Zork asks us to do, and so generally repellent, that it absolutely should not be the solution to anything. Not only that, doing the compassionate thing actually makes the game unwinnable! Let me say that again: saving a baby animal from dying (or at least, doing so before attacking it first) ensures that you cannot win the game, because the hunguses disappear from the game after you rescue the baby. This might be the worst puzzle in the entire Infocom canon. It’s all the more surprising coming from Moriarty, who had already done such brilliant work in Trinity exploring player complicity and moral culpability with an animal-killing puzzle. Here, instead of a metaphorically freighted moment of tragedy, the animal cruelty is treated as a mere mechanical device — it’s both disappointing and baffling.

If you’ve read other entries in this series, you might recall that every Zork game so far has forced Dante and I to restart, for one reason or another. Well, this puzzle forced us to restart Beyond Zork, because of course it did. Who attacks a baby animal before saving it? Actually, this was the second time we’d had to restart. The first was caused by a different sort of inventory limit — magic items that only had a limited number of uses. Certain areas of the game are unreachable except via these items, and if you run out of “charges” for them before you’ve solved everything in the area, it’s off to restart-land you must travel.

>ENJOY GAME

So, that was a lot of ranting. I’m out of breath. Let me wind this up by talking about some of the things we really enjoyed in Beyond Zork, of which there were really quite a few, despite all my complaints above. I haven’t spoken at all about the game’s primary technical innovation, a multi-windowed display which always shows a boxes-and-lines map and relevant information such as inventory contents, room description or character stats alongside the game’s main text. That’s how, in the text above, we knew to say “get fish cake” even though the transcript only said “you notice something lying in the dust” — the room description window identified the fish cake. This display was very slick for an Infocom game at the time, and still works pretty well. I think my favorite thing, though, is the way you can use the number pad to navigate — for instance, pressing 8 on the number pad automatically enters “NORTH” and a carriage return into the parser. Combined with the map, this was an awesomely fast and easy way to get around. I wish more IF games did it now.

A screenshot from Beyond Zork, showing the onscreen map, the description window, and the parser interaction below both.

Another highlight of the game is its humor. Moriarty knows his way around a joke, such as this bit from a gondola conductor, which continued to amuse us throughout the game, despite how many times we saw it:

“Thirsty?” asks the conductor. “Stop by the Skyway Adventure Emporium for a tall, frosty Granola Float.” He smacks his lips dispiritedly. “Mmm, so good.”

Moriarty also does a lovely job of tapping into the general joy of Infocom’s tone and culture. By 1987, a whole lot of love had gone into the Zork universe — although this was the first game to carry the “Zork” name since Zork III, there were several intervening games set in the milieu that filled the gap, namely the Enchanter series and Moriarty’s own Wishbringer. With all this history established, Moriarty can draw on quite a few sources for references, jokes, and general explanations of what’s going on.

Now, we hadn’t played all those other games at the time we ran through Beyond Zork, so many of the references were lost on Dante, and sometimes only dimly recalled by me. But writing this review now that we’ve played them all, I can appreciate the game’s easy command of Enchanter-ese, such as “yonked a girgol just in time.” There’s another mailbox, with another leaflet, this one yielding a burin, which is a co-star of Spellbreaker, the game at the other end of the Zork spectrum. The unicorns all wear gold keys around their necks, a la Zork II. The boot crushed by the farmhouse is quite reminiscent of the Boot Patrol in Wishbringer, and the platypus recalls that game’s feelies, not to mention being emblematic of Moriarty’s sense of humor. All these allusions gave us (especially me) that warm insider feeling of, “Hey, I understood that reference.” Similarly, the scenes of recent or future Infocom games visible in the scrystone (Hitchhiker’s Guide, Zork Zero, Shogun) are a delight.

There are plenty of good puzzles in the game, too — it isn’t all attacking babies. This was our first game with copy protection via feelies, and it was a lot of fun leaning on The Lore and Legends of Quendor to help solve puzzles. The dust bunnies and dornbeast were particularly successful examples of this. The gray fields area is another pretty successful puzzle box. We appreciated the way it unfolds in layers — first entry, then understanding the scarecrows, then figuring out the use of the sense organ, and finally the Wizard of Oz sequence, relying on what you’d learned in the other parts. The subtle changes with the corbies and the corn are the kind of thing that work gangbusters in text but would be very hard to pull off with the same nuance in graphics.

Overall, we had a lot of fun with Beyond Zork despite its flaws, and I looked forward to replaying the next Infocom Zork game — the most technically sophisticated of them all, and certainly the biggest. Ahead of us was final Zork game from Infocom as an actual artistic ensemble rather than just a brand name, though in another way, it was the first: Zork Zero.

Bellclap by Tommy Herbert [Comp04]

IFDB page: Bellclap
Final placement: 17th place (of 36) in the 2004 Interactive Fiction Competition

When I wrote LASH, I was interested in the concept of separating the player from the PC. Thus, instead of the traditional IF second-person voice, it used first person, and made “me” refer to the player while “you” referred to the PC. Now, Bellclap goes one more step by separating the player, the PC, and the parser. In this game, you (the player) are apparently some sort of god, and you’re answering the prayers of a supplicant (the title character and PC.) However, the two of you are working through an intermediary — it’s never made quite clear what or who this is, but there’s definitely some kind of third party relaying your commands to the PC and reporting the resulting actions back to you. It’s the parser personified, basically, as some kind of angel or holy spirit, though its diction is more that of a bureaucratic functionary.

The game speaks mostly in the third person, because it’s mostly relaying information about the PC, but the parser speaks in first person when referring to itself, and in the second person when referring to the godlike being at the controls. For example:

>x me
He can't see you, sir. You're in light inaccessible, hid from his eyes.

Unless that instruction was intended for me, in which case you're looking radiant, sir, radiant.

>x bellclap
He is dressed in a tunic, sheepskin coat and sandals, and he has a bag in which he carries food and tools for the maintenance of walls, fences and thatch.

>x you
He can't see me, sir. I'm more a sort of guiding voice.

I thought this was a really fun experiment, and Bellclap carried it off quite well. It seems clear that a fair amount of work and thought went into overhauling the standard Inform libraries to reflect this unique split consciousness, and the result felt seamless to me. Sadly, the game was quite short — just a few puzzles strung together, really — and therefore it didn’t explore the gimmick nearly as much as it could have. Also, I’m not sure that making the player an omnipotent being was the best course, as the most obvious solution to pretty much all the problems would have been to just exercise some divine power over them. The game declares these sorts of actions verboten for no apparent reason other than that they’re not implemented.

Consequently, I was left feeling not very godly, even though some of the PC’s actions result in supernatural events. Actually, the scenario put me in mind of the M*A*S*H episode where Father Mulcahy is stuck in a remote location with a wounded man and must perform a tracheotomy, while Radar relays Hawkeye’s radioed instructions on how to do so. That scenario had a tension that Bellclap lacks, not just because of the urgency and life-or-death nature of the operation, but because the knowledgeable party was powerless to exercise that knowledge directly, and the person who was capable of action was crippled by inexperience, while both had to deal with the comically squeamish middleman.

In Bellclap, there’s no clear reason why the knowledgeable party should be powerless — just the opposite, in fact, since the game clearly establishes him as all-powerful. For people exploring this structure for IF in the future, I think a stronger design would exploit rather than undermine the difficulty inherent in the separation of commander, relayer, and actor.

As for the rest of the game, it’s pretty good, though as I said, there’s really not too much to it. The prose strikes a strange pseudo-Victorian tone that works despite itself, and occasionally gets off some excellent jokes, such as when I tried to make Bellclap go up from a roof:

>u
But gravity, sir. Gravity. They're your physical laws, not mine.

I also really enjoyed the response to JUMP: “Bellclap wants to know how high.” The writing was blessedly error-free, but the coding was just a little weaker. Most of the game was quite solid, but I encountered a couple of situations that the game mishandles. The worst offender is a puzzle that requires a container to be filled with liquid, but doesn’t properly recognize the word FILL. Instead, the game wants a command syntax along the lines of PUT LIQUID IN CONTAINER, which is both anti-intuitive and anti-mimetic.

Speaking of puzzles, I thought these were pretty good too — most of the solutions were quite unexpected, but they made sense in retrospect. Bellclap gave me the strange sensation of solving puzzles even though I had no idea why the solution would work, which I suppose is as close as I’ll ever get to omniscience. I was sorry when the game ended so soon, and I’m certainly looking forward to future works by this author.

Rating: 7.8

Blink by Ian Waddell [Comp04]

IFDB page: Blink
Final placement: 21st place (of 36) in the 2004 Interactive Fiction Competition

Blink claims to have multiple paths. According to its ABOUT text, there are “several instances throughout the game where you can quickly switch to a different path by saying something different or doing something else.” This is simply not true, at least not as I understand and define the idea of multiple paths. Yes, there are a couple of conversations whose outcomes can be altered by various menu choices. However, none of these alterations have any impact whatsoever on the story, which is quite linear. There aren’t even any points where the game offers more than one goal at a time — everything is very much on rails, and any deviations from the path result in either gentle rebukes from the parser or a little bit of scenery description.

I know this, because after one trip through the game, I went through it five more times looking for the alleged paths, only to find myself always in the same sequence of scenes, each of which has only one exit. Finally I ran it through TXD and looked at all the game text, and sure enough, I’d pretty much seen the whole thing. The experience led me to think about what we mean by “multiple paths.” In a sense, there are multiple paths through even the tiniest IF game. Even in an Inform shell game, you can, say, SING and then PRAY, or PRAY and then SING. Strictly speaking, these are two different paths. However, since both of them simply result in default parser responses, neither of which affect the game world or the PC, they are functionally equivalent. That’s the way Blink is — sure, there are different ways to go through it, but none of those differences are significant. The game’s story, and its ending, are identical no matter what you do, and thus I would contend that it only has one meaningful path.

Even that path is a short one — Blink is a small game, and that’s another one of its problems. Not that smallness is a problem in IF per se, of course, but Blink‘s main project seems to be to provoke an emotional response in the player, and it’s just too bare to provide the necessary connection. The specifics are too spoilery, but at its base, the game presents a PC who is confronted with the specter of loss, and thus must reevaluate some of his past decisions. However, when we barely know any of these characters, all they can be is unadorned archetypes, and those aren’t enough to create character identification. Plenty of affecting stories boil down to something like “boy meets girl, boy loses girl”, but if the actual story is just those six words, then it’s not going to affect anyone. Of course, Blink isn’t this extreme, but it’s still insufficient in the end, and consequently its methods feel hamfisted and overbearing.

Additionally, there are a few places in the game that are hampered by awkward diction or bad coding, and in a game this size, those problems loom large. For instance, there’s a conversation that starts with a question, and then when you try to TALK TO the character, the parser tells you that you have nothing to say, even as the conversation continues. An example of the diction problems is the creek is described as the “epicentre of the entire forest.” Aside from the peculiarly British spelling from what is clearly an American PC, “epicenter” is a term that refers specifically to the center of an earthquake’s shock waves — it’s not just a synonym for “center.”

Still, there are things to like about Blink. The implementation is thorough, with all first-level verbs implemented carefully. The plot’s rails are constructed well — that is, whenever the game prevents the PC from taking a divergent path, it generally provides a pretty good reason. The story coheres well enough, and I liked the fact that the PC begins geriatric, and then progresses backwards through his life via flashback. In fact, there are the seeds of an excellent game in Blink. If it really had offered multiple paths, it could have been a compelling presentation of difficult choices, a la Tapestry. Even if it had remained on rails but its story and characters had been better fleshed out, it might have made a pretty moving character study. In its current state, though it’s nicely implemented and it hangs together okay, it feels falsely advertised, and there’s just not enough meat on its bones.

Rating: 5.5

Goose, Egg, Badger by Brian Rapp [Comp04]

IFDB page: Goose, Egg, Badger
Final placement: 12th place (of 36) in the 2004 Interactive Fiction Competition

One of my favorite things about interactive fiction is its ability to surprise me. Not only can IF deliver all of the surprises available to static fiction — plot twists, unexpected turns of phrase, and so forth — but it can also delight me by understanding a command that I never thought it would, or by altering its internal objects in a way that casts new light on the story, and sometimes on the medium itself. Goose, Egg, Badger offers both kinds of surprises in abundance. The former are difficult to talk about, since I don’t want to reveal any spoilers, so let me focus on the latter for a bit.

GEB kept on thrilling me with all the things it understood. Over and over, I’d try a kooky verb and find that the game handled it with a response that was usually funny and occasionally even useful. It’s clear to me that a whole lot of effort was poured into expanding Inform‘s standard library of verbs, and the result is a parser that kept making me smile and say, “Wow!” In addition, many standard Inform library responses have been replaced with whimsical substitutes, to great effect.

Besides the good parsing, GEB introduces a handy goal-tracking device, similar to the to-do list from Shade: throughout the game, an “urge” remains in the PC’s inventory. Examining the urge will give a clue as to what the player’s current goal ought to be. The innovation works well in this game, though I found it to be slightly buggy — on occasion, it seemed to be urging me to do something I’d already done. In addition, its contents are sometimes too vague. This problem may be unavoidable when some of the puzzles involve performing a wholly unexpected actions rather than combining mundane actions to achieve a desired result, but I found it sometimes vexing nonetheless.

In fact, the main problem I had with GEB was that while its implementation is terrifically robust, I often found its writing a little insufficient. One stylistic choice that didn’t work too well for me is that GEB changes all room descriptions after the first visit. This approach can work well to help characterize a PC who is very familiar with her surroundings, as is the PC of GEB, but I found myself floundering without exit lists, and frequently checked the scrollback because of the nagging feeling I’d missed something. Even with a PC who knows the lay of the land, a game’s room descriptions should still meet the minimum standards for IF: mention of all important nouns and exits.

Similarly, if you embed clues in your prose, that prose should be repeatable without too much trouble. This is one of those rules to which there are a bunch of exceptions, but I what I found in GEB is that occasionally an important bit of information is smuggled inside a description that prints once and once only; when the hints intimated that I should have seized upon this clue, I felt a little indignant. One other area in which the game is a little under-described is in its depiction of certain NPC actions. In particular, there’s an NPC who follows the PC around, but this action is never mentioned by the game beyond the fact that if you do a second LOOK in the current room, you’ll find that the NPC is there with you. This should have been made a little clearer.

This obliqueness affects some of the puzzles — in fact, there’s one object on which the game offers so little information, it’s a bit of a puzzle just to figure out what the object is. Despite this, many of the puzzles are quite nice indeed. There some arbitrariness here and there, and every so often a situation will come clear out of left field, but I can’t deny that I thoroughly enjoyed winding my way through the game. GEB rewards experimentation, and thanks to the deep implementation, there are a lot of things to try, some of which may succeed in totally unforeseen ways.

In addition, the writing does an excellent job of balancing humor and scattered surreality — I particularly enjoyed that the ape in the game has a theme song, and that the SING command prompts the PC to sing that theme song. Best of all, though, is the extremely clever conceptual gimmick at the heart of the game. It was subtle enough that I got through and enjoyed the whole game without recognizing it, but interesting enough that once I figured it out, it opened up new vistas for me. I definitely recommend playing this game, and I recommend not typing SECRETS until you’ve played through once. Then play it again — if you’re like me, you’ll be too entertained not to.

Rating: 8.8

PTBAD 3 by Jonathan Berman as “Xorax” [Comp04]

IFDB page: PTBAD 3
Final placement: 35th place (of 36) in the 2004 Interactive Fiction Competition

When I saw the title, I thought this game was going to be a sequel to Pick Up The Phone Booth And Die. Because the acronym seemed to be missing a number of letters, I thought it was going to be a badly-done, amateurish sequel, but a sequel nonetheless. For those unfamiliar with this long-standing IF in-joke, in 1996 Rob Noyes released a very simple game called Pick Up The Phone Booth And Die. The title is more or less also the walkthrough.

There are other ultra-minimalist joke games, but PUTPBAD attained iconic status because of the humor of its writing and the sheer ludicrousness of its premise. The joke inspired one sequel by Noyes, which fleshed out the simplicity of the original by adding some more funny stuff. It also inspired a much better joke, Pick Up The Phone Booth And Aisle, in which a huge number of IF authors collaborated to combine the original with the “one-move IF” concept pioneered by Sam Barlow in his game Aisle.

Well, if this game was meant to connect to any of those, it fails completely, and consequently, I have no idea what the title is supposed to represent. In fact, representation is a vexed issue for the entire game, which bears more resemblance to gibberish like Comp2000’s Stupid Kittens in that all of it seems like offhand, random, unconnected thoughts that make no sense whatsoever. To borrow a phrase from the game itself: “Rather disgusting dada surealist [sic] foolishness.” PTBAD 3 offers a badly-spelled, creakily-coded trip through what purports to be someone’s mind, perhaps someone who was the victim of a severe closed head injury. It’s got a maze, toilet humor, and a complete lack of proofreading. It’s quite a waste of time, though it’s short enough that it at least doesn’t waste much of it.

I wonder, though: why does PUTPBAD work when this game doesn’t? After all, in Baf’s Guide, Carl Muckenhoupt dismisses the original PUTPBAD in almost the same terms (“Would be a waste of time, were it not so short as to be almost nonexistent.”) They’re both tiny, nonsensical games that discard nearly all IF conventions. The difference, I think, is craft. Even though it only consists of maybe 200 words beyond the standard Inform libraries, PUTPBAD is clever, solidly coded, and impeccably written. PTBAD 3, on the other hand, seems as though it couldn’t care less about its prose or its code. And because of that, neither could I.

Rating: 2.9

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

No Room by Ben Heaton [Comp03]

IFDB page: No Room
Final placement: 22nd place (of 30) in the 2003 Interactive Fiction Competition

In a cheeky display of one-upsmanship (or maybe it’s one-DOWNsmanship), No Room trumps the one-room game by having no locations whatsoever. The author explains in a brief note that the PC resides in “the Inform Library itself, which is the most sense Inform could make of my game.” No rooms were harmed, or even created, in the making of this game. Consequently, the entire thing takes place in a dark, empty void, though I don’t think the location description or reactions are the Inform defaults. Thinking about how they got the way they are is making my head hurt, so I’ll stop.

The gimmick is fun, but doesn’t make for much of a game, of course. So No Room is a piece of micro-IF that basically consists of one puzzle. The puzzle is a good one, though it relied on some basic scientific knowledge that was, embarrassingly, just a bit beyond my grasp. But only a bit. Since there’s no location, the entire thing takes place in the dark, and between its darkness and its scientific-puzzle storylessness, the game feels like a cross between Aayela and In The Spotlight, except, of course, there’s no spotlight.

No Room could have used a bit more depth of implementation. Many of my ideas weren’t implemented at all, and a game this small can afford to take a great deal of care in making lots of options possible with its few items. On the other hand, the implemented parts were coded fairly well, and relying entirely on the sense of touch was an intriguing way to experience a puzzle. I was surprised to discover that a few uncommon Inform commands (like PRAY) were given special messages. Some of these messages felt desultory or over-the-top, but some (again, like PRAY) were funny. In fact, if the implementation had been a little less thin, I probably wouldn’t have found myself trying to PRAY in the first place, so maybe it was intentional…? Nah.

Rating: 6.2

Internal Documents by Tom Lechner [Comp03]

IFDB page: Internal Documents
Final placement: 19th place (of 30) in the 2003 Interactive Fiction Competition

After Curse Of Manorland, it was a relief to start into a game that seemed at least to be composed of coherent sentences, although the incredibly long, clause-upon-clause opener was a bit of a red flag. Still, the premise of the PC as civil servant investigating electoral fraud in a small town seemed like it had potential, and I began the game excited and interested. Sadly, Internal Documents fails on a number of levels, and by the end of the game I was just annoyed and disgusted, typing straight from the walkthrough. Some of its problems are pretty standard, such as the writing issues — typos and grammatical errors are common, and a noticeable number of sentences just fail to make any sense.

The coding is similarly problematic. At one point, I tried to read a document that (according to the hints, anyway) contains important clues. Here’s what happened:

>read manual
Chapter 1 reads:
Xy                  Yi                  Z
Zm              x                    b      k       a  c         k
a  d         k      a  e         k       a  f        k       a
g   Y   k       a  h   (   k      a  i   ê  k       a  j
y   k       a  k   0y   k       a  l   1u   k       a  m   2o   k
a     3c                 3u

I think this freakiness happens because of a particular quirk in Inform, because I vaguely remember using it intentionally in LASH to demonstrate illiteracy. However, in this game it obviously wasn’t intentional, and even the most basic testing should have revealed that it wasn’t working properly.

Another one of Internal Documents‘ big problems is one that I’d like to discuss in more depth, because I think it’s a signpost for anybody who wants to design good IF. Basically, the mantra is this: THINK LIKE A PLAYER. This game doesn’t, and falls down badly as a result. Here’s an example: early on in the game, I walk into a bar, and after the room description and a bit of incidental business, I get this:

The bartender cuts in and asks you, “So what brings you around here?”

Remember now, I’m a player. I’m trying to be immersed in the game’s fictional world, to do what the PC would do. So I type TELL THE BARTENDER ABOUT DUE DILIGENCE. In the game’s words, “This provokes no response.” So then I try to TELL THE BARTENDER ABOUT several other things, with no results. I proceed to strike out with TALK TO BARTENDER, ANSWER BARTENDER and ASK BARTENDER ABOUT <a variety of topics.> With sadness, I realize that the game has asked me a question but has no intention of providing me with a way of answering. So much for immersion.

See, as a designer, I might know that the bartender isn’t useful, and therefore give him only the bare minimum implementation. Maybe I want him to seem a little bit alive, so I give him a line of dialogue when he’s first sighted, and maybe I don’t so much care just what that line is. As a player, though, I have no idea whether the bartender is useful, so if he has some dialogue that encourages further interaction with him, I’ll take it as a cue that indeed he is supposed to be interesting. Then, when I encounter his minimal implementation, I’m annoyed and disappointed. The solution? Make the bartender surly and uncommunicative, so that his thin implementation seems like a natural aspect of his character. Your game is going to shape your player’s expectations — there’s no way around that, so it should shape them to its advantage rather than to its detriment.

On another “think like a player” point, remember that what’s fun for you isn’t necessarily fun for your player. You may really dig writing up three hundred slightly varying descriptions of the same sort of rather ordinary room, but by all that is holy, it is not fun to walk through them. Don’t set up situations where the player ends up wandering huge swaths of useless, pointless territory, or has to sit around or walk around aimlessly for dozens of moves waiting for a random event to trigger. That’s not fun, and it produces no particular emotional effect except for irritation. That’s not what players want from their IF.

Another aspect of thinking like a player is recognizing that if the game prevents a particular action repeatedly by use of unlikely coincidence, the player is going to believe that this action is forbidden and unimportant. If you think that the player will later be moved to attempt to do that forbidden thing as a way of solving a major puzzle, you’re probably wrong, especially if much more sensible solutions are disallowed. If I the player end up looking at the walkthrough, you want me to think “Oh, of course! Why didn’t I think of that?” Instead, I end up thinking, “First of all, I thought the game didn’t allow that action, and second of all, how does that make sense as a solution to that puzzle anyway?”

There’s a larger point here, which is that implementation generates expectations. If 99 out of every 100 nouns in your game are unimplemented, as is indeed the case with Internal Documents, I will come to expect a very bare-bones experience. I will not type out a long and unusual command construction, because what possible reason would I have to believe that the game would understand it? If you do expect me to do things like that, the game becomes either an intolerable exercise in attempted authorial telepathy, or else it ends up having to dole out sledgehammer-like hints (such as 1-2-3‘s notorious “Don’t you want to ask me about her breasts?”)

Before you even begin coding, think about what it will be like for players to experience your game, and if the answer is “boring”, or “irritating”, or “confusing”, stop those problems before they start. Otherwise, you end up with something that’s great fun for you, but not for anybody else… something like Internal Documents.

Rating: 5.3