Merk's Review: A Fine Day for Reaping

The “official” version can be found at my website:

1 Like

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.

Which release of Adrift did you use?

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 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.

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.

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)…

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


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.)

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. :smiley: