Merk's Review: A Fine Day for Reaping

Merk · October 8, 2007, 3:28pm

The “official” version can be found at my website:
sidneymerk.com/comp07/reaping.shtml

Game #3: A Fine Day for Reaping
By James Webb (writing as “revgiblet”)
Played On: October 4th (2 hours 50 minutes)
Platform: Adrift (Version 4)

Game’s Blurb:
It’s not all fun being the Grim Reaper. It’s your job to usher five awkward souls into the netherworld or the universe stops existing. No pressure. Take control of The Man in Black and find out if even Death can get a credit card…

A Fine Day for Reaping has the witty appeal that was lacking in the entry I played just prior to this. For a game about Death, it feels much warmer and more alive – and that’s a good thing. The Grim Reaper is well done (and what is it that’s so comical about a well-written lisp? I imagined him as sounding like a cross between a cheesy Mike Tyson impersonation and Sylvester the cartoon cat). At a glance in the Reaper Man novel, I think revgiblet is right. His Death is different than Terry Pratchett’s, seeming a bit like William Sadler in Bill & Ted’s Bogus Journey. Anyway, I was pleased at how nicely the author crafted a PC with real character.

This is a puzzle-fest of the sort I like best. Each objective has two or three alternate solutions (and it’s evident that there are alternate solutions just in the way things are constructed, which is nice). Some solutions cross paths, making it likely that a player will find clues to solving an object in the course of solving a different one entirely. I like this quite a bit, although the easiest of the solutions are probably the ones most players will find. This can leave the others to feel a bit like red herrings, unless you’ve connected the proverbial dots to realize certain things are no longer relevant. I managed to complete the game without peeking at the walkthrough, although not within the two-hour IFComp time limit.

And so, it was necessary that I decide on a score from a partial playthrough. My official vote is “X”, which thankfully lines up with my review score. I’m finding that I really dislike the two-hour rule, though. There is such a big risk in getting it wrong, but it would be unfair to the review to stop entirely just to avoid deciding on a vote, or to rush through and not get a feel for how the game should play out. I’m a little bothered by reviews based on a few minutes of play that have been extrapolated to the game in its entirety. Those reviewers may just be more astute than I, but I find it difficult to write authoritatively about a game when I haven’t explored more of it. Getting to the end can make a difference.

It makes a difference in A Fine Day for Reaping. Even though the writing suffers from minor problems (the usual suspects like misplaced or missing commas and typos in general, but also an intentional but slightly jarring switch in tense during cut-scenes) it’s by and large quite nice in this game. The author has a style (maybe a bit metaphor-heavy) – whether original or borrowed, I can’t say – that really makes for fun reading. That’s probably why I was more bothered that I had trouble pausing multi-page text dumps (a setting in Adrift that, for whatever reason, didn’t want to stay) than I was that the game has so many lengthy non-interactive bits. None of it was dry. None of it felt unnecessary.

That’s also why I was so pleased with how revgiblet handled the ending. It’s a lot to read, but it makes the payoff for almost three hours of play much better than the “congrats - you won” kind of ending I had expected. Different solutions lead to different wrap-ups at the end (according to the walkthrough – although I have not played through again to see those endings, they’re bound to be equally worthwhile).

As much as I enjoyed what revgiblet has done here, a number of problems hold it back from being the truly great game it might have been. Almost all of them are implementation problems. The design itself is fine, with predominantly logical puzzles (or at least illogical ones that make sense in context) and pretty good pacing where it’s hard to get stuck for long.

The exception, as far as the design is concerned, is the twelve-hour in-game time limit. I never felt that it really added anything to the game. I’m not sure how many turns this works out to be, but it’s plenty. For a game on a time limit, it’s probably too long. To be fair, players will realize this from the beginning, and probably plan their saves (and multiple saves) accordingly. The problem for me was that the game didn’t need a sense of urgency. The time limit was made long enough so that exploration and sight-seeing doesn’t have to be cut down too much, but if you’re not forcing a sense of urgency, then why have a time limit at all? In my play-through, I ran out of turns close to the end of my last objective. It’s a nice little non-winning ending, but it just didn’t add anything to the experience.

Other problems are strictly bugs in the implementation. For example:

Jimiyu Wangai’s empty body is lying on the ground.
>x table

You look at the table.
“Don’t worry,” says Jimiyu, “It’s perfectly sturdy.”

Now, Death can talk to the dead, but in this case, poor Jimiyu had been reaped and departed. The “x table” reply had to have been hard-coded on the assumption that players would only be looking at the table while Jimiyu was still alive. I found this kind of thing in some other places as well, where static descriptions (for instance, not being able to approach one NPC’s bed due to a protective spell, even though the spell was already gone) didn’t take into consideration the changes in the state of the story.

“In” and “out”, as standard commands in IF, didn’t work in places where they might have been appropriate. Some of the more specific actions were a little guess-the-verb-y (I had trouble figuring out how to take something from the “lucky dip” without finally resorting to “use dip”, for instance). There is no special way of entering a year into the machine (you just type the number as though it was a stand-alone verb, but it only responds with something other than an unrecognized command message if you enter a year that the game knows), which does make it a little confusing. These kinds of small frustrations happen frequently in A Fine Day for Reaping, but it probably just needs more testing and polishing.

Then, there is a strange screen-clearing problem at work. I’m not entirely convinced Adrift is to fault for this, since it appears that room descriptions that shouldn’t even be printed yet are shown just prior to the clearing of the display (and there is no forced pause, even with Adrift pausing turned on). This may be a bug isolated to this game. It seems I’ve been able to pause before forced screen-clears in Adrift games before.

The “help” built into A Fine Day for Reaping works more like 2005’s Beyond than most other IF games. You’re whisked away to a whole new location, which is a good thing for any player to try as part of the overall experience. Once there, you don’t actually have to get hints (I found it a little under-developed, anyway, where some of what I wanted help with didn’t quite lead to answers).

The “X” I scored it at two hours fits with the game as a whole, thankfully. It does have problems, but it’s an imaginative and fun story, and a worthwhile, recommendable game. I’ve tacked on a “minus” because of the frustrations with pausing and screen-clearing, but the score itself is unchanged.

Merk · October 30, 2007, 5:20pm

In light of comments I’ve seen elsewhere and thinking about the game in retrospect, I was probably a little too hard on it for the problems in Adrift. I can’t change my vote (I played past two hours), but I considered changing the review score. I think I won’t, because I’m reminded of some real Adrift-induced frustrations (I’ve left it all out of the review), but still, this is a very well-done game in many ways.

No specific point in bumping this, really. I was just revisiting some prior reviews, and checking around out there for new reviews of the games I played early on.

David_Whyld2 · October 30, 2007, 6:56pm

Which release of Adrift did you use?

Merk · October 30, 2007, 7:21pm

The latest, I think. Version 4.0, Release 50.

Here were my specific complaints (in their chopped-out form). I don’t mean this to stir up drama (which is why I chopped it – well, that, and it belongs more in a discussion on Adrift than in a review about a specific Adrift game), but it did lead to some frustration and probably a score that’s a point or two lower than what the game would have deserved otherwise.

I have to get this out of the way before I begin. I don’t have a natural aversion to Adrift. Others may. I don’t.

Regardless of the cause, if problems do exist in a game it can detract from the experience and enjoyment of that game. That’s true, no matter what the development platform may be. When I talk about the problems in Adrift (and I do so at length, later in this review), it’s not for a loathing of the Adrift platform. It’s because games written in Adrift would generally be better if written in something else (it’s the same complaint I’m likely to make of home-brewed games, including my own now). What I mean is, problems that typically crop up in Adrift games, usually as a result of how it seems to handle the scope of objects and differences in parsing, are just not inherent to other systems.

More on that a little later.

… (the bulk of the review is here) …

And speaking of Adrift…

There is a tendency in the Adrift community, from what I’ve observed, to feel threatened by criticism of the Adrift platform. Maybe it’s natural – I was peeved last year by a reviewer’s flippant comment about Hugo (where the comment seemed to ignore that games written in Hugo work just like those in Inform and TADS) – but it really is different in Adrift. Adrift doesn’t work the same way.

Differences can be a good thing. Adrift’s built-in mapping is nice. The Windows interpreter is easy to use, customizable and simple. Differences exist in the nuts and bolts of how Adrift works, though, that makes me doubt an Adrift game can work like a game written for a different platform. These differences can be maddening, and in some ways they cripple the playability of games written in Adrift.

Try this in A Fine Day For Reaping:
>say time machine to horse

The response is:
The time is 9:55:22 AM

That just shouldn’t happen! It’s not what I asked for. Ultimately it doesn’t matter, but it tells me that Adrift is guessing at my intentions rather than actually figuring out what I meant. The right response would be “Horse can’t take you there directly” or even “please use location names when talking to Horse, rather than specific objects.”

Try something like this in most any Adrift game:
>dig for a cut rope

The response is typically:
You can’t cut that.

Adrift works on the premise that players will only ever enter simple commands, and that it’s safe to throw away parts of the command that aren’t understood. This allows Adrift to understand “gee I really want to cut the rope” as a command in an almost miraculous way, but all it really understands (and retains from the entire command) is “cut” and “the rope”. This is a fundamental difference in how Adrift works, that makes things like actively commenting a transcript during a game a downright aggravating experience. Instead of “comment recorded” or even “I didn’t understand that command,” you’re likely to get one or more actual results where Adrift puts your comment into action as best it can.

I’ve been told that Adrift grammar is based on wildcards. Is the problem just that these wildcards are overused? I do intend to dig into Adrift development one of these days, even if only to find out if it’s possible to write grammar rules that parse in a more traditional way.

One player’s problem, though, is another player’s “feature”. I don’t think Adrift authors are bothered by these things much, if at all.

… (conclusion to the review, beginning with the help system, here) …

I don’t mention it there, but I’ve seen odd disambiguation and scoping issues in Adrift games as well. When I’ve seen them, it makes me thing that Adrift works on a different kind of world model than other IF development languages. I’m used to container/contained kind of relationship for the entire game world, where the room contains the player and other objects, the player contains a box, the box contains a sock, and so forth. Scope works on what’s reachable and previously encountered. I’ve seen evidence to the contrary in Adrift games, but this could just be poor coding, not a failing in Adrift’s world modelling. You guys would know better than I, though.

I think some Adrift authors – not lumping everyone together here – tend to dismiss complaints about Adrift without really taking a moment to focus on why people are complaining. I guess that’s what I’m getting at. If there are ways to write Adrift parsing and object scoping in a more traditional way, I think it’s worth looking into for Adrift authors. To me, the “right way” isn’t a standard or a convention by accident. It’s because that’s how it all needs to work to avoid misleading and confusing players.

Just stuff to think about. I’m rambling.

ralphmerridew · October 30, 2007, 8:05pm

From what I know about ADRIFT:

A game will first attempt to process a command against a list of author-provided tasks. If none of those match, it will process the command against system tasks.
Each author-provided task will have one or more command lines. A command line is similar to a regular expression. Examples might be “take *”, “put %object% in *”.
To handle a system task, ADRIFT will go through its list of verbs and search for each one in turn with INSTR. I don’t know the exact order; it might check first for “drop”, then “take”, and so on. (So a command like “take the lemon drop” will be interpreted as a “drop” action.) jAsea and (at least last time I checked) SCARE instead parse system tasks the same way they parse author tasks.

Merk · October 30, 2007, 8:08pm

Hmm. If that’s true, then it seems like the only way to prevent parsing issues – or minimize them, at least – is to never use object names that conflict with verb names. Even if you create parsing rules without an abundance of wildcards, you’d still get tripped up on the “lemon drop” issue (for instance)…

emshort1 · October 31, 2007, 3:04am

My particular gripe with this game (which I think is also an ADRIFT complaint, as I ran into it with another ADRIFT game) is that it pretends to understand things it doesn’t, and pretends to let you do things that are actually not actions. For instance, if you type

PRESS THE FOOBLE

and the parser doesn’t know what fooble is, it will respond,

You press, but nothing happens.

This is awful! It makes the player think she’s done something and it turned out to be useless, so she moves on and tries other approaches – rather than what she should actually do, which is to figure out another name for the object she wants to press. It is in my opinion dreadful design to give a response that suggests the player did something, when in fact the parser didn’t even understand the command. I remember gnashing my teeth over every piece of this game that had to do with any kind of button or machine. (Don’t even get me started on the elevator.)

Kell-Teng · January 19, 2008, 10:51pm

Yeah I noticed some of those same issues too. Have to agree though, fun, fun game.

And I can’t help but cackle maniacally about the ways to win against the woman in Paris.