intfiction.org

When I've played ADRIFT games in the past, my chief complaint has been the parser. It seems to pick keywords from inside a command line, and act on those. From observation, it seems like the grammar rules must go something like "If [command] contains [cut] and [command] contains [paper] then perform [action]" -- something like that.

This can easily lead to the misinterpretation of what the player really intended. Ordinarily, it's no problem at all. Commands are generally simple enough that they're unlikely to be ambiguous. But, when you're trying to put comments in a transcript, it really goes wonky. ADRIFT starts acting on multiple commands within the comment line.

I don't mean this as a slam to ADRIFT -- I ask, because I'm curious if anybody can explain to me exactly *how* ADRIFT's parsing works? How does it go about figuring out what the player intended? Is it really just looking for keywords? Would typing "make paper cut on finger" be interpreted as "cut paper" ?

---- Mike.

Well, I use Adrift, and have done for years, but I've always steered well clear of discussions regarding the parsers. I'm more interested in what Adrift can do than the nitty-gritty of its makeup.



Not as far as I know. Commands in Adrift are entered in the task panel in the Generator, pretty much as they appear in the game. So you could have two different tasks "make paper cut on finger" and "cut paper" and it would interpret them as two entirely different commands. As far as I know anyway.

Wildcards can be used to get rid of the necessity for words like "the", "a", "an" and the like, so you could have a task "make * paper cut on * finger" which would be interpreted as "make paper cut on finger" or "make a paper cut on the finger" or, indeed, as "make a really big paper cut on my little finger".

I've always found that the more I know about how Hugo works (down to the nuts and bolts of its libraries and parsing -- I still have a lot more to learn), the better I'm able to construct the game itself. I've been thinking about writing something in Adrift, just to see what it's like (one of these days, I mean -- not right now). Because I've seen Adrift games misinterpret what I meant (carrying out the wrong action by mistake), I've wondered just how its parsing works.

When you're setting up those rules, are you setting them up for each object, and for each variation of how an object may be referenced? In other words, If you want to support "jump" as a general verb, do you code a "jump" rule giving the nouns that are recognized for that object? In the paper cut example, would an alternate "cut * finger with paper" be a different rule from "cut * finger using paper", or would it just be written as "cut * finger * paper"? What about cutting other things with the paper? Would there be a similar rule set up for other things? Is this done globally, or as an aspect of the "paper" object? Would "finger" be a real object in the game, or just a keyword?

It probably sounds like I'm a rank newbie -- it's just that it sounds like Adrift games are designed in a way that's far different from what I'm used to.

"Jump" is supported by default in Adrift, but as it produces a silly message that has never fit in a single game I've written with it (something like “wheee-boing!”), I've always override it. Generally I'll just do a "jump*" task which will cover every command the player types which starts with "jump" - usually something like "You jump up and down for a bit”. Or if you wanted a more specific one, “jump %theobject%” could produce “You’ve no need to go jumping over %theobject%”.



You don't have rules in Adrift. At least not of the kind I think you're getting it. Every command is either built into the system (i.e. directional commands, things like get, drop, inventory, look, etc) or created via a custom task or, sometimes, interaction with an object. There are generally several different ways of doing most things. If, say, you wanted a door, you could either create an object and give it locked or unlocked properties (or custom properties if you like), or create a task and use that to determine whether the door is locked or unlocked. It's all down to choice over which you use, although most times tasks give you move control over what you want to do.



Personally I'd word it as "cut *finger* *paper*" (with "cut *paper* *finger* on the next line), but some people would have it as "cut {your/a/the/an/my} {small/left/right} finger {with/using/on} {the} paper", which is essentially the same command but a lot longer and more trouble. The first way allows for the player to type pretty much anything that includes the words “cut” and “finger” and “paper” in that order (or “cut” and “paper” and “finger”), whereas the second needs more precise wording. I always go with the first way as while it allows someone to type “cut lots of things with the finger but most of all the paper”, it’s easier to use and covers the bases far better than the other way.



You could have "cut %theobject% *paper*" with a restriction that the referenced object must be visible to the player, and then either say "You can't cut %theobject%" or maybe "You cut %theobject%. It is destroyed." and then move the referenced object to room hidden (i.e. effectively remove it from the game).

Any worthwhile threads on the ADRIFT forums we could browse for those? The discussion got my interest piqued as well.

Thanks!

I don't recall any specific threads overall, but parser discussion pops up there quite a few times. Searching for "parser" brings up a list of several dozens threads.

I know Adrift's parser has received a lot of criticism in the past, generally from people don't use Adrift that often, but it's never seemed like such a big deal to me personally. Maybe it's because I grew up using the two word parsers that games back in the 80's had - when YOU CAN'T DO THAT was considered a perfectly reasonable response - or just that I've never considered the parser to be [i]that[/i] important. Okay, yes, it [i]is[/i] important, but a game can have a decidedly average parser and still be a great game, and a bad game isn't necessarily any better because it has a brilliant parser.

Hey, Rioshin! Where are you? Is there a new phpBB beta that fixes the italics ubb code bug, by chance?

What happens in Hugo -- and I *think* in Tads and Inform as well -- is that a minimal number of words are discarded. "a", "an", and "the" are always optional, and maybe a few others. But everything else *has* to match a grammar rule, else it's not a valid command. In a review of my first IFComp game (Lunatix), back in 1999, Paul Obrian said:



Essentially, the grammar in Lunatix was such that it looked for a command to start with a certain word, and contain other keywords -- sort of like how Adrift grammar would be if you did wildcards like described -- essentially something like INSERT * CARD * SLOT. If the player types "Insert greeting card under mail slot" and the game assumes "Insert key card into door slot" because that's the thing you anticipated, then it may really confuse a player.

What's encouraging, though, is that you describe Adrift grammar rules in a way that makes me think an Adrift game *could* do a good job of mimicing the type of parsing done with other platforms. The trick would be to go very sparingly on the wildcard tags, and define specific grammar rules as needed. I'd really like to experiment with this some day, even if only to get a better feel for it.

I guess if you were to construct every task in the game along the lines of

"cut {your/a/the/an/my} {small/left/right} finger {with/using/on} {the} paper"

you'd get the parser working exactly the way you want it to, but I'd shudder at the very idea of writing a game with 1,000+ tasks along the lines of the one above. Something like

"cut *finger* *paper*"

I can type in my sleep but

"cut {your/a/the/an/my} {small/left/right} finger {with/using/on} {the} paper"

I'd probably need to check over several times to make sure I wasn't missing something out.

Hopefully when Adrift 5 comes out (sooner rather than later), the parser problems will be fixed.

It doesn't sound like the parser is "broken" per se. It just works in a much different way than other systems. Any idea when it's coming out, and what features are being added or changed?

I see where you're coming from now, with all the extra definitions you'd have to create. In Hugo (probably others too -- I wish I could speak from experience there), the grammar definition just uses placeholders for the objects. The objects then carry their own nouns and adjectives. You'd never have to write different versions of the "cut" verb (for instance) to accomdate different objects, as long as the grammar def is something like "[cut] object "with"/"using" held" and you have the proper nouns and adjectives associated with a screen door (object) and a knife (held). The parser handles checking all in-scope objects to figure out which one you're talking about. It looks at the command line, tests to see if the words meet noun and adjectives for objects in scope, and goes from there. If later, you want to tell the player that the knife is sharp, you only need to add "sharp" as an addtional adjective for the knife, so that any references to a "sharp knife" will work.

I really like Adrift's auto-mapping. Doesn't it have multimedia features, too? Have there been any Adrift graphic adventures?

From what I know of ADRIFT 5 there are two changes that will be important for the parser.

First is that rather than things being hardwired into the runner much of the game logic will be in a standard library that can be changed.

Second is that tasks will change so that you can create a general task for a command and then from it create a specific task for a specific exception. You might make a general "bounce %object% task and then create specific tasks for where the task was a ball, and another for where the object was breakable.

For more ainformation on what Campbell Wild is planning you should look HERE.