I’m not sure if I design with two-word commands in mind, but when playing even in advanced parsers I understand that two or three words is usually enough so I tend not to use complete sentences or complicated commands like
PICK UP THE JUMPER CABLES AND ATTACH THE RED CLIP TO THE POSITIVE TERMINAL AND THE BLACK CLIP TO THE NEGATIVE TERMINAL
I’ll step through it.
TAKE JUMPER CABLES
Taken.
ATTACH RED CLIP
(to what?)
NEGATIVE TERMINAL
(done)
ATTACH BLACK CLIP TO POSITIVE
(the positive battery terminal - done)
If I design anything that requires a complicated “tie the rope” implementation or an extremely complicated machine I tend to have the parser see if the player has all the stuff and just give the player the benefit of the doubt.
START THE CAR [or] USE BATTERY CHARGER [or] EXAMINE BATTERY
The car has a dead battery - but you now have a battery charger and jumper cables, so it’s short work to connect those up and start the car. The car is now running, for as long as it has gasoline.
Because it had all the other bells and whistles other systems didn’t, remember?
More seriously, though, I really didn’t expect people to care that much, or that they would think it would alter that much the gameplay or the kind of game you can make.
I thought (without anything to back it up) a lot of parser games are in practice two-words (minus some parts implemented in the clunky/unergonomic ways), and to be frank I’m still not entirely convinced of the contrary. It would be great if someone had some real and clear example.
Like, I wouldn’t go as far as saying that “you could release a game with a two word parser today and nobody would notice for months”, because there will always be someone who will try a complex command at one point, but I’d think that with a well-crafted game you could get quite far at a player not noticing.
Now that I think about it, we could easily make parsers that’s between a two-word and a full one.
“1 + N” parser: First word is the action, all the other words are for a single noun, to avoid disambiguation for when you have a lot of similar objects. But could be confusing if player tries an action with multiple objects.
Four-word parser: Same as with two words, but it accepts an optional preposition and second object. (We could extend that to “even-number-word“ parser to allow an arbitrary number of objects! )
I’m thinking as an implementer now, but I feel that two- and four-word parsers are basically trivial to implement, “1 + N” a bit more difficult but still OK, and that the step between them and a full-fledged parser is really really high.
Anyway, thanks for all the answer, it’s really interesting!
Sorry, nothing you listed was in the territory of “no currently available authoring system can do this”, so I didn’t realize I was supposed to be imagining bells and whistles that only this hypothetical system has and was thinking that the hypothetical game author could have done their aesthetically fancy game in, say, Adventuron, or Inform with Vorple, or something, and gotten the ability to handle “tie rope to tree” without splitting it into two commands.
Hey, no need to apologies, I wasn’t totally serious.
And it was more of a thought experiment (what if this system was absolutely better in everything but the parser). In the end you’re absolutely right of course.
Honestly, to me, the solution to tie rope to tree in a two word parser is obviously
rope tree
Or at least, it’s hard to imagine a situation where rope object wouldn’t be interpreted as tying the rope to the object.
And it makes me wonder how far one could go with the idea of most actions consisting of using one object on another and how many puzzles could be built around order dependant two noun commands… e.g. rope knife ties the rope to the knife, but knife rope cuts the rope with the knife.
There were some games like this back in the mainframe era; I think Haunt was the one that had a truly unfair puzzle built around the five-word limitation.
Of course, the better way to do a four-word parser is to use a language with case marking, so you can have verb, direct object (accusative), indirect object (dative), and instrument (ablative), without any bothersome prepositions!
Inform (well, really Preform) has all those pieces in place already, so that should be possible there. Of course it also has a lot of historical cruft that might complicate things, like two different verb constructs… In fact, maybe the best thing to do is to make a new IF environment on top of Preform to replace Inform?
I’ve experimented with parsing this sort of language in Dialog, and it’s doable but tedious; Preform might be better for it. The trick with Dialog is that it generally doesn’t look at units smaller than whole words, so it can’t automatically generate declension tables for you like Preform could.
Either that, or write some IF about the glorious Roman empire!
There’s not only Latin, but also many language with declensions… Germanic ones, for example, or the extreme case of the euskadi (basque) language, with has a whopping 16 cases…
True! But for a true four-word parser, we need a language with an ablative or instrumental case: a case for the tool used in the action (like UNLOCK DOOR WITH KEY). German lost that one, but Finnish and Russian still have it.
Wouldn’t Latin be often ambiguous? If I recall correctly, quite a lot of cases have the same ending.
(I remember an exam where I failed an exercise because my translation was “technically” correct, even if nonsensical. I interpreted it as a different case as intended, because they both had the same ending.)
Anyway, I’m glad this thread sparked so many ideas and thoughtful answers besides solely discussing the virtues and failing of two-word parsers!
This is true! It’s most often the dative (“to…”) and ablative (“with…”) that are ambiguous, though, and using both of those in the same action is very rare in parser IF.
)
