Lunatix: The Insanity Circle by Mike Snyder [Comp99]

IFDB page: Lunatix – The Insanity Circle
Final placement: 12th place (of 37) in the 1999 Interactive Fiction Competition

Early on in Lunatix, I typed “X TUKE.” The game responded, “It looks just like you might have expected.” Of course, there’s no “tuke” in the game — I meant to type “tile” but my right hand had strayed a bit from its accustomed spot on the keyboard. I’m glad it happened, though, because the incident taught me something important about Lunatix: its parser pretends to understand more than it does. In my book, this is a big no-no. In fact, if I ever write a Parser Manifesto, my first principle will be, “Parsers must not pretend to understand more than they do.” Even a fairly innocuous violation of this rule, Inform’s famous “You can’t see any such thing,” has caused no end of debate on raif. When a game pretends to understand more than it does, you can never really be sure when you’re encountering a bug, because bugginess has been built directly into the interface.

What’s more, it’s a cop-out. Instead of doing the often tedious work of creating descriptions for the available objects, the game elides the absence of these descriptions by acting like it recognizes them when it doesn’t. As a player, I find this pallid deception infuriating. Unfortunately, Lunatix‘s parser does something even more infuriating, which has led to the formation of the second principle in my hypothetical Parser Manifesto: “Parsers must not give smarmy, unhelpful error messages.” My encounter with Lunatix was filled with exchanges like this (the words after the ellipses are my input):

...FILL WATER GUN
Your logic, although interesting, is flawed.
...TURN ON FAUCET
That's a pretty crazy idea, but it didn't work.

These kinds of responses make me want to scream obscenities at the game, and sometimes I did, along with feeble protests like “No it isn’t! Wanting to fill a water gun with water is not flawed logic! Turning on a faucet isn’t a crazy idea!” Then I remembered that talking to yourself is a sign of impending mental collapse, so I stopped. But my blood pressure stayed high.

The problem with this kind of message is that the game is willfully occluding its own shortcomings at the player’s expense. Error messages that insult the player, when in fact it is the parser that has failed, piss me off. I’d so much rather see the game say “I don’t know that verb” or “You can’t fill that” — that way I know exactly what hasn’t been implemented, and that knowledge will be useful to me throughout the game. Instead, Lunatix sneers at me and acts like its flaws are my fault.

Which brings me to the third principle of my Parser Manifesto: “Parsers must not ask questions without being prepared to receive an answer.” I had lots of exchanges with the game that went like this:

...POUR CPU
What are you trying to pour out?
...CUP
In a perfect world, that might have worked.
...POUR CUP
You empty the cup's contents onto the floor.

OK, so I made a typo in my first command, and the game asked me a disambiguating question. Fair enough. But wait! Further evidence reveals that the question only appeared to be for disambiguation. Actually, the parser wasn’t asking me a question at all, but giving me a message along the lines of “I only understood you as far as wanting to pour.” By phrasing that message as a question, Lunatix tricks me into thinking it is following the standard set by every other major parser: ask the player a question and process the answer. Instead, it’s only prepared to follow through with the first half of that standard, and gives me a snippy error message in the bargain. Grrr.

These kinds of problems have been more or less eliminated in the default library parsers used by most major IF tools, but Lunatix doesn’t use one of those parsers. Instead, it is a “homebrewed” creation written in (from what I can glean from the readme) QBasic, and presenting a radically different interface than most IF games do. The game splits the screen into four windows: the top half of the screen is split vertically between a square graphics window (displaying a picture of the current room) and a square text window, which always displays the textual description of the current room. Taking up most of the bottom half of the screen is a rectangular text window, which displays the game’s responses to the player’s input. Below that, a frame around a one line text field, is a window for the player’s input. It’s a bit reminiscent of the Legend interface, except instead of a compass rose and clickable command menus, there’s just a room description next to the graphic.

The graphics themselves are grainy and pixellated (or at least, they were on the two monitors I used to play the game), but still manage to be appropriately atmospheric at times, and even rather attractive once in a while. More importantly, they add significant content to the game — there are some objects that would be difficult to envision when described in text, but the presence of the graphic clarifies the setting a great deal. The window with the textual room description was nice, too, as it allowed systematic examination of the first-level nouns without having to periodically “LOOK” to remember what those nouns are. Of course, the game doesn’t actually implement most of these nouns, but that’s not the window’s fault.

The only difficulty I had with this window is that it didn’t always automatically update when something drastic had changed about the room, unless I explicitly typed “L” again. Thus, after solving a puzzle I might see a picture of a normal hallway, while the description alongside it raved about the giant squid blocking my path. In addition, lots of keen features were implemented in the interface, like command recall with the up-arrow, splash screens at the beginning and end of the game, a weirdly pulsating cursor, and nifty sound effects. So I can say with certainty that Lunatix is the most technically competent homebrewed game in the competition, perhaps even the most technically competent homebrewed game in the history of the competition. Unfortunately, all the snazzy windowing and gee-whiz effects in the world don’t really make up for its substandard parser.

The other part of the game’s core, its story, is OK. It’s one of those IF scenarios whose premise rationalizes why it is full of patently ridiculous things. In this case, you’re the unscrupulous director of an insane asylum and you’ve been given a drug which replicates insanity. This is a cozy explanation for why nothing you see really makes any sense, and seems to be just a setup for lots of different code and one-use-object puzzles. These puzzles are mostly OK, too. They’re more or less logical (within the confines of the completely nonsensical story) and, with one or two exceptions, pitched at the right level of difficulty. There is one real howler towards the end which makes almost no sense but will be deeply appreciated by fans of The Penguin on the old Adam West Batman show.

So in other words, the story and puzzles aren’t great, but they aren’t terrible either. Unfortunately, the combination of fair-to-middling plot with really-irritating parser makes the game less fun to play than it should be. See, (he said, mounting his soapbox) an IF game is a fusion of parser and story. The beauty of the modern IF languages is that they have freed designers from most of the hassle of worrying about the parser, allowing them to focus the bulk of their creative energy on the story. When a game eschews these time-tested solutions, it doesn’t just double its work, but increases it exponentially. Lunatix, strong as it is, isn’t quite up to the task.

Rating: 7.1

Exhibition by Ian Finley as Anatoly Domokov [Comp99]

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

Exhibition is a game of absences. It has no plot. It also has no puzzles, at least not in the way we’re used to thinking about puzzles. There are no takeable objects whatsoever in the game, and most of the action consists of standing around examining things. What it does not lack, however, is quality. It’s a masterwork of storytelling, creating a spellbinding narrative from spaces inbetween. I loved it. The story takes place at an art exhibition, the final show of a painter named Anatoly Domokov, who committed suicide shortly before the show opened. The only thing to do is stand around and look at the show’s twelve paintings, but devoid though it is of traditional action, the exhibition has psychological action galore. The player may view the paintings from one of four viewpoints: the wife of the dead artist, a critic, a twenty-year-old man, or a student. Although we can see (via HTML TADS image embedding) a drawing of each character, we do not see the paintings. Instead, each character describes each painting in magnificently written paragraphs, and in doing so tells as a little about the painting, and quite a bit more about themselves, usually unintentionally. The absence of the paintings is just another example of the way Exhibition tells us its most revealing secrets by what it chooses not to include.

Like last year’s winner Photopia, Exhibition is all about someone whom the player never controls. Unlike Photopia, this game goes one step further: we never even see Anatoly at any point in the game. Instead, what we get are descriptions of his works, sometimes mixed in with anecdotes about him when the work is being viewed by someone who knew or met him. With each description from each viewpoint, we get another piece of the puzzle. All the pieces fit together like a jigsaw, but they do not form a clear portrait of the artist. Instead, like a frame around his outline, they define his shape, each moving from a different direction to collide with one of his boundaries, and sometimes with each other too. At the end of the game, we know Anatoly’s form, but only obliquely, filtered through the very individual perceptions of each viewer.

In the bargain, we are granted insight into his art, his loved ones, his disposition, and his culture, but all these insights are lines around a central emptiness, an absence reflected in the artist’s final painting, “Iscariot.” The painting, in the words of the critic, is “a simple desert landscape with a frayed noose hanging empty on a gnarled tree and a scrawny goat searching in its shadow.” Anatoly hanged himself, and was found next to this completed painting. Each character offers an interpretation of the empty noose (as well as its grisly companion), and each interpretation gives us a piece of the truth. The author notes that, in part, Exhibition aspires to be “an experiment in how tales are told and the inevitable gap between the teller and the audience.” It is by shining its light through these gaps that the game so sublimely illuminates and limns its subject.

Unexpectedly enough, this collection of descriptions is a puzzle, though certainly not in the tradition of most IF puzzles. It is up to the player to create that outline, to put the pieces together so that one viewer’s comments clarify those of another viewer, and both together sharpen the focus on Anatoly’s silhouette. Even the shape of the gallery itself, walls around a space, contributes to the developing portrait. Exhibition makes the process of deduction easier with its stellar production values. In the reams of text presented by the game, I found not one grammar or spelling error. I didn’t find a single bug either, though the game’s design is admittedly simple as far as programming is concerned. These virtues by themselves give me great pleasure, but what made the game a true joy to play was its wonderful writing. As an exercise in character and viewpoint, Exhibition is an impressive performance. As storytelling, it is mesmerizing. Exhibition may be a game of absences with death at its core, but like the stories it tells, it wields a power far greater than the sum of its parts.

Rating: 9.9

Beat The Devil by Robert M. Camisa [Comp99]

IFDB page: Beat The Devil
Final placement: 9th place (of 37) in the 1999 Interactive Fiction Competition

If you grew up in suburban America in the 1980s or 90s, what would be your vision of Hell? Where would you least like to spend eternity? Where does it already feel like an eternity when you’re there? That’s right: a shopping mall! In Robert Camisa’s Beat The Devil, Lucifer is building an addition to Hell, and you’re his betatester. He overheard you mumbling about how you’d sell your soul for a chance with the object of your affections, and, being surfeited with souls already (“Washington and Hollywood provide me with all the souls I’ll ever need to buy.”), makes you this alternate offer: wander through this Stygian mall and defeat the incarnations of the seven deadly sins, and that date is yours.

It’s a fun concept, and Beat The Devil gives it an energetic, cartoonish implementation. There are a number of funny spots, though the humor tends to lean a little too far in the direction of over-the-top junior high style exaggeration. For example, to make fun of stores whose decor is all white, there’s a store in the Hell-mall whose shelves are so white that they’re blinding. There are a number of choices like that, which puts the humor at the lowest common denominator. Still, on the whole the game remains pretty funny, just because by being such a detailed working-out of its concepts, it manages to satirize both malls and typical depictions of Hell.

The game is clearly the product of a novice IF author, and while the writing and coding are both fairly good, each has a number of errors easily identifiable as beginner’s mistakes. On the writing side, there are a number of punctuation problems: sentences missing periods, contractions missing apostrophes, quotes missing quotation marks and the like. The grammar and spelling are better, though an occasional glitch will slip through on those as well from time to time.

On the coding side, there are a few little oversights such as some objects missing short_names, disambiguation problems caused by objects whose names are too short, and a number of unimplemented first-level nouns. More interesting is another slip-up. Searching the shelves in one store yields this:

Yada yada..blow dust..yada yada..small white packet.. yada yada...
again with the no gold or jewels. Sigh.

The description didn’t make much sense to me until I reached another store, searched its shelves, and found this description:

You blow dust off the shelf, almost choking yourself from the resultant
cloud, but you uncover a pair of pliers, which you pocket. Personally,
I'dve preferred gold or jewels, but beggars can't be choosers.

Clearly, the game assumed I would search the shelves in the opposite order that I did. This is an easy mistake to make, especially if you’re concentrating on making sure your game is winnable by focusing on a particular walkthrough path. Vexingly, it’s also the sort of thing that your betatesters won’t always find — if they go through the game in the same order that you envisioned, no problems will be apparent. Writing text that is dependent on some other text already having been displayed is very tempting in IF, but you have to be careful that you take account of what happens if that text hasn’t yet been seen.

These are minor mistakes, and can be cleaned up easily in a subsequent release of the game. They don’t much interfere with enjoyment. The same could be said of the puzzles. While there are a couple of sticky spots, most of the puzzles are either pretty obvious or rather clever. The “obvious” part of that evaluation may sound like an insult, but I don’t intend it as one. I’m a fan of obvious puzzles — they’re a lot better than “guess-what-the-author-is-thinking” puzzles, and in an author’s first game you’re more likely to find the latter than the former. The clever ones include a nifty device reminiscent of the “T” remover in Leather Goddesses.

The one real clunker is flawed in a way that, again, marks it as a beginner’s error. There’s an object in the game that will destroy anything put into it. When you try to put anything into it, you’ll see a funny default message about how destroying something you may need later is a dumb thing to do, and the game won’t let you do it. However, there is one object you must destroy in such a way in order to win the game. Based on the default message, there’s no way of knowing that the destroyer will react differently to one particular thing. This isn’t a problem with the puzzle so much as the way it is implemented — it’s like a hungry troll saying “I don’t want to eat!” when offered the wrong kind of food, rather than saying “I don’t want to eat that!” If the default message were worded slightly differently, the player could twig to the fact that although the attempted action is wrong, a similar one might be right. This is the sort of thing you learn with experience, either of writing a lot of IF or playing a lot of it, or both. Beat The Devil is an auspicious start, and I look forward to the author’s next game.

Rating: 7.5

King Arthur’s Night Out by Mikko Vuorinen [Comp99]

IFDB page: King Arthur’s Night Out
Final placement: 22nd place (of 37) in the 1999 Interactive Fiction Competition

This game depicts King Arthur in a way I’ve never seen him before. Instead of tragic hero, noble warrior, or eager wizard’s apprentice, it’s King Arthur as… henpecked husband? Yes, you as King Arthur just want to head to the pub for a pint or two with “Lance” and the boys, but your wife, the uncharacteristically shrewish Guinevere, wants you to stay home while she sits on the bed, knitting. The puzzle, then, is how to get out without her knowing. It seems to me that this plot could have easily taken place in a suburban house rather than Camelot. Yes, Excalibur makes an appearance, but even with that addition the game is still a rather pedestrian affair with a superficial sheen of Arthurian trappings laid on. I’m not convinced that this sheen improves the game. There’s an element of the unexpected, I suppose, in seeing Arthur cast in such a strange way, but the surprise does little to illuminate either the Arthurian mythos or the game itself. In addition, the henpecked husband stereotype has never been one that I’ve found all that compelling, so mixing it in with the legend of King Arthur shatters the power of the legend while doing little to enliven the stereotype.

King Arthur’s Night Out suffers in several places from “guess-the-verb” weaknesses. There is an item that, when SEARCHed, will yield an important discovery. However, if you look in, shake, push, open, or examine it, you won’t find a thing. In another spot, you must retrieve an item from underneath something else. However, you can’t crawl under this thing, nor lift it, nor just get the item from underneath it. The puzzle has a logical solution, but because such a specific wording was required, I didn’t find that solution until I checked the walkthrough. I felt annoyed when I discovered the answer, because it was no more complicated that the things I had been trying, things which got no response. How was I supposed to know that this particular method had been implemented, I wondered, when 5 others weren’t? I think my experience contains a lesson for me as an author — puzzles shouldn’t consist of hunting around for the one method which the author anticipated. The author should anticipate three or four methods of solving a puzzle, and implement them all, either as alternate solutions or as dead ends which will help point the player toward the correct method.

Having griped about that, I will say that the game was coded quite well overall. Many actions were accounted for, especially in areas which weren’t puzzles. I found no bugs in playing the game, and only a very few errors in the prose mechanics. I still didn’t have a particularly great time playing the game, but a large portion of that reaction is due to the fact that I didn’t find the premise very interesting. Perhaps people who enjoy broad domestic farce would like it more. In addition, if a second edition of the game emerges that implements the puzzles a little more robustly, King Arthur’s Night Out will be a solidly coded, if a little bit odd, piece of interactive fiction.

Rating: 7.2

Four Seconds by Jason Reigstad [Comp99]

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

Maybe I’m just getting cranky, but I really feel that this year’s competition games are a lot buggier, on average, than in previous years. It’s drained some of the fun out of the competition for me — I’ve begun to dread starting a new entry rather than eagerly anticipate it. For each unknown game, I start to wonder whether it will be just another bugfest that I’ll sincerely try to play for 30 minutes to an hour, getting more and more frustrated with its constant errors before turning to the walkthrough. That’s not normally my approach, but this year’s games have changed my usual attitude.

Four Seconds is a case in point. It is very, very buggy, and heavily burdened with grammar and spelling errors as well. If you don’t use the walkthrough, you will find lots of bugs. In fact, there are even a few bugs in the walkthrough itself. If you type “info” or “about” in the game, you’ll find an apology from the author for the bugginess of the game. This is something for which I have zero patience. If you know your game is buggy, fix it. Fix it before you ask people to play it. Don’t waste my time.

It’s baffling to me that buggy games like this get entered, especially considering the fact that this year Lucian Smith and Liza Daly went to the trouble of actually setting up a betatesters clearinghouse on the web. Testers were available, so why weren’t they used? All I can conclude is that the authors who submitted buggy games just don’t care that much about the players’ experience. This disregard leaves the player little motivation to care about the game’s rating, and it gives me as a reviewer very little motivation to put any time or energy into giving useful feedback. In addition, playing a game so crammed with bugs feels like another version of non-interactivity, since there’s almost nothing to see outside the bounds of the path dictated by the walkthrough.

So here’s the deal with Four Seconds: it’s not worth the download. Not only is its plot a b-movie rehash of much better games (mayhem at an isolated science complex a la Delusions or Babel), but it’s pretty much unplayable. Tons of commands get no response at all from the parser. Many more get responses that make no sense. Those pieces of prose that do emerge, whether arrived at by use of the walkthrough or just dumb luck, lack the most basic proofreading. I spent an hour of my life that could have gone to something much more fulfilling on playing Four Seconds. I wish I had spent 59 minutes and 56 seconds less.

Rating: 2.7

Lomalow by Brendan Barnwell [Comp99]

IFDB page: Lomalow
Final placement: 21st place (of 37) in the 1999 Interactive Fiction Competition

Ever feel like you’re first reader for the slushpile? I get that feeling sometimes as I near the end of a long list of competition entries, and I definitely had it playing Lomalow. It’s sentences like this that produce such a feeling: “The sheer mountain cliffs end abruptly at and are ended abrutply at by a dense forest of tall evergreens.” Huh? The author announces at the outset that the game’s only puzzle is “how to get to read all the text that you possibly can.” The implication is that reading the text is its own reward. This is a nice concept, but works better when the text is actually well written. There’s a fair amount of prose in this game, and seeing it can be rewarding, but often not for the reason the author intended. For instance, at one point, a wind howling above the pit you’re in is compared to “a giant child puffing across the top of a Coke bottle.” This comparison may have been intended to inspire awe, but for me it was a very comic image. Somehow the idea of a kid blowing on a Coke bottle failed to evoke the fury of nature.

My favorite passage, though, was a room description, and I can’t resist quoting it in full:

Waterfall
This area seems to be filled with abrupt ends. To the east,
the mountain ends abruptly at the forest you came from, and vice versa.
The forest also ends abruptly at the cliff which you are standing on.
It's about ten feet wide and ends abruptly in midair. Far above, a
riverbed abruptly ends at the abrupt end of the mountain, generating an
incredibly long but relatively narrow waterfall. From the roar that
emanates from below, you presume that this waterfall ends abruptly at
some flat surface, creating high-intensity sound waves which end
abruptly at your ears, which end abruptly at the side of your head,
which ends abrutply at your shoulders, and so on and so forth.

By the time I got to the end of this passage, I almost fell out of my chair I was laughing so hard. The problem is, I’m not at all certain it was meant to be funny. The contrast suggests to me that the game’s prose has escaped its control — the same word is repeated 10 times in 6 sentences, sounding sillier each time (it doesn’t help that the final occurrence is misspelled) and jarring badly with the overall tone of the story.

The mounting ridiculousness of the repetition in the above passage is echoed by the repetitive nature of the game itself. Lomalow is designed so that the only way to win is to ask the two characters the same questions over and over and over again. A typical interaction might be to type “ASK WOMAN ABOUT BOOK.” She will give a very short answer, trailing off with an ellipsis. Then, the player must type “G” again and again until the old woman starts to repeat herself. After that, the player must repeat the process with a different noun substituted in place of “book.” Then, repeat all of the above with the game’s other character, an old man.

After going through the cycles a few dozen times, the whole thing starts to seem really funny. I kept imagining what life would be like if all conversations had to be carried out this way. I’d have to ask my wife about the store 29 times to get the entire shopping list down. You’d have to ask the cop about the ticket 8 times before finally receiving it. When the final climactic scene came, my main emotion was relief that the characters could bring themselves to utter more than a few sentences at a time without being prompted. Relief was followed closely by amusement when the old man screamed at me, “We’re magic BIRDS, aren’t we? What do BIRDS do, guy?” Of course, it took me a while to get to this scene, because I kept running out of nouns to substitute in the conversations.

I turned to the hint system for help, but all it tended to give me were cryptic suggestions along the lines of “Don’t be dense. You’ve already seen 14220. Why haven’t you talked to the old woman about it?” My suspicion is that these odd messages are the result of a bug in the hint system caused by having Inform print an object’s number rather than its name. The numbers may have been intentional, but if so, the decision to use them makes the hint system pretty useless.

So Lomalow is a very flawed game, hampered by its overblown prose and its numbingly iterative design. That’s what I have to say as a critic. Now, here’s what I have to say as an author. The thing I liked about Lomalow, and the thing that kept it from becoming a purely irritating experience, was the obvious sincerity that was driving it. Yes, it’s the product of a novice writer. But every writer is a novice at some point, and I’m quite certain that almost every respected writer (of interactive fiction and regular fiction too) started out writing passages that were just as silly as, if not sillier than, the ones I quoted in my first paragraph. It’s a necessary thing, and I know from my own experience that fear of looking foolish in public can hold a writer back from going through that stage. Since it’s a stage that is almost always one of the first steps on the path to real skill, the fear stops many writers from reaching their true potential.

So even though, from a critical standpoint, I can’t see Lomalow as a success, I applaud its author for having the courage to overcome that paralyzing fear. I could see the promise of improvement shining through much of the text, and the game’s very existence suggests that the author is committed to pursuing that promise. These thoughts allowed me to play through Lomalow with a smile rather than a grimace.

Rating: 5.0

Thorfinn’s Realm by Roy Main and Robert Hall [Comp99]

IFDB page: Thorfinn’s Realm
Final placement: 28th place (of 37) in the 1999 Interactive Fiction Competition

For someone who has always loved playing IF, the first few attempts at programming it can be a giddy thrill. The smallest achievements can provide boundless amusement: “Look! I made some rooms that link together in crazy ways!” That’s why many IF authors, especially those who started programming IF during their adolescence (or even before) go through a stage of writing games that do all kinds of really crazy, annoying things. These games are usually brimming with smarmy, smart-assed responses to various fairly ordinary commands, because smart-assed responses are one of the easiest, most fun things for a novice to program. The games often do really annoying things, from a gameplay standpoint, just because those are things their author has just figured out how to do. Mazes are common, as are insta-death puzzles, silly objects/rooms, in-jokes, and self-referential appearances by the author.

Design isn’t a big consideration, and for that matter neither are consistency, logic, realism, or correct grammar and spelling. All these things take a lot of patience, and the fledgling IF author is way too eager to write the next snarky response to bother with them. Of course, many of these early efforts never see the light of day, something for which their authors find themselves very grateful five or ten years down the line. But some find their way out. Some authors even take the trouble of porting their old efforts so that the games can reach new audiences (Andrew Plotkin‘s Inhumane is a case in point). I don’t know whether Thorfinn’s Realm is the product of novice programmers (or a port of such.) It may not really belong to this category of game, but it certainly feels like it does. It’s a game that does many things wrong, and has lots of irritating misfeatures and errors, but is still endearing nonetheless for its abundant energy and enthusiasm.

The plot is a goofy contrivance for a treasure hunt, something about time-traveling back to the 10th century to join a time-travelers club. Of course, the introduction is careful to explain, the club has gone ahead of you to set up a few “surprises”, a rationalization which serves to explain any strange anachronisms you might find, such as oh, say, flashlight batteries lying around. Hung on this framework is a string of lots of the most irritating puzzles/features from the earliest IF games.

There’s a 4 item inventory limit. This limit can be contravened with a rucksack later in the game, but even the rucksack has a limit. There’s a maze, almost at the very beginning of the game. There’s a “replace the light source” puzzle, which basically entails saving and restoring to replay the first 200 moves over and over until you’ve found the aforementioned flashlight batteries. At times I felt like I was having an extended flashback to the early 80s — I’m thankful there was no starvation puzzle or I might have permanently lost my mind.

Along the way there are a host of misspellings, objects missing descriptions, lapses of logic, and lots and lots of smarmy parser rejoinders. Take, for instance, the following:

>EXAMINE LOGS
Captain's log, stardate 950 AD. Some idiot is poking around in a fireplace.

I can almost picture the programmers chortling with glee, savoring the oh-so-clever wordplay and hoping some suckers examine the logs in the fireplace so that they can be the target of that zinger. The player who finds it, on the other hand, grimaces for a moment and then moves on (or at least that’s what I did). Who had more fun in this scenario? Thorfinn’s Realm is full of moments like these, things that are aggravating for the player but which were presumably fun for the authors to create.

Now, let me back off a few steps. First of all, I recognize that I’m setting up a strawman in the above paragraph. It is certainly possible that the scenario I describe above is very far from the truth, and that the authors genuinely thought that the in-jokes, self-references, light source puzzle, etc. etc. would really be fun for the player. Not probable, I admit, but possible. Secondly, I can’t stay mad at Thorfinn’s Realm for long, despite its many flaws. For one thing, in spite of its cracked design and sometimes wobbly English, the game is coded pretty competently. I found very few bugs, aside from the occasional elided description, and lots of verbs and nouns are accounted for in the parser.

But more importantly, there’s just such a verve to the whole thing. It’s a quality much more difficult to put into words than the game’s problems are. Something about the gestalt of the whole package — puzzles, setting, prose, and the rest — conveys an infectious enthusiasm for the medium of interactive fiction. Come to think of it, that’s another quality that Thorfinn’s Realm shares with the earliest IF, but a good quality. Those early games had many characteristics whose passing is unlamented, but they also had the bright-eyed excitement of explorers mapping uncharted territory. In capturing the feel of the early days of IF, Thorfinn’s Realm finds not just its curse, but its blessing as well.

Rating: 6.4

Music Education by Bill Linney [Comp99]

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

In Music Education, you play a college student majoring in music. The game takes place in and around a college music building, and many of the characters and puzzles involve music in one way or another. The specificity of this premise helps the game feel a little less like a generic college romp, but does not help it to transcend the genre of games which feel more or less like implementations of somebody’s (usually the author’s) fairly quotidian life. These are the kind of games that are much more fun to write than to play. Aspiring writers are given the advice that they should write what they know, and try to write for themselves, creating works that they themselves want to read. This is good advice, but I think that when it is applied to interactive fiction, it often leads to games which are more or less an interactive version of somebody’s apartment, or house, or campus. These can be fun to play, but only if the main attraction isn’t the game’s similarity to the author’s real life.

For example, A Bear’s Night Out may have been set in an implemented version of the author’s house, but the main attraction of the game isn’t the fact that you get to walk around a virtual replica of a typical house. Instead, there are specific, interesting elements to the game that put the house in the background rather than the foreground. In Music Education, the college music building occupies the foreground, and one suspects that the most fun thing about it for the author is its resemblance to that author’s lived reality. This is a type of fun in which very few players can share. I may be way off base here. Perhaps the whole building is imaginary, and the game’s scenario has no bearing on the author’s life. If so, the game fails to make the fictional scenario compelling enough to hold the player’s interest. This lack of zing arises in part from the sheer ordinariness of the scenario (with occasional lurches into absurd death scenes), but also from its curious goallessness.

The game begins at a parking meter, so it’s reasonable to think that the goal of the game is to feed the meter. However, even after you do this, the game is not won, and there are many more points to be scored. There’s no real plot to the game, so it’s difficult for players to understand just what they’re supposed to be trying to accomplish in order to win the game. There are no overt indications of exactly what the puzzles are, let alone how they ought to be solved. Consequently, I spent a good deal of time wandering around the game just doing the obvious thing with the few objects to hand, without ever understanding the purpose of such actions. After I ran out of ideas, I consulted the walkthrough and discovered that a couple of highly unlikely (though, in retrospect, more or less logical) actions are necessary to complete the game.

I still didn’t understand why any of those actions were necessary until I had performed them, and I think I’ve figured out the problem. Most of the puzzles consist of bringing things to various characters, or creating a situation that the character desires. However, the characters never give any indication as to what they want, so it’s very difficult to know what you’re supposed to be doing for them. This is why such “locked-door” characters in IF normally say things like, “Boy, I sure could go for some ice cream right now!” It’s a way of feeding the player specific information about the key to unlock the NPC’s puzzle without that NPC needing to break character. In Music Education there is one character whom you can ask about the other characters, but again there’s no motivation to do this other than trying to figure out what the goal of the game is, and even when you do ask, the character only answers on a few topics. This setup breaks mimesis, since there’s no intrinsic, character-based reason to ask such questions; the game becomes less about a music student and more about a confused player trying to figure out what the game is looking for.

Luckily, there’s an easy fix to this: just enhance the characters so that it’s easier to figure out what you’re supposed to be doing for them. This could mean tweaking their responses to various questions, or giving them a response to “hello”, or giving them opening text for when they first meet the player, or some combination of the above. Granted, “I really want a…” statements can feel rather artificial when written poorly, but wandering around wondering what to do in a simple environment feels much more artificial. Music Education is a game whose writing and coding are relatively free from errors, but whose drive is deflated by the banality of its setting and some relatively basic omissions of puzzle design. Once the latter of these problems is fixed, the former will cease to have as much effect.

Rating: 6.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

Guard Duty by Jason F. Finx [Comp99]

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

Wow, now that’s really too bad. As with The Water Bird, I knew that there was a fatal bug in Guard Duty before I started playing it. I didn’t know what that bug was. Turns out the game crashes as soon as you take inventory. This crash occurs with both Frotz and Jzip. It doesn’t occur with Evin Robertson’s Nitfol interpreter, though that interpreter will spit a lot of errors at you during crash-worthy occasions unless you turn on its “ignore” function. So that gave me a decision to make. Do I rate the game based on its ability to function under my traditional interpreters of choice, or do I download a new interpreter, set it to ignore all errors, and play through the game (or as much as can be played) that way?

I chose the former. Here is my reasoning: I try to judge all the competition games on a level playing field, as much as possible. When I played The Water Bird, I played the version that I downloaded on October 1, fatal bug included. If the author had released a bugfix version, I wouldn’t have used it, because one part of the challenge of the competition, as I see it, is to release the best game possible by the assigned deadline. If I play a version that comes out after the deadline, that version would have an advantage over all the other games whose authors could have fixed post-deadline bugs, but who didn’t do so because they’re following the rules.

A similar logic applies to interpreter-specific bugs. To my way of thinking, a bug that shows up in any interpreter (as long as it’s not the interpreter’s fault) is a bug that ought to be factored into the game’s rating. Even if it’s possible to jigger an interpreter so that it will look like the bug doesn’t exist, that doesn’t mean that the bug is gone. Part of an author’s job is to test the game thoroughly enough that its bugs get fixed before the game is released. If this doesn’t happen, the bug should be factored into the game’s rating. I already wrote my screed on how games that haven’t been bug-checked or proofread shouldn’t be entered into the competition, and there’s no point repeating it here. It’s really too bad, though, because like The Water Bird, Guard Duty showed a lot of potential before it crashed and burned.

Unlike the bug in The Water Bird, however, Guard Duty‘s bug is of a nature that I felt it made the whole game unplayable, not just a portion of it. For that reason, I didn’t feel justified in giving the game any rating higher than 1. I hope that in remembering Guard Duty, authors will think twice about entering a game into the competition before it’s ready. It’s really not worth it.

Rating: 1.2