One of the things that’s soured me on interactive fiction recently is that the problem of the parser seems to be insurmountable. There are two common solutions or workarounds:
Adhere to Zork-style conventions about verbs (e.g., SEARCH versus EXAMINE, commands like DIAGNOSE or INVENTORY) to limit the scope of what needs to be parsed, and have the player accept that not every object in the game will be implemented and available;
Give up entirely, abandon any idea of simulation of freedom, and give the player a small list of actions to choose among at various points in the game.
There are variations of these ideas (e.g., parser games with a very limited verb set, various interfaces that provide a GUI wrapper around a text inference), and it’s possible to have complicated state even with the latter choice. The impression I get from various authors (plus the whole design metaphor of Inform 7 that writing an interactive fiction game is like writing a novel) is that the holy grail of IF is to create an interactive narrative that completely removes all friction between the player and whatever interface the game provides. I don’t think that’s the right, or at least the only right, goal to have, but I also don’t think it’s something that will happen over the next two or three decades.
Removing all friction between player and interface is impossible. However, the more unnecessary friction exists, the fewer people will play it. For some games, this presents a serious tension, because making them that sort of “more accessible” may well make them lesser games. To be a (semi-)hidden gem or a clearly-visible game that doesn’t fully realise its potential?
I think this problem is the easier to handle of the two. Author-side: implement more stuff! Of course, the development cost is high. I can tell you about it, as I like to implement above average amounts, and I have a feeling my WIP is implementing a higher average amount of stuff than, maybe, any game I’ve seen. This is what I like as my ideal. Handily for others, I don’t subject everyone else to it when I’m playing or reviewing. But in the end, the amount of implementation will always come down to authors. And probably the average level is in the ‘IF contract’ area: most people won’t implement a ton, and most players forgive them for it because we know that to implement Absolutely Everything would be impossible, and beyond a certain point, not add that much to the game.
I find I’m struggling with this area more these days. Personally I’ve never been too interested in limited verb set games. I like that thing where you feel you could type anything. But I also have the inclination to remove more friction these days, and collapse actions. Sometimes I think ‘Should I really collapse this bit or not?’ Again, using my WIP as an example, I cover all the verbs (82 or whatever it is). But most of the time, what you have to do is done with the same six or so. It makes me feel like sometimes I’m covering the others for nothing. I do hope to frictionlessly enforce the use of a wider range of friction-inducing verbs at points to introduce them into player consciousness within the game. So yeah, the verb set thing is the site of more trouble in my brain. But not deep trouble.
May I suggest that such assertions are really a self-fulfilling prophecy? The more people believe the problem is insurmountable, the less they will be inclined to try making parser games player-friendly. Take, for example, the oft cited EXAMINE/SEARCH problem. Here’s a simple way to reduce its unfriendliness to novices. The first time the player examines something, add an additional message saying, that this a fairly superficial examination and one should use SEARCH to do a proper one. How many games do that?
I could not agree more. In my own, fairly massive, Adv770 I went to a great deal of trouble to do just that. Yes, the cost is high, but players appreciate it. And it does not necessarily mean providing oodles of additional objects. My solution was to try ensuring that every noun in game’s descriptions and guide’s comments can be referred to and elicits some kind of a response, even if it is just “Oh, that’s just scenery!” Did I cover the lot? Probably not. But the resulting coverage is very unusual – or so players tell me.
Now, I freely admit that my personal experience/expertise is limited to a single, utterly non-mainstream system (see my profile) and that my knowledge of other IF systems is highly superficial at best and mostly non-existent. But it strikes me (and please correct me if I am wrong), that the real problem with parser games is that parser implementations are based on the concept of pattern matching, which is, indeed, inherently player-unfriendly.
To my mind, there are (or should be) two distinct layers to parsing player commands. (a) Match command words to words in the games vocabulary, ideally allowing for abbreviations and simple typos. (b) Given the words so identified, try to make sense of the player’s intentions, on the default assumption that the command was meant to make sense (what is known in philosophy of language as the Principle of Charity in interpreting others’ utterances) – and that is very hard to do just by pattern matching. Yes some players will deliberately try to fool such a parser. I reckon that’s their problem :-). I am more concerned with players who are actually trying to play the game.
Do any IF systems implement this double-layer matching/sense-making schema? It doesn’t seem to be mainstream, since even just handling noun/verb combinations seems to be deemed controversial. But do feel free to dispel my ignorance!
The standard modern parser does have two stages, as you describe. First it matches input words to (abstract) verbs and objects, and then it tries to execute the action based on the verb and object(s).
However, the first stage is traditionally concerned with synonyms, not typos and abbreviations. It’s assumed that the author will add sensible abbreviations to the synonym list. (Occasionally I’ve added typos too, but only if I thought they were very likely typos.)
So there’s room to fit in your idea, but we generally haven’t gone there. I think Aaron Reed’s Smarter Parser extension tried to make it work, but results were mixed.
I would be less charitable, and phrase it thus: “…the problem of the parser is very difficult. There are two common evasions:”
The solution, of course, is to bite the bullet and write a good parser. Until that is done, IF will not expand past the relatively small group of aficionados who currently write/play it.
Yes, I am over 40, and am dismayed by the lack of progress in parser design in the last several decades.
The adv3Lite library for TADS 3 has a spell-checker that corrects errors, as well as properly-spelled words intended for another (such as “cattle” for “castle”).
In my experience it works pretty well, although it does occasionally overreach.
Eh? Why? That just adds to vocabulary uncertainty. It is trivially simple for the game engine (of whatever sort) to allow abbreviation of all vocabulary words to the minimal unambiguous length and to signal when a word is actually ambiguous. Ditto for typos. I should know – I’ve done that. And yes, I am well aware that IN could be an abbreviation of INVENTORY, that some commands words should not be abbreviable, that special abbreviations like G for GET are useful and that abbreviations and typo fixing should not reveal things player should not yet know about. Again, all of that is trivially simple. Perhaps I should stop feeling apologetic about the current “primitive” A-code parser.
I had a look at adv3Lite’s features, and it is obvious that its author is on the same wavelength as me. In fact, it includes things which I have been wanting to do but never got around to doing, like responding to GET ALL with a single “You/I get X, Y and Z.” instead of giving separate responses for each. Having said that, do many TADS games actually use it? I also see that at the time of its release some were asking what problem it was supposed to solve.
Well, that’s good to know. I was genuinely unsure how accurate my diagnosis actually was. And you are right, this is somewhat off-topic. Maybe I should start a separate topic to discuss what player-friendly parsers should be like (but aren’t). I’ll think about that.
Mmm… Unclear. Do you mean you write IF like that or that you are being charitable in interpreting my grizzling?
Because it fit in well with the Z-machine architecture, which is oriented towards word units and not all that great at letter-by-letter processing.
I’m not saying you’re wrong. Figuring out all unambiguous prefixes would be nice. But I don’t think it’s an order of magnitude improvement either. People who are trying to get comfortable with parser games aren’t particularly likely to type “EXA GOL MAC” even if that’s an unambiguous way to examine the gold machine.
Great minds and all that!.. While it won’t be directly applicable to a wider case, you might find it useful to have a look at the description of A-code command parsing: A-code parser. It is far from perfect but it just might give you an idea or two. Or not.
Is that architecture really so inflexible? Surely, at some stage it must be matching command words against game’s vocabulary, which means calling strcmp() or equivalent. One just needs to replace that comparison routine. And if it really must be a drop-in replacement, then add some global flags to signal the permitted precision of matching and the quality of match located. Elegance of design cannot trump quality of player interface.
Sure. The main obstacle is pattern matching and the mindset it encourages. But that does not mean abbreviations and approximate matching aren’t worth doing. Improving player interface would be useful for seasoned players too.
The very first time I ever thought I had found a bug in an Infocom game, it was the response to CALL VICTORIA in Suspect, when you’re in a room with a telephone. The game responds, “Too bad, but the comfy chair has no telephone.”
You see, I had momentarily misremembered the victim’s name. Her name is Veronica, but I was thinking Victoria.
My command was unambiguous; VICTORIAN is a synonym for the comfy chair object, and no other word in the game starts that way. Still, this was not a helpful response.
That’s just bad coding. The game should have checked whether the referenced entity (VICTORIA[N]) is an NPC of some sort. Instead it mindlessly substituted “comfy chair” into the stock response. No parser architecture can prevent author’s being lazy.
Furthermore VICTORIAN is an adjective and I would definitely caution against accepting abbreviations (let alone approximations) in cases of adjectives not accompanied by nouns. An adjective on its own is effectively an abbreviation even if typed out in full, so in this case it would be an abbreviation of an abbreviation. Definitely dodgy and I would not advocate accepting it.
The Inform parser follows Infocom’s, which happily accepted GET ELVISH or OPEN ELONGATED. Those are cases where the player’s intent is clear. I don’t see a reason to surprise the player by not accepting the command.
(I clearly remember relying on this feature in the Apple 2 days. I didn’t have as much experience typing back then; GET RED was easier to type than GET RED SPHERE.)
For the famous POT PLANT and PLANT POT example, you can argue that X POT is a better fit for PLANT POT. (Because a single noun is more likely than a single adjective.) But that’s a question of weighting, not rejection.
Given that, Inform’s parser doesn’t try to distinguish nouns from adjectives at all. You can perfectly well type GET SWORD ELVISH. (Zork would reject that.) I agree with this decision, although the tradeoff is a little bit subtle.
The point is that the parser asks the author to provide a simple list of synonym words. This is an obvious task; it’s easy to get the basics right, and can then be incrementally improved by thinking of more synonyms (or abbreviations). Asking the author to categorize words into “nouns” and “adjectives” is extra work and the author might get it wrong. Not worth it.
Hm, now that I re-read your post, you’re talking about unaccompanied abbreviations of adjectives. That’s not the same as standalone adjectives. But it’s getting into some pretty fine slicing.
Indeed I was (and I was cautioning against, rather than just ruling out). But I was also talking in the specific context of the case quoted by Nathan. There the problem was that the command did not make sense and was being quite correctly rejected, but the rejection response still assumed that the intended entity was correctly identified from the truncated adjective, thus effectively violating the principle of charity – I don’t see any fine slicing in calling that out as dodgy.
I have no problem with accepting noun-adjective on par with adjective-noun. It makes perfect sense for the parser to treat both adjectives and nouns equivalently, simply as names (possibly partial). But a human player does distinguish adjectives from nouns and is, by default, far more likely to use both adjective and noun, or just a noun, rather than just an adjective in referring to an entity. Thus in trying to infer player’s meaning, it is useful for a higher level of the parser to be aware of the difference between nouns and adjectives. If a command is not understood and the identification from adjective-only was inferred rather than exact, it must be considered doubtful. Not impossible, but doubtful. And the rejection should reflect that, in order to avoid confusing the player, as it understandably enough, confused Nathan.
Of course, if the IF engine in question simply truncates everything at 8 characters, there isn’t much a game’s code can do to allow for it not being actually an exact match. (Is Inform really restricted to 8 characters? Even for non-abbreviable “magic words”? That would be a pity.)
Finally, no. I am not asking authors to categorise entity names as nouns or adjectives. I am suggesting that the game engine could give an option to do so, to those authors who care for such things. As for “authors might get it wrong”, that’s hardly an argument. Authors can get all sorts of things wrong – it’s called bugs.
(Disclaimer: the above is my current thinking, I reserve the right to change my mind after giving the matter more thought and coming to a better understanding. It does happen. :-))
The version 3 Z-Machine is limited to 6 characters, later versions are limited to 9 characters. (Matching input to the game’s vocabulary is done by the Z-Machine interpreter, not the game’s code, so this can’t be changed.) In Glulx Inform, the developer can set the number of characters in a dictionary word, but the default is 9 characters for historic reasons.
