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.