legend, >INVENTORY

Really Late Reviews #1: The Space Bar [misc]

[I wrote a few reviews of graphic adventure games in 2001, and Stephen Granade hosted them on the About.com interactive fiction site he ran at the time. I called them Really Late Reviews because, well, I wrote them long after the games in question had been released. About.com has gone so far down the Internet memory hole that I can no longer retrieve those reviews in the context of the site, so I’m taking their dates from the original text files on my hard drive. That means this review of The Space Bar was written on January 27, 2001.]

For several years now, I’ve had a growing pile of commercial adventure game CDs sitting next to my computer. For one reason or another, I haven’t gotten around to playing them, but when the millennium turned, I decided I was going to change all that. I’m playing through them now, and for each one I play, I’m hoping to write a review. These reviews won’t be aimed at helping people decide whether or not to buy the games — they’re mostly out of print now, so the point is pretty moot. (Although many of them could no doubt be obtained through eBay or bargain bins.) Instead, I want these “Really Late Reviews” to be meditations on what works and what doesn’t in graphical adventure games, as illustrated by the successes and failures of each work under scrutiny.

The game on top of the pile was The Space Bar, Steve Meretzky‘s first post-Legend foray into graphical adventures. Meretzky has a good name among text adventure enthusiasts like me for having written landmark Infocom games like Planetfall and A Mind Forever Voyaging. I wasn’t as fond of his later works for Legend Entertainment, the Spellcasting series, because what clever writing and puzzles they did contain were submerged in a sea of juvenile, sexist humor, but they were commercial hits and plenty of people enjoyed them. After he left Legend, he founded a company called Boffo Games, Inc., and created The Space Bar, a large adventure game that was to be Boffo’s flagship product. Despite good reviews, the game sunk, and so did Boffo. Maybe this postmortem will provide a little perspective on just where TSB went wrong.

The game puts you in the role of Alias Node, a human detective on the seedy world of Armpit VI, investigating a robbery and murder whose culprit has been traced to a dive called The Thirsty Tentacle. The bar, like the rest of the galaxy, is populated by aliens of various races, but very few other humans. Your job is to interview these aliens, looking for clues about the identity of the killer, and using your special ability of “Empathy Telepathy” to enter their memories and guide those flashbacks to discover vital bits of information. In effect, these flashbacks serve as mini-adventure games in themselves, and the bulk of TSB is spent navigating the memories of various aliens, with occasional excursions back into the Thirsty Tentacle to meet other aliens and, finally, to catch the criminal.

The aliens are definitely the best part of the game, springing as they did from the imagination of Ron Cobb, the same guy who designed the eye-popping oddities that populate the Star Wars cantina scene. Copious background information on each alien species enlivens the game, and deepens the experience of otherness that permeates the flashbacks. Visually, too, the game does a terrific job with the aliens, and here we see one of the great strengths of graphical games. Text is wonderful for evoking interior worlds, but for the presentation of bizarre shapes and structures, it’s hard to beat good graphics. For example, a text game might tell you that Sraffans have hourglass-shaped pupils, but it would be hard put to present the labyrinthine network of veins surrounding the pupil, or to take your perspective inside those eyeballs as the flashback begins. TSB uses graphics in some clever ways throughout the game, including a freaky perspective from within the compound eyes of an insectoid race.

So The Space Bar is clever, and visually engaging. It also has its fair share of funny moments, thanks to Meretzky, who’s much funnier when he’s not aiming at 13-year-olds. Unfortunately, fun as it is to look at, it’s often not much fun to play. In struggling through the game, I found myself thinking quite a bit about the problems of translating text-game writing experience to the creation of graphical games, and wondering if TSB‘s many flaws stemmed from those problems.

Take, for example, the game’s interface. If you don’t have a parser and prompt, something must obviously take their place, and in this case it was the standard 360-degree panning worldview (with a bit of up/down axis as well), augmented by a multi-purpose onscreen device called the PDA: a combination map, inventory, system command portal, voice-mail receptor, and information storehouse. The idea of the PDA is a sensible one, but its implementation in TSB was extremely clumsy. Rather than occupying a stable portion of the screen, it rises up to half-obscure the main window whenever you click on it, spending the rest of its time half-visible, with half its features unavailable.

One of the most important of these unavailable features is the voice-mail indicator, which blinks when Alias receives a message. Because the light is obscured from view except when the PDA is fully visible, you end up receiving messages and not knowing it for dozens of turns, until the little voice inside your PDA says “Have you noticed your message light is blinking?” Why no I hadn’t, probably because I CAN’T SEE IT! It’s silly that the blinking light is hidden, but even the hidden light is a better solution than the one the game adopts occasionally, which is to have the PDA suddenly rise up and stop all action as a message comes in and is played.

When this happens (and it’s usually at the worst times), the player has to wait for the game to speak its message before continuing on with any actions, and therein lies another significant difference between graphical and text adventures. Text adventures print all their output, which takes pretty much no time at all. Graphical adventures have voice-acting, which means that to receive the dialogue, the player has to wait as long as it takes for that dialogue to be spoken… every single time. The voice acting in TSB is excellent, so it’s a pleasure to hear the dialogue in real time when you’re hearing it initially, but when you already know what’s going to be said, even the best voice acting can become tedious indeed. TSB often provides the option of hitting Esc to halt these sequences, but all too often Esc doesn’t have an effect, and you’re left drumming your fingers while a phrase plays for the tenth time.

Even worse, when realtime voices are overlaid on turn-based gaming, the resulting timing confusion can turn an extremely simple puzzle into a maddeningly difficult one. For example, in one of the flashbacks, you’re waiting for your name to be called before you can leave a particular room. However, there are about 10 voice phrases that play before that happens, each of which is around 30-45 seconds long. The phrases play one per turn, so if you perform actions which advance the turn counter (examining things, inventory management, etc.) and space them less than 30 seconds apart, the phrases pile up and play one after the other. When this happens, you’ll hear your name called, and try to leave the room, but the turn when you were supposed to do that has long passed, so the game goes on to say “Oh, too bad you didn’t leave the room — you lose” as you’re frantically clicking away. Doctors recommend against this sort of game design, as it leads to many cases of heads embedded in monitors.

Another sin of sound design which TSB commits over and over is having background noises drown out crucial information. For example, there’s a scene where you’re performing your actions while a thunderstorm rages in the background. In a text adventure, the scene would look like this:

> EXAMINE WATERFALL The water sounds funny -- there might be something behind it.

KER-POW! Deafening thunder shakes the ground where you stand.

In The Space Bar, you click on the “Examine Waterfall” icon, and what you hear is the flashback character’s voice: “The water sounds funny. There mi– KER-POW! –it.” Then the sound you hear is yourself growling, as you realize that the game has stupidly and randomly allowed a background sound to prevent you from learning information that, as the character, you should theoretically already know. In other words, an actual sound has obscured a symbolic sound, the latter of which is only meant to represent the character’s interior dialogue. This happens over and over again, in several flashbacks, and each time it does, you have to repeat the action and hope you get lucky enough to hear the information you’re supposed to have.

That same thunderstorm flashback also features another one of TSB‘s biggest gaffes: the realtime puzzle. There’s a chase sequence in this flashback in which you have to make the correct series of clicks and rotations, in an extremely limited period of time, and if you don’t the flashback ends unsuccessfully. Maddeningly enough, this is exactly the time when your PDA chooses to rise up and halt all action until it finishes playing the incoming message. Because restoring from a failed flashback is blindingly dull [you have to listen to the failure message in real time, then get past the transition animation, then trigger the flashback again, then another transition animation, then the beginning-of-flashback animation, and only then can you restore your game], the punishment for failure is quite steep.

Add to this the fact that the processor load in that flashback makes cursor movement jerky, and panning unreliable, and you have one annoying roadblock. Now, I’m not of the school of thought that believes adventure games should never ever have realtime action portions, though I do believe it’s a bad idea to throw one arcade sequence into an otherwise traditional adventure game (which is exactly what The Space Bar does.) I enjoy both adventure gaming and twitch gaming, and don’t mind seeing the two mixed, but they have to be done well — if I fail, I want it to be because of slow reflexes, not a slow processor. My P-166 seems pretty pokey these days, but in 1997, when The Space Bar came out, it was well above the game’s minimum requirements.

Still, I gritted my teeth through many attempts at this puzzle before finally, gratefully getting past it. In a text adventure, that realtime puzzle would probably still be annoying, but because the processor demands of text are minimal, the computer’s speed would very likely not be the bottleneck that impedes completion of the puzzle.

Another side effect of the increased complexity of sounds, images, and animations in a graphical adventure game is their increased size and consequent separation onto multiple disks. The Space Bar comes on three CDs, two of which contain flashback material and the other one of which contains all the sequences within the bar itself. As a result, every time a flashback begins or ends, you have to switch CDs. I needn’t point out that a text adventure is highly unlikely to fill more than one CD and therefore to require such constant switching, but I will note that the drudgery of such switches imposes unnatural limits on both design and playing.

Because I was trying to minimize CD switching, I stayed within each flashback and tried to solve them in their entirety one at a time, instead of hopping from one to the next anytime I got stuck, as I probably would have in a text game. In effect, the disk switching became another of the game’s many resource management problems, but one of its least enjoyable. The best of these puzzles take advantage of the potential of graphics to easily demonstrate spatial relationships, and end up achieving effects that would be extremely difficult in a text game. The worst of them work through the game’s regular interface, and the presence of graphics and sound slows down the solving process to no real benefit. Elements that slow the process of solving a puzzle by means of arbitrary and pointless delays make that puzzle much less fun. Text has an advantage here, because its elements very rarely cause time delays.

Another advantage of text is its ability to clearly separate objects. For instance, in one of the game’s flashbacks, you stand before a house. There’s a boat locker in front of the house, from which you must obtain a vital object. The problem is that the locker blends in a bit with the house itself, and both the house and the locker are clickable objects. Consequently, you can click on several features of the house, all of which the game will process as the house itself. The only exception to this is the locker, but when the windows, the roof, the chimney, and the pipes are all called “House”, why would a player think that the little brown square representing the locker is anything but another unimplemented house feature? What’s more, you can get irretrievably stuck in the flashback and not know why — I had to look at a walkthrough, and when I did I said, “What locker?” In a text adventure, this simply wouldn’t be an issue, because objects don’t overlap:

Beside the House Be it ever so humble, this is your home. The roof, windows, chimney, and pipes may all be a bit ramshackle, but they're all yours.

There is a boat locker in front of the house.

There’s no chance you could miss the boat locker (as I did playing TSB), because the interface never obscures it.

Reading through this review, I’m worried that it sounds like I’m railing against graphic adventures in general, and arguing that text is always better. I hope it doesn’t sound like that, because I don’t believe that. For one thing, The Space Bar has several problems that are equally possible in text adventures (an extremely irritating maze, several bugs, one of which almost kept me from finishing the game.) For another, I don’t think that superiority and inferiority enter into the equation at all — I just think that text adventures and graphic adventures are distinctly different forms, kind of like (to employ a tired analogy) novels and films. The skill sets required to create each of them overlap a bit, but not nearly as much as you might guess. Playing The Space Bar felt reminiscent of watching a film directed by a really good novelist who knows very little about moviemaking. You can see what was intended, and if you look harder, you can see why for the most part it all falls horribly flat.

Bane Of The Builders by Bogdan Baliuc [Comp01]

IFDB page: Bane of the Builders
Final placement: 28th place (of 51) in the 2001 Interactive Fiction Competition

In what is either a shameless rip-off or an unwitting duplication of the Heechee backstory behind the Gateway games (and novels), this game posits a “mysterious race known as the Builders [who] had left many traces and artifacts throughout the galaxy.” The game opens as a planet has been discovered that might yield the secret of the Builders’ demise, though it’s unclear how the simple existence of “an energy source” would promise such vital information. No doubt the answer could be supplied by the foremost expert on Builder civilization, a fellow known only as “the Professor.” (I was torn as to whether to picture him as the Professor from Futurama or the Professor from Gilligan’s Island.)

The PC’s role is that of a starship ensign who has become “quite friendly” with the Professor (though apparently not friendly enough to learn a first or last name), and who is sent down to accompany said Professor on his investigative mission in this Builder artifact. Now, it can fairly be said that this scenario is rather illogical — would a lowly ensign really be the only one to accompany a scientist on such an expedition, and if so, would he really be asked to wait around in the ship instead of providing armed support, and would he only start worrying after the Professor goes missing for almost a day?

However, such objections aside, I enjoyed the setup of this game. It felt pleasurably reminiscent of sci-fi juveniles from the 1940s and 50s, right down to the cheesy idioms uttered by the characters. (“Thank Space you’re here!”) I especially enjoyed how Star Trek and its clones have become so ingrained in the culture that when the game provided a blaster “set to kill”, I knew that “SET BLASTER TO STUN” would work, even though the game provided no explanation of the blaster’s settings. It worked. Unfortunately, letdowns occur throughout the game that prevent it from being a fun romp through Golden Age and TV sci-fi tropes.

The problem isn’t with the writing, which is pretty serviceable throughout, even earning extra points from me for using “its” and “it’s” correctly the entire time. The formatting is fine too, although it seems to miss a few blank lines here and there. The implementation, on the other hand, is a bit more deeply troubled. Several times, the game seemed to want to produce the effect of the room’s contents shifting in front of the PC’s eyes; the room description would print, then a line reading “The world around you suddenly shimmers and changes…”, encased with blank line or two on either side, and another room description would print. So far, so good.

Except that sometimes, the descriptions were identical. Other times, a third room description would print after the second one, with the “shimmer” line printing without blank lines preceding it. I doubt this was intentional — it’s a feature that needed more testing before the game’s release. Another serious problem is that in a climactic scene, the most important object is unimplemented. I was more than a little nonplussed to be told about a Nasty Evil Menace by the game, but to be told, “You can’t see any such thing” when I asked to examine the Menace.

The biggest problem, though, is the puzzles. First of all, there’s a maze. There’s no redeeming twist to make it interesting or better — in fact, the only twist makes it worse: the maze doesn’t use compass directions, instead relying (quite arbitrarily) on “left”, “right”, “forward”, and “back” instead. Consequently, you not only need to keep in mind where you are in the maze, you have to keep in mind which way you’re facing. This is the sort of thing that feels a lot more like work than fun to me in a game.

Perhaps even worse are a couple of authorial telepathy puzzles, which demand highly implausible or even nonsensical actions to solve, and offer no clues whatsoever as to these solutions. I’m not sure whether I object more the puzzle whose solution seems impossible based on its object’s description, or the one whose solution is just totally illogical. Either way, having them both in the same game is not a good thing. I have sympathy for people who struggle with puzzle design, because I’m one of them. But it’s better to have no puzzles at all than puzzles that aren’t any fun.

Rating: 5.2

Lovesong by Mihalis “DarkAng3l” Georgostathis [Comp01]

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

This game was my first introduction to the Quest development system, and I wish I could say I was impressed. I mean that. I’m all for people using their skills to create IF stuff that’s new, cool, and functional. What I can’t get very enthusiastic about, though, is people using their skills to create IF stuff that isn’t as good as stuff that already exists. Sure, Quest looks nice and everything. But unless the author of Lovesong broke or disabled something, its parser is less sophisticated than, say, that of the first Monkey Island game. Based on the help text, the parser seems to understand 19 verbs. Counting synonyms. And 9 of those are directional commands. And another one was (I think) added by the game’s author.

Such simplicity allows the game to be almost completely mouse-driven (or it would if the mouse support didn’t break halfway through), but really… what’s the point of that? It’s one thing to present a mouse interface in a graphic adventure, but a text adventure? Why? Legend tried it, but I can’t imagine that many people actually played all (or even most) of any Legend text game using the mouse alone. I guess it cuts down on guess-the-verb, but really, is the gain worth the price?

It seems to me that what Quest allows people to do is to create text games with the interface of a graphical game. To my mind, that’s a pointless endeavor — it deprives text games of one of their major strengths, and adopts a “hands-off-the-keyboard” aesthetic from graphical games that has a stultifying effect on game design. The worst of both worlds. No doubt Quest has some features unused by Lovesong, and those may go some distance toward making it useful. But ultimately, I don’t think that any nifty features are going to make a big difference. You know why? Sure you do: THE PARSER IS MORE IMPORTANT THAN THE NIFTY FEATURES. Same old song.

Of course, no matter what development system had been used to write this game, Lovesong would still be deeply troubled. The big problem here is English. Apparently, English is not the author’s first language. As the game’s author bio asserts, “Please forgive me, but me English are not fluent enough. I pray that some mistakes won’t ruin your gaming experience.” Well… sorry, but it’s really hard to enjoy a text game written in broken English. (Unless the English is broken on purpose, a la Gostak or For A Change, but that’s a different matter entirely.)

In fact, I have to wonder: if someone isn’t fluent in English, but wants to create a game, should that game really be a text adventure in English? I’ll probably get flamed for that, and really, I don’t mean to be some kind of Guardian of IF Purity, but a text adventure is a piece of prose, just like a novel, short story, or poem. If you’re not fluent in a language, how can you possibly craft a good piece of prose in that language?

Maybe it can be done, but Lovesong isn’t it. Its plot is sorta sweet, but the whole thing is so hampered by the twin burdens of its straitjacketed development system and its badly mangled writing that there’s not much opportunity to enjoy anything else about the game. In addition, it has its own implementation problems, though it’s always hard to tell what’s the game’s fault and what’s the system’s fault. Several times, the game just had no response at all to a command. About halfway through, the mouse buttons stopped working. Towards the end, the “save” command stopped working. Oh well — at least I can now say I’ve tried a Quest game.

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