unfinished, >INVENTORY

Zombie Exodus by Jim Dattilo [IF-Review]

[I originally reviewed this game for Mark Musante’s site IF-Review, in 2012.]

Choice of Reviews

It’s been a long, long time since I reviewed a text game. Yes, I wrote a series of posts about IF-related stuff at PAX East 2010. I wrote an appreciation of GET LAMP, and a bit of a musing on applying IF-type thinking to real life. Oh, and a couple of non-interactive pastiches. But actually reviewing a text game? It’s been over three years! The last review I wrote was for Peter Nepstad’s 1893: A World’s Fair Mystery. Considering that I used to write hundreds of them, that’s quite a decline.

So recently I found myself with a little spare bandwidth, and having just enjoyed the Oscars, I decided to embark on a little mini-project of playing and reviewing the four games nominated for the XYZZY Best Game award this year. I ran the list through my handy-dandy randomatic scrambler, and out popped my first assignment: Zombie Exodus by Jim Dattilo. I was excited! It had gotten 10 nominations — more than any other game — and a nomination in almost every category! I’d never heard of Jim Dattilo, but I’ve been way out of the loop, so that’s to be expected. Off I went to check it out!

That’s when the surprises started. The game has no entry in IFDb. What kind of IF game has no entry in IFDb? So I just plain Googled it, and found that in fact, it’s a commercial release by Choice Of Games, makers of fine “Choose Your Own Adventure” (or CYOA) type stories. That required a little expectation adjustment, but it wasn’t all bad. I’d played a couple Choice Of Games offerings, and enjoyed them. Except… wait. Despite a press release which makes it sound as if Zombie Exodus was produced by Choice Of Games, it wasn’t, actually. It uses their ChoiceScript language, and is hosted by them, but it wasn’t actually created by the company. Still, that’s not a dealbreaker either. The vast majority of IF games are produced outside a commercial context!

Nevertheless, once I had done a little reading about the game, it became clear to me that I was not its ideal audience for a couple of reasons. First, it’s a survival horror game, a genre which I approach with trepidation. I’m not big on stories that aim to produce fear and disgust, without any particular reason or metaphor behind them. Second, it’s a CYOA game. Don’t get me wrong, I enjoyed many a CYOA book as a kid, and I still have affection for the genre, but compared to parser-based IF, I don’t find it particularly immersive. I tend to make decisions at random, at least at first, as I find that the majority of CYOA books and games play pretty fast and loose with the connection between choice and outcome. And indeed, that’s how I approached Zombie Exodus.

The game starts out well enough. A highly infectious virus is turning people into virtual “zombies” by disabling higher brain functions and triggering aggressiveness (though it later appears to be able to reanimate the dead as well; the story’s mythology isn’t quite in order), and society is starting to break down. As the player character, you have a more immediate problem: your sister Emma is out there in the chaos. Fair enough: setting and goal. The game begins with a somewhat clumsy PC construction section, taking the player through choices like “Are you Emma’s brother or sister?” and “While sleeping you dream of a time long ago… well, actually the past few months. In your time off, you had several activities keeping you occupied. What do you dream of?” The latter question helps establish a couple of specialties for the PC, which appear to (sometimes) open up options later in the game, RPG-style. Then, based on the choices you make in PC construction, you’re given a couple of choices for inventory items to carry. Awkward though it was, I liked the idea that RPG-ish and IF-ish features were integrated into the game’s basic CYOA structure. Those aspects promised to lend a greater depth of interaction and immersiveness than a vanilla CYOA narrative could offer.

Some of the time, it succeeds. There were definitely moments in Zombie Exodus when I felt very engaged with the story, and reconnected with that feeling of excitement I had as kid, flipping my way around some new Edward Packard or R.A. Montgomery book. Of course, those guys never wrote about zombies feasting on human flesh, but still, a driving story with meaningful choices can result in a very compelling experience indeed.

Unfortunately, all too often, the choices in Zombie Exodus are almost devoid of meaning, like the following, which comes up when you decide you’d like to steal a car to travel to Emma’s location:

Which car do you choose?

2011 red convertible BMW 6-series
2008 tan Cadillac Escalade
2004 gray Dodge Ram Pickup
2009 white Ford F-150 Pickup
2010 blue Honda Accord
1995 faded red Honda Civic

This is a fantastically meaningless choice, not to mention a level of observation that implies an incredibly car-obsessed autistic PC. How many people can identify not only the make and model of a car, but the year? How on earth could it possibly matter what color the car is? I guess maybe the bigger cars might be of more use in breaking through blockades and such, but other than that, how could a player possibly know what matters about these? This sort of thing is why I always have the randomizer handy when playing a CYOA game.

Another type of meaning-lite choice comes up rather often in battle scenes:

Heather’s back faces the zombie, and she does not notice the
imminent threat.

Shoot her with your rifle
Shoot her with your assault rifle
Shoot her with your revolver

Now, in the first section, I actually chose to configure my PC with a passion for guns, so the fact that she didn’t just grab the nearest gun to hand actually felt in character to me, but at the same time, the game starts to feel like a very degraded version of Doom when it asks me to select what weapon I’d like to use to blast away at the threat of the moment. Interestingly, there were moments when this type of choice worked well — for instance, when a zombie horde is advancing, the assault rifle seems like the clear choice. Unfortunately, I was given the choice whether or not it seemed to matter.

Aside from meaningless choices, the game’s other major flaw is that it stumbles occasionally into some pretty rocky prose, like “Now is time to make a decision”, or “There is an undescrible comfort to the room”, or “No zombies have spotted your group, though you keep watch on the closest creature thirty feet away across the street and wears a mailman uniform.” Some of the problems are just typos, and some of them require the intervention of an editor, but there are enough of them to make the game as a whole feel sloppy and unprofessional. It’s not an epidemic or anything — I’d say 95% of the game’s prose is trouble-free — but 5% is too high for anything that’s asking for money.

The biggest problem of all, though, came up right in the middle of the story, and it looked like this:

You have reached the end. Part 3 is in development, and begins with your arrival at the cathedral safehouse.

This game is not finished! Nowhere in its beginning, or its press release, or its “About ZE” web description, does anything suggest that you will suddenly be left hanging in the middle of the storyline. That is not okay with me. I’m not against episodic IF — I’ve committed some myself. But in my opinion, there are some crucial rules to follow. First, let your readers know upfront that they’re reading episode one, or episodes one and two, or whatever. Second, your release must tell a satisfying story in itself. It’s one thing to play through a game whose ending leaves some questions unresolved or hints at further developments. It’s quite another to play through a game that has no ending at all, that cuts off abruptly in the middle of a suspenseful scenario. In my opinion, such a game is not ready for release.

The fact that this game was nominated for so many XYZZY awards is fodder for an interesting discussion in itself, but I’m going to leave that aside for this review, except to say a few things. First, I think it’s perfectly legitimate to include CYOA games in the XYZZYs. Second, I think that when it comes to voting on finalists (not on nominees), voters should only weigh in if they’ve played all the games in the category. Finally, I thought the awarding of a “special recognition” XYZZY for Zombie Exodus was well-handled.

Overall, the game wasn’t my cup of tea, but it obviously has its fans, and I can see why. There’s plenty of suspense, plenty of gore, and a fair number of stretches that feel compelling and engaging. Once its prose is better edited, its meaningless choices are removed, and its story is, ahem, finished, it’ll be worth the time of horror devotees. Until then, the game is kind of a zombie itself, shuffling forward despite its crucial missing organs.

Order by John Evans [Comp04]

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

At this point, I feel like I could really save myself a lot of time and energy by just writing up a template for reviews of John Evans games. The basic gist of the template would be “This game has some cool ideas and a lot of potential, but it’s not really finished and it seems untested, so it sucks.” Then I could just fill in the blanks with some specifics about the game, and be done. Evans has submitted games to the last five IF competitions, and they’ve all fit this mold, so why shouldn’t I just keep writing the same review over and over again? I kinda have to.

I mean, I guess they’re improving. The first couple (Castle Amnos and Elements) were way too big for the competition, and that problem got corrected. Unfortunately, it got corrected by switching to total unfinishability due to scores of heinous bugs. I gave a rating of 1.0 to Evans’ last couple of games because they were just totally incomplete. Order isn’t as bad as that. It’s the right size for the comp, and it is finishable. But it is still not finished. See, if you’ve got a command called BUGS that lists out the bugs in the game, your game’s not finished. Actually, one of the funnier parts of Order is that even the BUGS list is buggy, as some of the things listed actually do work (though plenty don’t.) Also, if a crucial puzzle in your game rests on a piece of scenery that you don’t mention anywhere, your game’s not finished. A tester would catch that. That’s, y’know, what testers are for. Use them.

Actually, beta-testing seems particularly critical for a game like Order, because the game revolves around coming up with actions quite spontaneously, and the better sample you have of what actions people are going to come up with, the better you’ll be able to implement them. (Here’s where I start filling in the “cool ideas” part of the template.) I love the basic concept of this game — you’re some kind of magical spirit, and you’ve been set a series of tasks by your summoner. So far, still pretty bland, and strongly reminiscent of J.D. Berry’s The Djinni Chronicles. But the nifty twist that Order puts on things is that you have a CREATE verb at your disposal, and you must use it to solve every puzzle.

So, for instance, you find yourself faced with a locked door, and must CREATE a key. Done right, this could be an amazingly powerful device, giving the game a feeling of almost limitless possibility. And indeed, there are times when Order feels like that. Of course, there are way more times that it’s disappointing, and not just because I was trying crazy commands like CREATE PHASER and CREATE WETSUIT. Lots of much more reasonable attempts aren’t implemented, and I can’t help but think that some beta-testing would have greatly improved the game’s range of options. Still, there are multiple solutions to each puzzle available from creating various objects, and that aspect of the game is really fun. Too bad the other parts are such a drag.

Oh, there is one more good part — the hint system. These hints are nicely implemented, InvisiClues style, and it’s a good thing too, because nobody is finishing this game without the hints. As I alluded earlier, there’s a critical puzzle in the game’s midsection that is simply not solvable without hints, because its main components aren’t mentioned anywhere. Remember Bio, from Comp03, the game that starts out with gas seeping into your room and you have to get a gas mask out of an armoire, except the only place that says anything about an armoire is the walkthrough? Pretty tough puzzle, right? Well, Order takes inspiration from it with a puzzle where you must perform an action on an orb encased in a steeple. Problem is, nowhere in any room or object description are the orb and steeple mentioned. There is a dome mentioned, but like many of the scenery objects in room descriptions, it’s not implemented. Actually, even for some of the objects that are implemented, the descriptions aren’t exactly superb:

>i You are carrying a set of white robes (being worn).

>x robes A set of white robes.

Ooo, spellbinding. So okay, I’ve almost got my template ready. The only thing left is to figure out how to wind it up. I’m leaning towards a plea for the future: please help your cool ideas reach their fullest potential by finishing and testing your games! Please! I may have to edit that part out though, as its refusal becomes more and more certain.

Rating: 4.9

Domicile by John Evans [Comp03]

IFDB page: Domicile
Final placement: 18th place (of 30) in the 2003 Interactive Fiction Competition

For last year’s comp, John Evans submitted a game called Hell: A Comedy of Errors. That game started out very cool and interesting, but after playing for about an hour, it became quite apparent to me that the coding wasn’t finished. Well, some things don’t change. I mean, the ABOUT listing for this game includes the admonition, “for known bugs, type BUGS.” Known bugs? Listen, if you know there are bugs, especially basic ones like those in this list (“hints not done yet”), that means your game isn’t ready for release. So, hey: DON’T RELEASE IT!

Like Evans’ previous game, this game has some pretty cool stuff in it — there’s an interesting magic system, some good puzzles, a nice sense of expanding possibilities. The problem is, it’s not finished. I played for a while, found some of the cool stuff, and solved a few puzzles. I also found a ton of bugs (not on the “known bugs” list), which forced me into checking the hints a lot from early on — there were a number of synonym problems, some sloppy coding, some Vile Zero Errors. Then got I totally derailed by a game-killing bug (again, not on the “known bugs” list) that spat out a Zero Error and trapped me in a dead-end. So, back to the hints. I restored, tried another method, ran smack into another game-killing bug (that’s right, not on the list) that refused to acknowledge when a puzzle had been completed. So then I said, “Okay, you know what? You get a 1.”

I’m in a bad stretch, here. Three out of the last four games I’ve played have been, in my opinion, not even close to ready. This one is maybe the most aggravating of all, because it seems like the author has this problem repeatedly, so I’m going to do something I rarely do, which is to address him directly. John, your games could be really good. Really. But man, you have got to follow through! You have got to finish what you start. Polish it, test it, get the bugs out, make the code smooth. You know: finish.

Listen, I have a half-finished game on my hard drive too, and I could have slapped an ending on and released it to the comp, but I didn’t, because of this idea I have about comp courtesy. I would prefer to do the right thing by the people I’m asking to spend time on my stuff, so I won’t give it to them until I’ve done all I can to make sure they’ll actually enjoy it. If you get too bored with something to finish it, or the deadline comes before you’re ready, DON’T RELEASE IT. Releasing half-done, bug-ridden games is indefensible, because no matter how much potential they may seem to have, until they’re finished, they’re CRAP.

Instead of starting a new game for next year’s comp, polish and fix this one, so that you can actually have something good to your name. That’s just my advice, which I’m sure doesn’t mean much to you. If it did, you’d have gone back and finished Hell: A Comedy Of Errors. But you won’t be getting much respect as an author until you show that you can actually write a good game instead of a good half-game.

Rating: 1.0

Hell: A Comedy Of Errors by John Evans [Comp02]

IFDB page: Hell: A Comedy Of Errors
Final placement: 23rd place (of 38) in the 2002 Interactive Fiction Competition

So here we have the Fine-Tuned of Comp02. That is to say: Hell starts out with a great premise — you’re a newly-created demon, and your business is to go about torturing souls and extracting the maximum possible penance from them. There are some fun role-playing elements to choosing your form, your wings, your color, and so on. In fact, much of the game’s setup is RPGish in a good way — you can purchase various implements of torture (all rather lighthearted, e.g. “documentary crew” or “lizards with pointy sticks”) and carve out your own personal infernal landscape of punishment rooms. Getting penance from damned souls results in further credits for further purchases, and opens possibilities of further demonic avenues such as helpers and peddlers.

Hell then completely squanders the promise of this great setup by being so very incomplete. The documentation suggests that some souls give up more penance depending on their particular characteristics, but damned if pretty much every soul in the game doesn’t look exactly identical. So, inevitably, you run out of money and then wander around wondering what to do next. I get the sense that in the finished version, each soul will have its own personality, and the puzzle will be to match it up with the environments and tortures that best suit it. In the current version, it’s pretty much a crapshoot.

Of course, there’s always the possibility that I’m wrong about this. Maybe I’m missing some critical clue that would make it clear how to proceed. Given that the game provides neither hints nor walkthrough, it’s impossible to be sure that this isn’t the case. Nevertheless, what seems quite clear is that Hell doesn’t do what it says it will, and consequently I have no choice but to regard it as an unfinished game. Please don’t submit these to the comp.

Rating: 1.0

The Water Bird by Athan Skelley [Comp99]

IFDB page: The Water Bird
Final placement: 29th place (of 37) in the 1999 Interactive Fiction Competition

From the update on the comp web site, I already knew that The Water Bird had a game-killing bug in it, so I wasn’t surprised when I found it. What I was surprised by (though maybe I shouldn’t have been) was the number of other, extremely basic, bugs I found in it. This is unusual for me — usually once I see or hear of one bug in a competition game I expect them to come in droves, but the opening text to The Water Bird is so good that I allowed myself the belief that the critical bug was just a really bad-luck oversight, one of those things that makes you just about swallow your own tongue as an author the second a player finds it and it’s TOO LATE to change a thing. But no, actually, there are bugs throughout the game. In fact, in only the game’s second location, attempts to walk in an unavailable direction are met with “[TADS-1023: invalid type for built-in function]”.

This extremely fundamental omission is emblematic of the unfinished feel that the entire game has. It reminds me of a poster we have up in our bathroom, a print of an unfinished painting from London’s National Gallery. Part of the canvas is an accomplished portrait of a young woman with a dramatic landscape behind her, and the other portion of it is just a brown mass, with rough lines drawn to indicate how the rest of the painting will go. Similarly, Water Bird reveals its edges at unexpected moments. Here’s one room description:

Lodge Roof You are on the roof of the lodge. From here you can see most of the village. ... (good view, etc., smokehole (covered by?))

Now, to be fair, that’s not typical. Most of the descriptions are written, and written well, but there are several occurrences of the “…” symbol, which I’m guessing was the author’s Search-and-Replace code for “Elaborate on this later.” Incidents like this made me feel like I was playing a game that isn’t even ready for beta testing, let alone general release.

I have an opinion on this sort of thing. I’ve expressed this opinion before, and it hasn’t met with general approval. Nor do I expect it to now, although to me it seems like sheerest sense. But I just have to say it: if your competition entry isn’t ready by the deadline, and by “ready” I mean fully proofread, beta-tested and (please) played through at least once to ensure that it’s finishable, DON’T ENTER IT. Don’t even breathe a word of its existence. I adamantly maintain that you gain no appreciable benefit from entering an unfinished game into the IF competition. Instead, it’s detrimental to you in several ways.

First of all, many people who might have been open to playing your game will write it off as buggy and poorly done, and probably never come back to it again. After all, why should they bother with your rough draft when there are so many pieces of really good IF being published each year, and a wealth of older classics in the archive, all available for free? The audience for IF isn’t so large that an author can afford to alienate such a significant portion of it; as the hoary cliche goes, “you never get a second chance to make a first impression.”

Secondly, releasing an unfinished game tarnishes your reputation as an author, since it implies that you really don’t care how good your work is before it’s released, that you don’t take pride in it. But perhaps most heartbreakingly of all, it’s so agonizing for a player to go through a game that has lots of good pieces but is an overall bad game, and bad not because its author can’t write, not because there’s anything wrong with the concept or the programming or anything, but just because it’s NOT FINISHED. It’s like biting into a pancake and finding that inside it’s still just batter. It’s so much more disappointing than going through a game that just plain stinks on ice, because it’s so clear how much unrealized potential is present in the unfinished game.

I’m an author myself, and I understand how much time and energy goes into the writing of an IF game. Why would you want anybody to see that game before you’ve honed it and worked out the kinks? Why waste all that good effort? Instead of entering that game, finish it. Do it right. Then release it in the Spring, or the Summer. Or if you really want to be in the competition, enter it in the next year’s competition where it has a chance of kicking some serious butt over all the unfinished games in that year’s field. Exercise a little patience.

Hmmm, well I seem to have ascended my soapbox and delivered a rant, completely heedless of the fact that I’m supposed to be reviewing The Water Bird. OK, here are some impressions from what I saw of the game. It’s obviously quite well-researched, and makes a very smart move by putting most of the author’s explication of that research into footnotes, so that a player can choose whether or not to be exposed to it. This is a new approach to footnotes in IF, one that is amusingly enough much closer to how footnotes are used in actual books. The game is well-written, with great puzzles and a really interesting subject, and if it were finished I have no doubt it would make a sterling entry into that fledgling canon of folktale IF currently occupied by games like Firebird and Lesson of the Tortoise. Indeed, it’s so good that my disappointment was all the sharper when I realized that I couldn’t actually finish it, because by the time I hit that point I very much wanted to see the rest of what The Water Bird had to offer.

Rating: 4.1