In general, I feel like complaints about a game’s parser should be addressed to the creator of the platform (or its default library), not the game. Criticizing ADRIFT’s parser seems a bit like complaining about the grain in an 8-mm film: it’s probably less interesting than what the thing’s actually about.
This isn’t to say that the parser’s not an integral part of the experience of playing IF, just that it’s not one most authors are in a position to improve.
(It’s also not to say that the choice of the right tool isn’t part of the author’s job. Perhaps ADRIFT authors need to communicate more clearly to players what sorts of commands the ADRIFT parser is likely to understand, so players aren’t going into what they think is 3D IMAX and getting 8mm instead.)
This is the thing, though, for me: the ADRIFT parser is bad in ways that produce results I don’t anticipate, and which actively throw me off when I’m playing. It routinely doesn’t recognize sensible subsets of an item’s name, for instance, so if I can’t interact with an object, I have to try just noun, noun + adjective, etc. And that behavior is not consistent from one verb to the next, so if I’ve figured out what to call the object in one context, I have to figure it out anew in another. For that matter, the parser feedback is so vague that I can’t always tell whether the problem is that the action is unrecognized, the noun is unrecognized, or the whole thing is recognized but has no interesting results defined. This has bitten me over and over again.
So the result is, parser problems in ADRIFT actively interfere in my enjoyment of a game in ways that are difficult for me to work around. There are limitations in other systems too, but they are, I feel, usually more predictable with experience, which makes me more willing to put up with them. (This is not to say that I won’t still criticize an Inform or TADS game for failing to override some default behavior of the system when that behavior is a bad fit for the particular game.)
Once you put on top of that the fact that I usually have to play these games on an unofficial emulator and that any bugs I encounter might or might not be the emulator’s fault, and it becomes pretty frustrating.
I’m sure this is annoying to ADRIFT authors to hear these complaints again and again, but it’s also annoying to me as a player to experience again and again. In answer to the question, “can’t you just ignore the system and critique what’s unique about the game?”, though, the answer is no, I can’t. I’ve tried in several previous comps to set this issue aside, but the system routinely screws up my experience of the game such that I can’t tell whether my problems are down to the parser, the interpreter, or the author’s own additions. If it’s not useful to ADRIFT authors to hear the whole of my experience (including the crash that I don’t know the origin of, and the puzzle that drove me crazy because it recognized PUSH BUTTON but not PUSH WHITE BUTTON or PRESS BUTTON or PRESS WHITE BUTTON), then I don’t have useful criticism to offer them. And in contexts where I’m writing reviews for people outside the core community, I’m not going to give a glowing review to a game that I think is fundamentally broken.
So, bottom line: it’s the author’s choice to use ADRIFT, but by selecting this system, he is signaling to me that he isn’t trying to produce the kind of game I’m interested in playing. These days it takes a strong positive review from a third party (incidentally, one that does mention that the parser is above-average) to counteract that signal and make me want to play. Sorry about that, but at least I’m no longer writing reviews that ADRIFT authors find infuriating, I hope.
As far as the ADRIFT parser’s limitations being insurmountable, the authors in the discussion here: [url]https://intfiction.org/t/how-does-adrifts-parsing-work/56/1] seem to indicate that it would be possible to configure parsing tasks to work in a way that conformed more to the Inform/TADS approach, although it could be a significant amount of work.
Whether individual ADRIFT authors are willing to do this, and whether they think it’s worthwhile making such an effort to gain more traction in the wider IF community, is another question. Maybe when ADRIFT 5 comes out with its improvements it will improve the cost/benefit ratio on such efforts.
I have to disagree with Finn on this one. I don’t think people have played enough ADRIFT games to understand how its parser works, and I don’t think they could get to understand it that way, either, because 1) there’s no standard for writing tasks in ADRIFT-- different authors prefer different methods-- and 2) about a quarter of ADRIFT games are produced by authors who write one game and run, without learning the ins-and-outs of the system. So, players might learn some of the default error messages (“You push, but nothing happens” being a repeat offender), but that’s not always helpful enough to guide a player toward a correct command. What’s more, new authors might write things in ways that make it unnecessarily difficult to get the right command, as Emily pointed out.
I can think of a recent game, Ba’Roo!, by an author still relatively new (his second game). It has a situation very similar to Emily’s example. The player looks at some lights and sees a set of “push buttons”. >PUSH BUTTONS doesn’t work, so one might then want to >X BUTTONS. Then you get these coloured buttons. So you might, say, >PUSH YELLOW BUTTON-- “You push, but nothing happens.” To even an experienced ADRIFT player, this would mean push probably wasn’t implemented, but it doesn’t say what will work. Plus, if you then type >PRESS YELLOW BUTTON, you get a different message-- “Nothing happens.” So does it work? How? These are avoidable errors, but authors don’t always go out of their way to accommodate them.
Then you get games like Escape from Camelot which have all of 21 tasks implemented, each with excruciatingly exact and non-obvious syntax… five of which kill the player. Sadly, it’s pretty easy to see why people have little confidence in ADRIFT. Hopefully that can change, but we’ll see. It’ll certainly take some work.
…and all this ignores the fact that Inform & Tads’s parsers aren’t good enough, either. People new to IF consistently trip over it. So for IFers to criticize Adrift’s parser really says something. Assuming Adrift has a parser. Just going by Emily’s description of issues, it doesn’t sound like it has one. It sounds like every single recognized input is a special case written by the individual author.
As a programmer, I feel that the Adrift authoring tool is a bad piece of software with a good community. Conrad’s versioning problem with his Lair Of Cybercow springs to mind. That wasn’t Conrad’s fault, if I understand things correctly. The Adrift interpreter software can’t even tell if it’s capable of running a particular Adrift game? Wow.
Perhaps Adrift should target CYOA? CYOAs written in Adrift seem to do well. I don’t know. Something needs to improve. If the software improves, then I feel a lot of other problems will vanish on their own.
TADS and Inform parsers have problems (which we love to discuss) but they share some deep assumptions that make them intelligible to IF regulars. Basically, a deep dedication to breaking down player input into an abstract action and a list of abstract objects.
That is, they separate the tasks of parsing action phrasing, parsing object names, and reacting to the parsed command. More importantly, they ensure that the game author keeps those tasks separate.
That’s why “push button” and “press the button” work the same, in nearly all TADS/Inform games, whether the game author is experienced or a beginner. That’s what we-as-players accept and rely on. When that assumption breaks, the game experience goes to hell.
(I am a little worried about this assumption in I7, actually. With the advent of regexps, I’m seeing code questions – and answers – that rely on (e.g.) matching “get all” as a substring. This could be poisonous in the long term. Remember that because we’re used to the “standard” parser, we don’t always test these variations… A game in which “the” is illegal in half its commands wouldn’t cause me any trouble, because I never type “the”. But it would cause unwarranted trouble for some unknown number of newcomers, and we might never know it.)
It’s OK. We’ve one foot in the fiction world. We like to read.
I’m pretty sure RAIF is entering its twilight. I check it regularly still, but things with RSS feeds like here, Planet IF, IFDB, and Club Floyd are easier to attend to.
Wouldn’t it be easier for an author to go straight to the other platform to begin with?
Rhetorical question.
This is reasonable, but then you say…
…which seems to blame Drifters for the tool’s failure. I mean, if just one or two Drifters were consistently bashed in the IFcomp, your statement holds weight. But when they all are, well, the only common thread there is the tool. There is nothing wrong with Adrift authors. The worst one could say about them collectively is that they don’t kick Campbell Wild in the knees for such a crappy parser. Most likely, this is because they don’t have a clear idea what a parser is or why it’s bad. They use a graphical tool so parser issues are someone else’s job.
This isn’t just rhetoric on my part. From the Adrift Manual:
This part comes after the explanation of how to add synonyms and adjectives to the apple object, including adjectives like “an”. All of them were just thrown away by this example, and green was added regardless whether it was there earlier or not. “From” is hard-coded; there is no “off of”. Is it so hard for Campbell to add a syntax for the apple object? Is it so hard for Campbell to create a verb as an object so its synonyms need only be listed once? Is
!take !apple [from/off of] !box
so unimportant to him that his users are afraid to enter popular events?
And Campbell charges money for that? Really? Really?!
Don’t need Campbell for a group blog. The Adrift community should just create a Wordpress blog, attach to Planet IF, and post there semi-regularly. Even if there are only twelve Drifters in the community, each person only needs to post there once a year to create mindshare in the IF community once a month. Posts to their personal blogs can be copied & posted there as well, including “backissues” if relevant.
We don’t all use PDF files cause Adobe Reader costs money and isn’t integrated into web browsers.
Looks like I’m a few quotes behind here. Oh, dear. Allow me to briefly catch up.
Mostly display issues. For example, in the ADRIFT version, if you push the cannon around it displays the next room description, but the room description doesn’t have the cannon in it. So it has to manually print “The cannon is here, too,” at the end of the room description. In Gargoyle, that would be redundant because the cannon would already appear in the room description. Also, whereas ADRIFT reports “You take X,” Gargoyle reports “You pick up X.” As far as I can tell, it’s just things like that. They’re basically all easy to fix using ADRIFT’s ALR (text replacement), but a couple require remodeling tasks a bit-- not so much it creates a lot of work for an author, unless their game is really big, but enough to justify making two versions IMO.
Pardon me for not addressing this earlier. I checked it out and, personally, would blame the author for that one. It appears the task is flagged as repeatable, when obviously it should not be. I shall inform Tiberius… I know he is already planning a post-comp release. I’m sure he’ll be grateful for the help.
I think this is true for IF in general, what with the outreach goal and all, and so it goes without saying that includes ADRIFT. Indeed.
Believe me, it’s not my intention to bash on 'DRIFTers, especially seeing as I am one. But I meant only to refer to their writing as regards the craft of writing: making sweet narratives with grammatical polish and all. I suppose it’s impossible, in retrospect, to divorce that from game design when the medium is IF, though. Still, more expansive criticism helps people improve their art and I stand by this point.
All the bracketing and stuff (I believe the manual refers to it as “advanced construction” or some such) tends to create tasks that are too specific. Personally, I prefer to use wildcards for things like “* get * apple *” (though getting is already understood without tasks, so maybe it’s a bad example… if I wanted to do something with an apple being held, I’d create an event-task combo to check if the apple is held; I’ve released a module that 'DRIFTers can import to do things like this even if they don’t already know how). I realise being wildcard-heavy can lead to an overly keywordy sort of play, but 1) I think players would prefer to accidentally do something right than fail to hit on a syntax-too-specific, especially after trying several that “should have worked,” and 2) I have a friend who cusses at the parser with every other word he types, without fail. So I just imagine those asterisks being my censors… this livens up my design process a bit.
Prompted by this thread, Campbell has made an RSS feed for the ADRIFT Adventures page, which is where new games and reviews are posted on the main site. I don’t know if he has them hooked up with Planet-IF, yet.
I have my own blog, too, but I don’t think it’s quite in the shape where anyone would be interested in reading it, at the moment. Maybe I’ll try to give it some TLC and get it associated with Planet-IF soon. I just need to move across the country, first.
I’m torn on this. On the one hand, the author has enough to be responsible for without the parser. On the other hand, expecting the player to know the ins and outs of an engine well enough to decide what’s engine specific is kind of dicey. I have issues with Neverwinter Nights 2’s engine, and they’re the same issues in every game that uses it, and they may not precisely be the fault of the game designers/programmers, but that doesn’t precisely make the play experience easier.
I’m a relatively new player/writer, so perhaps I’m just not used to the limitations of the Adrift parser yet, but I’m not sure the player needs to apportion blame and/or praise properly. Clearly it’s unfair to expect something completely unusual in the genre, like a full OST and a facebook tie-in. But it feels weird to be told that the fundamental interface shouldn’t be critiqued, especially when it’s stopped the game in its tracks.
On the other other hand, I don’t want to write off an entire group of games along semi-arbitrary lines. What to do?
More on-topic, I think we have to review the games we’re given to play. I’m also relatively new, but if something about a game interferes with my enjoyment I think it’s only fair to mark it down for that. At least, the review can serve as a warning for other players who might not know what to expect. Also, it seems to me that some of the parser problems may be surmountable – at least, in Yon Astounding Castle! I’m not encountering any terrible parser problem that I can think of – and letting players know when there’s a problem can encourage them to fix it.
That said, IF players all have to make allowances for the parser one way or another, and if you’ve played enough ADRIFT games maybe you can learn your way around the holes in the parser. But I don’t think ADRIFT authors can expect everyone else to accept flaws in their parser, when there are other games out there that don’t have such flaws. To pick an analogy from point-and-click games, there are probably some engines in which the cursor doesn’t change on a hotspot and some where it does, but I think it’s legitimate to complain about pixel-hunting in the former games, because whether it’s the engine or the author that makes you do it it’s still f’in annoying.
As mentioned in another thread (and indeed this one), I have created an RSS feed for the ADRIFT reviews. I’ve requested that these are added to Planet IF, altho I don’t know how it normally take Christopher to respond.
Once I have made more progress with ADRIFT 5, it is my intention to look into creating multi-platform support for Runner. My plan is to make use of the Mono project for this.
I haven’t started spreading the word properly, as ADRIFT 5 is still in closed alpha testing. I anticipate that it will move into an open Beta within the next couple of releases, at which point I will make information more widely available.
Acronyms are supposed to be capitalised. I personally get tired of people dropping the capitalisation when it is supposed to be there. [emote]:)[/emote]
There is quite a lot of talk of the ADRIFT parser in this thread. I recognised that it was fundamentally flawed back in 2005 when I first started development of ADRIFT 5 (has it really been that long?!). I am confident that most of the issues you have with the parser will be resolved with the new version.
This is quite a similar approach to how tasks work with ADRIFT 5.
It’s a proprietary format I believe. Ron may also talk about crating one’s own PDFs, the utility of which is reduced if you don’t buy fairly expensive Adobe software.
As for readers, a decent in-browser alternative (and substantially faster) is KPDF.
Oh, I see how that parses now: “The reason we all use PDFs is not because Reader isn’t free and isn’t integrated with browsers.” I was attaching the negation to “use” rather than “because.”