Narrative based IF is predominantly for the over 40s?

[Dizzydonut]

Yes. Personally I like carefully reading scene descriptions, X-ing scenery to get more info and slowly putting together an impression of the location. I like this sort of exploration. But I get that this is partly because to me, typing is a transparent activity: to me, wanting to look at the cherub and typing “x cherub” involves almost no effort, because I’m a keyboard basher. But that’s because I’ve spent thousands of hours hammering the keyboard. To someone who normally uses the mouse (or their fingertip) to navigate it’s not transparent. They want to explore the world, not this weird QWERTY thing (why aren’t the damn’ keys in alphabetical order so people can find them???)

That’s why I’ve suggested using links: they function as a form of emphasized text so that players don’t have to play blind man’s buff with the room description, and also as an alternative interface which requires no typing. Combine them with a scrollable “Verb strip” down one side of the page (which would also reveal the available verbs, as has been suggested elsewhere), and you have (most of) a parser’s functionality.

Of course there are a bunch of tweaks that would need to be added, e.g. how would a player conveniently use a peeler in their inventory to PEEL FRUIT WITH PEELER, but that’s the sort of thing that gets worked out as people use the MK1 interface.

The IF community has worked hard over the years to produce a more intelligent parser, so that the computer’s literal-mindedness about e.g. opening doors with the correct key gets airbrushed out once the puzzle has been solved, and we now take for granted things like implicit actions and smart disambiguation (e.g. “prefer held”) for granted.

I think it’s now time we turned our collective attention to the playing interface, that’s all. There’s already been a deal of good, quiet work there, so that players no longer need to download a half dozen different standalone 'terps, but the assumption is still that input is via keyboard. For the new generation of would-be IFers, this seems no longer to be their go-to interface.

@HanonO

Others want to know exactly what’s in play.

Yes, particularly when I’ve gotten stuck, I’ve found it useful in games which displayed interact-able objects in a separate window: “Oh, right; the only things implemented in this jail cell are the door and the air vent, so I’ve been wasting my time using the chili paste on the window bars.” (As Mythbusters fans know, that was a jailbreak technique in real life.) Sort of a meta-hint, I guess.

[Dizzydonut]

@mla

@Dizzydonut

Unfortunately I was never interested in telling the sort of stories where you have to escape from a room using a postage stamp, a piece of smoked fish and a pamphlet on pyorrhea.

Heh… me neither! And I heartily dislike that kind of IF. Nothing unfortunate about that.

Well, for me it was unfortunate, in that IF languages are geared towards creating games which center on manipulating inanimate objects in cunning ways. I was interested in telling stories, and stories have characters – which implies being able to code NPCs. I found the DM4 in particular wasn’t helpful about this.

TADS documentation was better, and T3 in particular had a lot of support for NPCs but I seem to have a non-TADS brain. My fault. Or perhaps IF’s version of the Windows/Apple divide!

But yeah: all I really meant was that had I wanted to produce an Adventure or puzzle type game I would have been working with the grain of the languages.

@mla

But I disagree that the problem of “stuckness” is either inherent in or restricted to parser games. While a particular implementation may make it more or less likely, the real issue, I think is with the author’s mind-set.

Yes, that was what I was trying to say with the standing on the table example earlier. To the author, this was not intended to be a puzzle, it was game-world verisimilitude for looking out of a high window. But because the author and the player had differently imagined the relations of objects in that location, in a parser game it created an unintentional puzzle (the author’s fault for not explaining clearly enough, or not teaching the player about climbing up onto things.) In a Twine game, that lack of clarity would not create an unintentional puzzle, because the option of climbing up onto the table must be explicitly there, in the text, as a link. (If the link’s not there, it’s an unambiguous bug, rather than the more subtle sort of fail we’re discussing.) That was what I meant by this problem being inherent to parser games. But I agree, it’s not restricted to them.

Re: scenery matching, in inform 6, adding vocab words to a room results in the parser responding to any of those words with “There is no need to refer to the overmantel during the course of this game.” This is economical in its use of memory and processor time, a necessary consideration for z5 and z8 games.

In I7, the sentence “The overmantel, the ornate mirror and the aspidistra are scenery.” is valid code, and will (okay, should, that code is untested) create scenery objects which respond with bland defaults to all the usual verbs. This is more expensive, but not a problem on a modern machine.

So I think that objects being mentioned in the room description but not implemented (even in this perfunctory manner) is really a symptom of author fatigue.

I’m not sure that matching all the recent text would increase the illusion of parser intelligence though. Imagine:

You’re struck by the throne room’s air of faded grandeur. Sun browned tapestries flank the ancient throne, now revealed as iron hard oak beneath the peeling gold leaf.

> X LEAF
(should be synonym of the throne)

\X TAPESTRIES
You see nothing special about the tapestries.
(From scenery matching, and a fair enough response.)

But:
> X GRANDEUR
You see nothing special about the grandeur.

Hm. But on the other hand, it’s essentially free, and relying on the notion that players are trying things in good faith is a good principle. Storing the output of the last LOOK action, filtered by a lengthy stop-list to strip out “the” etc., would make it unnecessary for authors to implement routine scenery objects at all. It’s not quite free: the cost would be the lack of synonyms, alternate British/American/mis- spelling and so forth, but as a last resort before the generic “I didn’t understand that” response, it could be a good catch.

Okay! You’ve convinced me!

[mla (Mike Arnautov)]

@Dizzydonut

Okay! You’ve convinced me!

Well, that a first!!

[HanonO (Hanon Ondricek)]

@Dizzydonut

Yes, particularly when I’ve gotten stuck, I’ve found it useful in games which displayed interact-able objects in a separate window: “Oh, right; the only things implemented in this jail cell are the door and the air vent, so I’ve been wasting my time using the chili paste on the window bars.” (As Mythbusters fans know, that was a jailbreak technique in real life.) Sort of a meta-hint, I guess.

Actually, that might be a neat feature of parsers in the future: In graphical games interactable objects often get a glint or a shimmer or a halo effect to notify the player, either always on, or off by default and the player can “ping” to highlight objects in their radius.

Since many like experimenting on the text, it would be neat if parsers had a hotkey that could temporarily highlight important words/objects in the current room description without spoiling with a list. That would probably require an advanced interpreter similar to Vorple.

[AmandaB]

@HanonO

it would be neat if parsers had a hotkey that could temporarily highlight important words/objects in the current room description without spoiling with a list.

That is a fantastic idea.

[Dizzydonut]

There was a long discussion of having such a hotkey in a different thread https://intfiction.org/t/strengths-of-various-forms-of-interactive-storytelling/44348/38 a while ago.

(Sorry that link jumps you to my contribution, that’s how I found my way back to it.)

[Melendwyr]

Oh no, not exclusion!

That’s what categories are for - inclusion implies exclusion. They wouldn’t be useful, otherwise.

Any specific game does several things

That’s wrong. Many ‘games’ accepted as IF do only one thing. And they aren’t even all games.

[tmack]

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.

[Alianora_La_Canta]

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?

[severedhand]

@tmack

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;

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.

@tmack

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.

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.

-Wade

[mla (Mike Arnautov)]

@tmack

One of the things that’s soured me on interactive fiction recently is that the problem of the parser seems to be insurmountable.

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?

@severedhand

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.

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!

[zarf (Andrew Plotkin)]

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.

[JoazBanbeck]

@tmack

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:

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.

[jnelson (Jim Nelson)]

@mla

(a) Match command words to words in the games vocabulary, ideally allowing for abbreviations and simple typos.

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.

[fos1]

Good point Jim.

It might be interesting to do a current comparison between Adv3 and Adv3Lite and their relative player friendly options.

I’m currently about half way through Eric Eve’s Tour Guide for Adv3.

[JoazBanbeck]

@mla

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.

You are not wrong. Off topic, maybe, but definitely not wrong.

@mla

…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…

I’m doing this.

[mla (Mike Arnautov)]

@zarf

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

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.

@jnelson

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”).

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.

@JoazBanbeck

You are not wrong. Off topic, maybe, but definitely not wrong.

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.

@JoazBanbeck

@mla

(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…

I’m doing this.

Mmm… Unclear. Do you mean you write IF like that or that you are being charitable in interpreting my grizzling?

[zarf (Andrew Plotkin)]

@mla

Eh? Why?

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.

[JoazBanbeck]

@mla

Do you mean you write IF like that or that you are being charitable in interpreting my grizzling?

Neither. I mean that I am writing a parser, and that I had reached much the same conclusion as you about pattern-matching.

[mla (Mike Arnautov)]

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.