Tag: disambiguation

The Pickpocket by Alex Weldon [Comp00]

IFDB page: The Pickpocket
Final placement: 32nd place (of 53) in the 2000 Interactive Fiction Competition

It’s the kind of situation that happens all too often in comp games: after a long period of frustration, I finally turn to the walkthrough, only to find that the correct solution was unguessable due to the game’s omission of a critical detail. That’s just the situation I thought I was in when I finally turned to the walkthrough for Pickpocket and saw that it suggested the manipulation of an item I had never seen at any point in the game. So I marched on over to where the item was supposedly to be found, all set to write a cranky note for this review, and discovered something that surprised me: the item was in the room description. In fact, it had been there all along.

It was then that I realized that the game had pulled a rather clever, but completely fair, trick on me. (The rest of this paragraph could be considered a mild spoiler, I suppose, though it really just boils down to the standard admonishment to read carefully.) You see, what Pickpocket did was to announce the presence of an important item, but to announce it in an utterly casual way, burying the sentence in the second line of a rather long-winded room description, a description that is almost identical to eight other room descriptions in the game. What’s more, the game ensures that you’ll encounter at least three of these near-identical descriptions before you get to the one with the important difference.

This devious but totally reasonable trick worked perfectly on me — by the time I got to the critical room (and I got to it seventh, not fourth), I was blowing past the room descriptions, assuming that they were all pretty much the same. Even better, it’s the perfect trick for a comp game by a first-time author, since if most of its players are like me they’ll be (A) going quickly, hoping to finish within the two-hour time limit, and (B) not expecting anything quite so devious in what is otherwise a fairly straightforward game. When a game gulls me so completely, I can only salute it.

Then again, there is another, less laudable reason why I turned to the walkthrough: I encountered a bad bug. This bug was of the “Which do you mean, the door or the door?” variety, which is even more disappointing in an Inform game than it is in a TADS game, since Inform’s library has never had any particular propensity for creating that kind of error, where TADS’ library did (though I don’t think it does anymore.) After I encountered this bug at what seemed to be the climactic scene of the game, it was easy to assume that my failure to progress was the game’s fault, not mine.

Even after I discovered how the game had hoodwinked me, I felt disappointed that it contained such a serious bug, because without the presence of that bug (and a few others, and some few-and-far-between spelling and grammar errors), I might have felt compelled to continue working at the game and had the pleasure of solving that puzzle myself. The whole experience just reminded me again that one of the most important reasons for betatesting is that once players encounter a serious bug, they’re unlikely to take the rest of your game very seriously, having lost faith that it knows what it’s doing.

The other lesson that Pickpocket underscores is the importance of maintaining some logical consistency in constructing the PC. First of all, the premise of Pickpocket strains credibility considerably: a street urchin has made off with your money pouch, so you decide to wait until nightfall, then prowl into the most dangerous slums in the city to find the urchin and recover your money. Only in a text adventure could a character like this seem like a normal person — any book, TV, or movie character that made such a choice would come across, at best, like Charles Bronson gone way off his meds, only unarmed and not at all intimidating.

Certainly any real person that tried to hunt down a pickpocket just by wandering into the slums, hours after the robbery, would deserve to have her sanity questioned. But even if we grant this premise, the game still demonstrates a puzzling lack of moral consistency. For example, the game’s response to OPEN CASH REGISTER is “You’re trying to catch a thief, not embark on a life of crime.” Yet to recover this money, you’ll end up committing theft, assault, menacing, breaking & entering, and vandalism. If that’s not a life of crime, I’m not sure what is. Overall, Pickpocket is an enjoyable game with one dynamite ace up its sleeve, but that sleeve is still a bit ragged from logical inconsistency and technical errors.

Rating: 7.8

Purple by Stefan Blixt [Comp98]

IFDB page: Purple
Final placement: 15th place (of 27) in the 1998 Interactive Fiction Competition

The world is ending. It’s not immediately apparent at first, because you and your brother are living out on the remote island of Lino Kapo, quite isolated from the political troubles of your future Earth(?), whose nations have names like “the Kollagio Antarktika” and “the Oceanic Republic.” But listen to the TV. (The nations have morphed so much that people are living in places like Antarctica, but we still get our information from the TV. Some things never change.) Political battles between the nations have led to the use of the deadly K-bomb, which releases, unsurprisingly, deadly K-radiation! (Where are you when we need you, Lane Mastodon?) This radiation turns the sky a disturbing purple, and threatens to choke out humanity in its menacing clouds. (By the way, the color of the sky is the meaning behind the game’s title. Hallelujah, a title that makes a little sense!) Lucky for you, your brother is a bit of a tinkerer, and has come up with this device called a Phoenix Nest, into which you can climb and sleep away the death of the world in suspended animation. The Nest wakes you up when the levels of K-radiation have dropped enough for humans to be safe. So in you climb, as the world ends, to await its rebirth and greet it with your own. Now, I know I’ve made a bit of sport with the plot here, but details aside I like this premise. It has a drama and immediacy to it, it creates a perfectly plausible reason for the world to be basically deserted, as it so often is in IF, and it gives the author a blank slate onto which a compelling alternate world can be drawn. Not to mention the fact that the mysterious “K-radiation” can be an excuse for almost any biological oddity you care to dream up.

The good news is that from this imaginative premise, Purple takes several very creative steps. The flora and fauna of the post-apocalyptic world are pleasingly exotic and interesting. The landscape is convincingly changed, and the language used to describe the new reality can be quite vivid. The bad news is that these good ideas are very poorly implemented. Let’s start with the writing. Purple isn’t exactly riddled with errors in the same way that, say, Lightiania was. However, there are enough mechanical (spelling & grammar) problems to be a serious irritant. Many of these problems aren’t exactly errors, but rather awkward turns of phrase that make the game harder to read. Purple‘s descriptions often sound as if they were translated from another language into English, by a somewhat inexpert translator. The awkwardness throws off the rhythm of the game’s prose, and I found myself frequently reading text more than once in order to figure out what it was saying. Then there are those sentences that really don’t make sense, like this one: “Urging to cover your eyes from the bright light, you still can’t move a finger.” I think that what this means is that you have the urge to cover your eyes, but you can’t because you’re paralyzed. I figured this out, but it took a minute, and for that minute I was thrown out of the story; in a text adventure, where prose is all there is, being thrown out of the narrative like this is problematic. Add a few outright spelling and grammar errors, and the game starts to feel more like work than fun.

Compounding this problem are some trouble spots in the code. There were several instances of disambiguation troubles, almost enough to make me feel like I was playing a TADS game. Scenes like this were not uncommon:

>X CEILING
Which do you mean, the up, the ceiling or the hole?

>HOLE
Which do you mean, the ceiling or the hole?

>CEILING
Which do you mean, the ceiling or the hole?

To make matters worse, I also came across several run-time errors of the flavor ** Run-time error: [Name of object] (object number 211) has no property to read **, and in fact once crashed WinFrotz altogether with a “No Such Property” error. Besides these basic errors in the code, there were also a number of problems with the way objects were implemented. For instance, you have half of a tool that you have to complete by improvising the other half, and putting one piece into the other. Unfortunately, unless you choose the right piece to insert, you are told that the other half “can’t contain things.” I also had trouble with a number of the puzzles, and was unable to figure them out without a walkthrough, but I can’t tell if that’s because of the stumbling English and buggy code, or the difficulty of the puzzles, or just my own denseness. On balance, I’d say that Purple is a very rough version of what could become a good IF vignette. After it’s undergone a few vigorous rounds of beta-testing, you might want to give it a try.

Rating: 4.1