Tag: jzip

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

Pintown by Stefan Blixt [Comp97]

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

Playing Pintown was an extremely frustrating experience. The game was loaded with errors, both in its writing and in its coding. Even the walkthrough had bugs. I went through two hours and two interpreters trying to get the program to respond in such a way as not to crash the game, and after 45 minutes I stuck with the walkthrough. Even with the walkthrough, it took me another hour to finally get the game to stop crashing, and once I had done that a runtime bug derailed three puzzle solutions and magically eliminated the person following me. By the time I figured out that the game is unwinnable (at least according to the walkthrough provided by the author) I really didn’t care anymore. The game’s puzzles were infuriatingly arbitrary, its plot made no sense, and its prose was both very unhelpful and heavily burdened with grammar and spelling errors. I recognize the fact that the author of Pintown is Swedish and therefore might not have the best grasp on English. That’s why beta testing is important — not only does it get rid of those pesky game-killing bugs, but testers who are fluent in English can help correct all those mechanical mistakes.

In Pintown you play a musician (though the game will only respond to “play guitar” in one location at one particular time) who’s just come off a bender where you had a major row with your girlfriend. Now it’s your task to find her and make peace. Of course, the game gives you no hint as to where she might be, and characters who seem to have no programmed responses to any questions or actions aren’t much help either. A vital part of the plot hinges on your getting into a parking garage, but you can only get in there at one crucial point in the game, and your are given no hints as to when and how that point arises. I only managed to get that far with the walkthrough in hand. As to how the game ends, I have no opinion since I never got there — the game’s bugs prevented me.

This game recalled some of the more disappointing moments of last year’s competition, and I found myself once again asking that question: why would anyone who cares about his work at all enter a buggy, error-laden, unwinnable game into the IF competition? There’s clearly a precedent (upheld by many of this year’s entries) of high quality among many of the competition games. And surely authors understand that the idea of the competition is to encourage the writing not just of IF, but of good IF. So why would people humiliate themselves by entering poorly written, untested games? It’s a puzzle too tough for this adventurer to solve.

Prose: The prose in Pintown was weak. On the one hand, it’s one of those situations where there are so many technical errors that the overall prose quality is dramatically impacted for the worse. Then again, even without all those errors, I still think the prose would be bad. There’s a character who responds to every subject with “I don’t know.” Room descriptions leave out crucial objects. Sentences often make little sense. Clearly, there was a lack of effort here.

Plot: It’s hard to use the word “plot” in connection with a work like Pintown. The game’s basic goal, according to the designer, is “simply to get along with your girlfriend.” Of course, this is hard to do when she’s nowhere to be found until the endgame. Actually, the main goal of the game is to be in the right place at the right time, then to steal a car, set some random events in motion with an arbitrary action, then to clean up your apartment in exactly the right way, and finally to rescue a cat and “discover” your girlfriend’s hiding place. These plot points are relatively unconnected by any sort of logic.

Puzzles: The puzzles are very much of the “read the game designer’s mind” variety. First, you wake up and the first thing you need to do is go back to sleep. Then, you need to follow someone without really knowing why; if you don’t do this, you’ll never finish the game. Then, you steal a set of keys and a van to drive to your apartment. There is no alternate solution to the apartment puzzle. You can’t call a cab, or walk there, or ask anyone where it is. You’ve got to be there at the right time to get those keys and steal that van. Well, you get the idea.

Technical (writing): There were many grammar and spelling errors in the game. They include words missing letters, misspelled words, and made-up words (“trafficated?”)

Technical (coding): But if the writing was bad, the coding was downright awful. Playing the game under WinFrotz led to many game-killing bugs of the “FATAL ERROR: Illegal Object Number” or “Illegal Attribute Number” variety. Under JZIP, the game would just stop responding at random points. In addition, the game state was unstable enough to eliminate a follower and return two solved puzzles to an unsolved state, all at once. Unsurprisingly, beneath these major bugs was a panoply of minor bugs, including a dearth of synonyms, important missing verbs (like “pet cat”), and readable materials that only respond to “examine”, not “read.”

OVERALL: A 1.5