Tag: homebrew

Ninja v1.30 by Paul Allen Panks [Comp04]

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

You know, for all the newsgroup fuss and furor that Paul Allen Panks has created over the years with his obsessive marketing and subsequent defenses thereof, I’ve never actually played one of his games. I’ve been wishing for years that somebody would review Westfront PC for SPAG, but so far, no takers. Of course, what I’ve gleaned about that game is that it contains hundreds of fairly samey rooms and a bunch of randomized combat, so I can’t say I’m terribly surprised not to have received a review. Heck, the SPAG standards say that reviewers must finish a game before reviewing it, so maybe somebody started in on it the first time I made the request (in 2000) and still hasn’t gotten through it yet.

At any rate, Ninja v1.30 is Panks’s first comp game, so I was interested to see how well he presented himself. The answer: not very well. It’s bad. Really bad. For one thing, it is so primitive as to lack almost any IF conveniences. There’s no “X” command, no “L” command, and no “I” command. It goes without saying that there’s no SCRIPT or UNDO or anything handy like that. Despite the fact that it contains only four rooms and one puzzle (which is so heavily clued it can hardly be called a puzzle at all), to detail all its failings would be a pretty mammoth undertaking. So let me just pick a few choice ones:

  • The sudden-death endings, which frequently hit out of nowhere. Note that these are particularly annoying in an environment without UNDO.
  • The utterly arbitrary restrictions. For instance, this:
    You are within the shinto shrine. The room is lit by only the light from a nearby window. All else is darkness. You may 'exit shrine' to the south, or head west out the window.

    ? s
    Your path is blocked. Try 'exit shrine' instead.

    Why?

  • The maximum score, different every time the game ends. (Well, I guess the second number in the score might not be the maximum, but if so it’s left completely unexplained.)
  • Terrible writing. For a game that probably has less than 300 words, it’s amazingly well-populated with comma splices, redundancy, and awkward phrasing.
  • Bugginess. For instance, at one point the game started printing “>20” after every command, inexplicably.

Okay, enough of that. It’s just really not good at all. But there is a way to enjoy it, at least for me. See, I like to think that there exists a tiny sliver of possibility that Panks is actually just a satirist with a very, very, very dry wit. I mean, really — if IF were a Christopher Guest movie, Panks would just have to be a character. It’s almost as if he’s playing a character all the time in his postings, and this game works perfectly as reductio ad absurdum interactive fiction. Look at it as a parody, as perfectly straight-faced and utterly ridiculous all at once, and it may provide a moment’s entertainment. Of course, that doesn’t mean you’d give it a high score in the comp or anything.

Rating: 2.4

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

Little Girl in the Big World by Peter Wendrich [Comp03]

IFDB page: Little girl in the big world
Final placement: 24th place (of 30) in the 2003 Interactive Fiction Competition

NOTE: Based on the readme file, the author wishes to keep the PC’s identity unspoiled for people who haven’t played the game. I don’t really see the reason for this, since the identity doesn’t really make a lot of sense, so I’m going to be spoiling it in this review. Consider yourself warned.

Little Girl In The Big World must be titled ironically, because the game’s world is anything but big. It’s just five rooms, three of which are pretty much bare. Not only that, the entire thing takes place in a standard house, and leaving the house (to go out into the big world) ends the game. I wish I could say that some interesting stuff at least happens in this little gameworld, but… not really. There’s no particular plot to speak of, and the whole thing can be finished in 20 minutes, easy.

The ABOUT text suggests that the game was written as “proof of concept of a new virtual machine,” and indeed it’s kind of cool, from a programming perspective, that this virtual machine (called StoryFactory) can work both as a Windows executable and as a JavaScript runtime inside a web browser. As a story, though, LGITBW offers very little.

Even from a coding viewpoint, the StoryFactory parser and world model has lots of serious problems, or perhaps just blatant deficiencies compared to established first-tier systems. It’s got a leg up on many homemade games in that its error messages are not snide, but they are sometimes unhelpful. For instance:

> get key
[ I will get the rusty key ]
That didn't work.

“That didn’t work” doesn’t really tell me enough of what I need to know, and it’s the game’s standard failure message. The text in brackets at least signals that my command was understood, but I need much more specific feedback when a command fails. Happily, the parser politely and willingly admits when it doesn’t understand something, and doesn’t ask any questions it isn’t prepared to answer (it doesn’t ask any questions at all), but its ability to understand input is quite minimal, it usually chokes on commands of three words or more, and it doesn’t seem to have any concept of pronouns at all. Oh, and there’s no SAVE or RESTORE functionality, which is a minor drag in this game and would be a major problem in a larger one.

As for the world model, a couple of its most serious flaws are its lack of basic IF concepts, such as inventory, and its irritating habit of only printing the room description after a LOOK command. Even at the very beginning of the game, or when the PC moves into new territory, StoryFactory doesn’t care to tell the player anything about the location. Add to these issues the fact that the prose is hampered by a considerable number of spelling and grammar problems (English isn’t the author’s first language, so it’s understandable but no less unsatisfactory) and you have a game whose implementation is seriously troubled.

LGITBW does have one interesting aspect, which is the fact that it has a strange sort of split PC. You play, apparently, a rat who is living with a little girl named Alice. However, most of the time Alice is with you, the parser will interpret your commands as orders to her, which she will usually carry out. You can specify the actor before the command in order to remove any ambiguity — I EAT THE CHEESE or ALICE EAT THE CHEESE. Now, because it’s a rat and a little girl, my personal inclination is to find this somewhat creepy, especially since Alice is so lifeless an NPC that she seems to behave as some sort of Stepford automaton, eerily under the sway of her pet rat’s will. I dunno, maybe it’s just too close to Halloween.

Anyway, creepiness aside, it’s a noble attempt to provide a team PC. Alice can do things the rat cannot, though the reverse isn’t true (not when it comes to anything useful, anyway.) There’s more ground to be broken in this area, and indeed I hope to break some of it, but LGITBW at least provides a signpost. Pity it does so ensconced in such a poor parser and inconsequential game.

Rating: 2.6

Hercules’ First Labor by Bob Brown [Comp03]

IFDB page: Hercules First Labor
Final placement: 26th place (of 30) in the 2003 Interactive Fiction Competition

For me, the comp game experience begins from the moment I read the game’s title and blurb in Comp03.z5. What that meant for Hercules’ First Labor was that I was out of sync with it from the beginning. Not from its title, which is fine, but from its blurb:

My introduction to computers was the Scott Adams series of adventures
with the simplistic Verb/Noun parser and this game is in that vein.

I know that there are these people who have lots of nostalgic feelings about Scott Adams games, but I’m not one of them. I’m an Infocom guy, and have been since the beginning of my involvement with IF. Consequently, Scott Adams games tend to feel like cave paintings when what I’m really looking for is Degas and Monet, or at least Jack Kirby. I come to IF more for the fiction than the interaction (though they’re both important, of course), and my favorite games all have excellent writing in common. So, predictably, I’m not a fan of room descriptions that look something like “I’m in a Hotel Room by Door.” The “simplistic Verb/Noun parser” also feels like a straitjacket to me, and it’s that much worse when I don’t have access to the metacommands I’m used to, like UNDO, AGAIN, and, well, SAVE.

So I’m really not in the target audience for this game. Now, that being said, HFL pulls off the Scott Adams feel quite well, and the fact that it’s apparently coded in JavaScript makes the whole Verb/Noun thing a little more understandable. The presentation is attractive in the browser window, and even though it was frustrating not to be able to generate a transcript of my game sessions, I found the split-windowed interface (one frame each for status line, room description, parser responses, and input) effective and intuitive. The parser worked tolerably well (with some problem inconsistencies between “read” and “look”), though “pretty well” for a two-word parser is still pretty darn poor by today’s standards. The bare-bones nature of the setting made the puzzles very straightforward indeed — just use the very few verbs at your disposal to interact with the handful of objects you encounter and you’ll be finishing the game in no time. The verb USE is your friend. Similarly, there’s not much to say about the writing, because there just isn’t much of it.

“Homemade” competition games tend to be notorious for having underimplemented parsers, and for lacking some of the basic functionality that we take for granted in games produced by top-tier development systems; the homemade games I’ve encountered so far in this comp are no exception. However, this time around, new approaches have tried to turn these shortcomings into advantages. The way Sweet Dreams did it was to throw out the parser altogether, replacing it with a low-res avatar in a graphical environment. Thus was the whole parser problem avoided entirely, and this approach worked for me. The homemade interface still had its bugs and frustrations, but I found Sweet Dreams to be one of the least irritating comp games ever made outside of a mainstream IF development system. (That’s not to damn it with faint praise — I liked it well enough.)

HFL avoids the problem in a different way, by setting the player’s expectations from the very beginning, and enlisting the aid of nostalgia to make its simplistic parser actually seem like a feature rather than a bug. I’ll bet that for people with fond memories of playing Scott Adams games, the trick works really well. For me, though, it felt like just another substandard homemade parser, albeit ameliorated a bit by the fact that its simplicity was matched by that of the environment. So, while I acknowledge it as a good try, HFL left me cold. It did inspire me to my first comp game anagram, though. (“SA flirt’s core blur, eh?”) That’s worth a little something.

Rating: 3.7

The Last Just Cause by Jeremy Carey-Dressler as Noob [Comp01]

IFDB page: The Last Just Cause
Final placement: 50th place (of 51) in the 2001 Interactive Fiction Competition

Hoo boy. I’m not sure how to approach this one. OK, let me start here. If I had downloaded this game by itself from, I don’t know, download.com or something, I think I would have approached it differently. I might have taken, for example, its more or less complete lack of a parser more in stride. However, this is my 20th text adventure in 17 days, and all the others — even the homebrewed Windows ones — at least made some pretense at approaching the ability to understand basic language input. Consequently, I approached TLJC like another text adventure. It isn’t. This game doesn’t even come close to the level of understanding displayed by even something like Angora Fetish. I typed “x lantern”, and here’s what happened:

You have used 0 turns... What do you want to do next? x lantern


That might be foolish, try something else...

Your HP is 104 percent. You're in room 1. Your MP is 44.
You have used 1 turns... What do you want to do next?

That might be foolish, try something else...

Your HP is 104 percent. You're in room 1. Your MP is 44.
You have used 2 turns... What do you want to do next?

What I determined, after a bit more confused thrashing about, is that the game only understands one word at a time, and that its vocabulary is limited to a couple dozen words. After being immersed in modern, sophisticated text adventures, this game suddenly made me feel like I had time-warped back to 1982, and that one of my 12-year-old colleagues had just unveiled their rockin’ new game to me.

I just keep coming back to it: programming an IF game from scratch may make for a better (or at least more educational) experience for the programmer, but it almost always provides a much worse experience for the player. Not that this game would necessarily have benefited greatly from being written in an advanced IF language. Its shape is extremely simplistic, it has very little story, its writing lacks coherency (as well as a number of other virtues), and… well, I could go on, but what’s the point?

TLJC (which, by the way, never mentions causes of any kind, be they just or unjust) has the feel of a bad early-eighties console game, with very primitive action, only a few items, and rooms that vary for appearances’ sake only, with no regard whatsoever to creating a believable or even consistent gameworld. It also falls into what I’m beginning to recognize as a standard trap of beginning IF authors: mocking the player for no good reason. The very first room gives us this:

You are in a cave... Now that you have light, you see there is a
spider on your leg you go screaming like a little child!

Okay, setting aside the egregious punctuation problems for just a second, I still have to ask just what this wants to accomplish. Is the game giving me some bit of characterization about the PC? Is it trying to establish that the narrative voice will be a harsh, unfriendly Hans-and-Franz kind of presence, mocking the little girlyman throughout the game? Nah, it’s just there — it seems to be little more than free association.

TLJC is one of those games that it’s hard to imagine anyone enjoying who isn’t the author. It doesn’t offer good writing. It doesn’t offer interesting technical achievements. Lord knows it doesn’t offer fun gameplay, instead serving up mind-numbing tedium of battle after battle with one (undescribed and made-up) monster, all of which feel like waiting around while various dicerolls happen without you. (Although I did greatly enjoy when the game asked if I wanted to use the “lighting” spell, and upon my assent cried “I call upon the Power of lighting!” That’ll make an excellent line for turning on lamps.)

Its puzzles (such as they are) make very little sense. Oh, there is an implementation of blackjack that felt like it had received the most care and interest of any feature in the game. I guess that goes to show that as sheer programming exercises go, it’s probably better to make card games than interactive fiction. It’s hard enough to make good IF even when you have every advanced tool in the world on your side. It’s a problem that encompasses design ability, writing ability, and programming ability too. With a card game, the first is taken care of, and the second is irrelevant, so it’s only the third that gets challenged. I think I’d have a lot more fun playing a first-time programmer’s version of blackjack than I would playing their homebrewed IF. That was certainly the case this time.

Rating: 2.4

Invasion of the Angora-Fetish Transvestites from the Graveyards of Jupiter by Morten Rasmussen [Comp01]

IFDB page: Invasion of the Angora-fetish Transvestites from the Graveyards of Jupiter
Final placement: 44th place (of 51) in the 2001 Interactive Fiction Competition

Note: This review contains one exasperated, Dennis-Miller-channeling expletive.

One of the first things that happens when Invasion (this year’s entrant in the traditional comp sub-contest of “I-have-a-longer-sillier-name-than-you”) begins is that it plays a song with a creeping bass line and a Shirley-Manson-like female vocalist. “Hey,” I thought, pleased, “that sounds a lot like Garbage!” Little did I suspect how closely that comment would come to resemble my assessment of the game as a whole. Invasion claims to be “an interactive tribute to everything Ed Wood“, the famously awful director of such cinematic nadirs as Plan 9 From Outer Space and Glen or Glenda. This, you might think, would give it some wiggle room in the quality arena. It turns out, though, that there’s “entertainingly bad” and then there’s just “bad”, and sad to say, Invasion falls into the latter category. I played it for about 45 spleen-piercing minutes before finally giving up in a raging tide of annoyance, frustration, and sheer exhaustion. With my last shred of curiosity, I glanced at the walkthrough and discovered — Good Lord! — that the game is huge, and that there are tons of things I didn’t even find. I can’t imagine the sort of person it would take to find all these things and play this game through to completion.

Whoa there, Paul. Aren’t you being a little harsh? Well, in a sense, yes. This game obviously wasn’t put together overnight. For one thing, it’s a Windows executable, and anybody who’s tried an MS visual language knows that those forms are fiddly to arrange. It’s got its own parser (of sorts), a hit points system, timekeeping, and lots of other stuff. So it clearly was the product of some effort. In another sense, though, I don’t think my view is that harsh at all. This game is loaded with bad, irritating, horrible factors, things that you can’t help but suspect were put in there on purpose to annoy you. Little details like, oh, capitalization, punctuation, putting spaces between words, blank lines between text blocks, printing the contents of a room with the room description, and other such niceties are handled… shall we say… capriciously. I’d give an example but, unsurprisingly, the game provides no scripting function, and randomly clears the output window every so often, making even my Isolato Incident method quite impossible to carry out. More aggravation: image windows pop up every so often, which can’t be controlled from the keyboard — a special trip to the mouse is required to shut these down.

But this is all cosmetic, right? Sure, so far. Oh but don’t worry, there’s lots more. The game occurs in real time, and NPCs flit in and out of rooms like angry insects, sometimes changing locations as much as, oh I don’t know, once every two to three seconds, which makes it darn tough to actually interact with them, since by the time you’re finished typing the command, they’re gone. Not that they’re worth much when they stick around, as they tend to spit out uninformative, unpunctuated, and often just plain uninteresting phrases, on the rare occasion that they have any responses implemented at all. The game also throws random information at you without explaining it in the slightest. For example, at some point, you’ll see a flash of light in the sky and the game will print “** Quest : killer on the loose **”. Huh? Whaddaya mean, “Quest”? What am I supposed to be doing? How do quests work in this game? Who’s giving me a quest, and how does a flash of light tell me that there’s a killer on the loose anyway? Should you fail to figure it out within some set amount of time or moves, the game abruptly ends. Sometimes the parser ignores input altogether; a command like “drop all but nutribar” will drop everything… including the nutribar. And there’s only one savegame allowed. And there’s a money system that is seriously whacked. And… ah, fuck it. Who wants pie?

Rating: 1.8

2112 by George K. Algire as George K. George [Comp01]

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

Unlike the other game at the IF Archive by this title, 2112 is not an adaptation of the 1976 Rush song. There are no Red Stars of the Solar Federation, no Temples of Syrinx… really, no Ayn Rand-inspired dystopian sci-fi whatsoever. Instead, this game just happens to be set in the year 2112, and casts the PC as a middle school student taking a field trip to humanity’s scientific outpost on the planet Mars.

The futuristic trappings are there, but I wouldn’t exactly call this game science fiction. Its vision of the future is more or less a straight transplantation of present-day life into a century from now, with very little extrapolation for change. The students travel to Mars in a Boeing 797, and upon reaching the planet, the PC finds a Starbucks, a Gap, even a “2113 Dodge Aries Planet Hopper.” As the author jokes in the readme, “It’s a shame they don’t offer a prize for most corporate name-dropping in a single work.” The game reserves a little sneering for the various corporate presences, but I’d hesitate to call it satirical — the swipes are rather too blunt to deserve that label. Of course, the game was so large that I didn’t reach the ending in two hours, even after I spent the second hour more or less typing commands straight from the walkthrough, so there may have been a stinger that I missed later on in there, tying the whole thing together and making some kind of point. More on the size a little later.

This not-quite-science-fiction, not-quite-satire game was also written as a Windows executable, using a homegrown parser. Every year, the IF competition seems to attract one or more of these, and I have to say, I find it rather interesting that there are enough people willing to write their own parsers and world models to actually provide a number of new creations, all with their own from-scratch code, for each and every annual IF competition. I’ve mentioned before that the urge to keep reinventing the wheel is quite a foreign one to me, and that I tend to dread these homegrown entries, as their parsers are much more likely to be problematic, snide, and annoying. Due credit, though: 2112 has one of the best homegrown parsers I’ve ever seen. Yes, it still breaks rule #1 of Paul’s Parser Manifesto: “Parsers must not pretend to understand more than they do.” One small favor is that its violation applies only to verbs, as in the following exchange on the occasion of finding a stuck hatch:

>pry hatch
You don't figure doing that would help you much.

Well actually, I did figure doing that would help me. That’s why I typed it. Turns out the game would have responded exactly the same way if I had typed “rpy hatch.” However, on the positive side, the parser has a very useful and ingenious way of disambiguating. For instance:

>drop note
. . . note
Which of the following do you mean? 1) the small yellow note, 2) the
pile of notebooks? Just hit 3) to forget it.

After issuing this question, the game disables all keys except 1, 2, and 3, thus preventing accidental input while preserving (through the last option) player freedom. I thought this was a great way to prevent the pernicious “Let’s try it again: Which do you mean, the note or the note?” problem. 2112 also had several fun features available, such as a customized game window, appropriate (and sometimes startling) sounds, and multicolored text. It even provided most of the features I’ve come to expect from IF, such as scripting capability and undo, though I was hesitant to use the latter because it required restarting the former.

Usually my screed on homegrown games is that nifty features don’t matter as much as a solid parser. 2112, though, has both. You’d think I’d be satisfied. Well, it turns out that reasonable game design is nearly as much of a must as a good parser, and it’s here that 2112 doesn’t quite make it. I’d played the game for about an hour and couldn’t figure out what to do next — the game was telling me I was still in the preface, despite my having explored a couple dozen rooms and solved a variety of puzzles. So I checked out the walkthrough, and guess what? I’d failed to find a vital item in the first 10 moves of the game, and there was no way to recover that item, nor to substitute its use in the puzzles that involved it. I had to restart, and let me tell you, I was gritting my teeth.

From that point, I was going straight from the walkthrough, and although I did this for a straight hour, I still wasn’t able to finish the game. What this means to me is that 2112 is in no way a two-hour game. Consequently, it dodged the pet peeve I expected it to hit (shoddy homegrown parsers) and ran smack into two others (games inappropriately large for the competition, and games that close off without warning.) Oh, I almost forgot to mention: the game suffers from a number of spelling and grammar errors, too. Make that three pet peeves. 2112 is a slick piece of work, and it didn’t need TADS or Inform in order to be as richly interactive as it needed to be. What it did need, however, was to take a few lessons from the game design ethos that the IF community has evolved alongside its development systems.

Rating: 6.6

Escape From Crulistan by Alan Smithee [Comp00]

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

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

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

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

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

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

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

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

Rating: 2.1

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

SNOSAE by R. Dale McDaniel [Comp99]

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

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

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

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

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

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

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

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

Rating: 5.0