The results are mixed. The prose can get rather florid -- long, long sentences one after another -- but is mostly pretty good, and it can in fact be argued that the prose style matches the baroque structure it describes. I have more conflicted feelings about the design. In an earlier review, one where I was complaining about scenes that only make one option available, I asked "Why even give me a prompt at all?" It appears that Jacks is the answer to my question. At a number of junctures in the game, it only takes a very minor action, such as moving in a particular direction, to impel the PC to perform a long sequence of actions, all of which are out of the player's control. In a way, this is fine, since most of the actions performed would be very difficult to communicate to an IF parser, not to mention difficult to guess. However, this design choice once again tips the balance away from interactivity. Every time the PC makes a bunch of independent choices, I feel more and more like I'm not really involved in the story, like I'm just there to hold up the cue cards so that the plot can continue. Still, of all the minimally interactive games I've played in this year's competition thus far, Jacks is one of the most successful. It's worth examining the game more closely to find out why. For one thing, the milieu is involving enough that just seeing the plot unfold is interesting. This gives Jacks a leg up on games that are set in a cardboard cutout genre world, or whose plots are a string of nonsensical non sequiturs -- even though I didn't have much influence on the plot, I was interested in it. Another factor which helps to counterbalance Jacks' lack of interactivity is the fact that it doesn't make its puzzles too difficult, and it allows for multiple solutions at the most important juncture. When there is only one way to advance through the game, the action (and the fun) grinds to a halt pretty quickly if that route is difficult to find. Jacks never falls into this trap, instead opening the next scene from fairly minor actions on the part of the player (usually involving examining everything or doing the obvious thing with the few items to hand.) Moreover, at the one juncture where the action might be difficult to guess, the author wisely provides for a number of actions that will resolve the situation, and gives each one its own lengthy text. In fact, I was interested enough in the situation at that after I finished the game I consulted the walkthrough and tried out the alternate solutions. For each action, I was rewarded with a different series of clever machinations on the part of the PC.
Oh! How could I forget? Jacks also features a really cool technical feat, which makes for some very funny moments in the beginning of the game. In the opening scene, an E is making a lengthy speech that uses lots of words, and says basically nothing. The game accomplishes this effect through the use of a random doubletalk generator. Each turn, the E comes out with randomly generated phrases, all of which perfectly mimic the kind of empty speech that often fills long orations. A sample: "One part of the whole must be that you should sing each song as if it will personally show others each other." The mechanism for this doubletalk generator is complex and masterful -- frankly, it's worth the download time just to see this thing in action. And you'll have no trouble lingering in the first section, since the author has provided a number of things which must be examined before the action can continue. Jacks is another fairly non-interactive entry into this year's competition, but through technical innovation, fresh milieu, and shrewd design, it partly makes up for what it lacks in gameplay.
But hey, as the game itself reminds us at several points, it's only a "three-chord" effort. Indeed, one of the most endearing things about HeBGB is the way it evokes the D.I.Y. (Do It Yourself) spirit of punk, making a joyous noise even though it's no virtuoso. The author reinforces this viewpoint by cautioning us in the credits that HeBGB "does not represent the real capabilities of the Alan Language but does demonstrate Alan's amazing ability to allow someone who has never done an iota of computer programming of any kind to produce SOMETHING within a few weeks!" This is a very nice thing to say about a programming language, and in fact HeBGB is quite playable despite a lack of programming polish. However, there are a number of things missing from the game that the average game programmer shouldn't have to worry about at all. For example, the game offers no "undo" function, nor an "oops" verb. Some simple things run contrary to convention, such as a "<More>" prompt that accepts only the Enter key, rather than the space bar or any random keypress. Some fairly basic verbs are missing, such as "throw". I attribute these flaws to deficiencies in the ALAN libraries (or perhaps, in some cases, the ARUN interpreter) rather than a failing on the author's part. It's unreasonable to expect every game author to program conveniences like "undo" on their own. That's what libraries are for, and by being such a complete game in lots of other ways, HeBGB demonstrates the limitations of ALAN -- not the language, but the default shell given to potential authors.
What the author can control he provides quite well. Despite a few spelling and formatting difficulties, the prose in HeBGB (especially when it's not doing a Lovecraft parody) combines a snappy sense of humor with strong descriptions. The plot is clever, allowing a good deal of exploration while never opening so wide that the story feels aimless. There are a number of good things about the design, including the fact that the game is carefully structured in such a way as to allow players a second or third chance to obtain items that they may have failed to notice or pick up the first time around. These chances are always well- integrated within the game, and feel natural rather than gratuitous. This design choice allows HeBGB to close off early sections of the map once their purpose is served while avoiding the trap of making the game unsolvable once those sections are unavailable to the player. The puzzles, for the most part, are quite good, maintaining a high level of originality and (with one exception) escaping "guess-the-verb" syndrome. The one qualm I did have about the puzzles is that at several points, you must return to apparently unfruitful locations to obtain an object that wasn't there before. The reasons given for the appearances of the objects certainly make sense, but from a gameplay standpoint it's not very logical for a player to assume that visiting and revisiting empty locations will be rewarded. Moreover, some of the actions required to make the object appear in the empty location don't seem to have very much causal influence. In other words, the action which puts the object in the formerly empty spot gives players little reason to guess that visiting that spot again will be worthwhile. These quibbles aside, I enjoyed HeBGB quite a bit, and while I was wishing for the conveniences granted by more sophisticated libraries, the roughness of the game was in keeping with its topic, and that resonance lent it an unexpected charm.
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.
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.
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.
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.
Paul O's 99 Competition Game Reviews -- Page 6 / Paul O'Brian / obrian at colorado.edu / Revised November 2002