Parser Interface Design

[HAL9000]

Thanks, Lee! Your games were one of the reasons why I thought about making my own engine. I could tell that you put a lot of thought into changing the paradigm of text adventures and it got me thinking… too much, some would say.

@CobwebbedDragon

No scrolling view …

The no scrolling decision is something that I have struggled with. I usually ponder these things and play out scenarios multiple times before committing any code. This one has me stumped. Every UI should eliminate scrolling if possible so I don’t dismiss your decision easily. I’ll have to give it more thought, but I like the idea of keeping the location description visible at all times.

---

@Nathan

I’ve read so many of these “never let the player get stuck” comments over the decades, and I just don’t get it. I’m not the player they’re talking about. Maybe it comes down to a difference in personality. My greatest experiences in IF have come from the “aha” moments after being stuck.

We definitely want to keep the “aha” moments. That’s the dopamine rush every adventure game should reach for. Hints that nudge, but don’t push, should be strove for.

How do you help, but not insult a player’s intelligence or spoil a puzzle’s solution? Hmmm…

---

@pinkunz

For example, this is me typing…

And I saw it as you type the whole thing, hit enter… and then it underlines what it didn’t understand. It’s not a live thing, but only after the fact. Still, in that scenario, I would add a small⚠️ in front, but I’m not sure what would happen as you change the command. I guess it would disappear as you re-type it. Blazing new trails… gotta love it!

IF competitions sound like the perfect venue for introducing new mechanics to the public.

Oh, and nice edit, Pinkunz! Much clearer!

[CobwebbedDragon (Lee)]

@Nathan

My greatest experiences in IF have come from the “aha” moments after being stuck.

Exactly! I love those moments! And what I mean by “don’t get stuck” should probably be better articulated as “don’t let the player get so frustrated that they quit the game and do not return” or become completely paralysed an unable to proceed, thereby denying them the pleasure of enjoying the rest of the game. It’s those predicaments I don’t like in a game (any game for that matter, not just parser-based IF - I’ve been ‘stuck’ in other kinds of games and have felt cheated that because of one obstacle I can’t get past, I’m denied access to the rest of the game).

[HanonO (Hanon Ondricek)]

So I’m once again going to throw out my “dream” parser interface which is part SCUMM part Quest/Gruescript. And Legend… (And Dialog…but I want to use Inform!)

Essentially I want to write the game in Inform 7 and I want it to parse like normal. But I want every single word of the output text clickable for the player to construct sentences. I don’t want individual words highlighted. This has sort of been tried in a game called Spondre.

The one slight issue is you would either have to make sure that action verbs are included in the description texts, or you would need supplementary verbs to appear as a dropdown verb list or action wheel. For example:

You are standing in an open field west of a white house, with a boarded front door. There is a small mailbox here.

If I click “You” I’d get options for EXAMINE, INVENTORY, GO. So I could choose EXAMINE and click OPEN FIELD to basically get the room description again, click HOUSE or WHITE then HOUSE to “examine house” or click YOU again to examine myself.

Some actions would appear by default based on kind. Openable containers like the mailbox would automatically offer OPEN/CLOSE/SEARCH (search for “look in”). Lockable things include LOCK/UNLOCK. The leaflet is portable so it automatically offers TAKE/DROP. Probably everything would have the action EXAMINE attached. Keys would include UNLOCK, etc.

Ideally this system would include an editable ‘glossary’ of general and specific nouns that could be programmed with individual verbs and actions that can apply to a word anywhere it appears…so DOOR when clicked could always offer OPEN/CLOSE, LOCK/UNLOCK if lockable (and also just include DOOR to add to the command line for more complex sentence construction) but it would still be parsed as normal so if that particular door didn’t lock the author wouldn’t need to program a special message because it would fail “You can’t lock that.” A more specific object like SECURITY DOOR could be specialized to include the action ENTER CODE. WHITE HOUSE could have a custom verb PAINT action so if I have black paint in my inventory or nearby I could construct EXAMINE WHITE HOUSE AND PAINT IT BLACK. I could also selectively include READ as a synonym for EXAMINE on the leaflet.

Bob, an NPC, could include TALK TO/ASK ABOUT/TELL ABOUT, but if I have a violent game I could also include ATTACK or define a synonym BLUDGEON that only applies to blunt weapons and attach it via the glossary.

If a word in the text does not have actions defined, clicking it just adds the word into the command line, so if I want to get fancy for my transcript I can include “paint THE house WITH THE black paint”. The parser would interpret all of this as a regular typed command.

[pinkunz]

I like this concept, as it is beautifully unobtrusive. Those who want to interact with the game entirely by typing their own commands can do so. I’m going to mentally name this the AllClick Engine in my headcanon.

[HanonO (Hanon Ondricek)]

@pinkunz

Those who want to interact with the game entirely by typing their own commands can do so.

Yes! Exactly. I think this was one of the things Dialog is capable of, but I remember playing Impossible Bottle and experiencing the problem of I can’t quite phrase what I want with the only actions the author has defined here so I have the “gotta switch from mouse to keyboard” back and forth problem. I think the difference is the pop-up actions just add to the command line and are not married to the noun they were obtained from so you can click all over to make actions like ADMIRE PRINCESS DAPHNE AND HER VAIN EFFORTS AT IMPERIALISM based on text words, even if it doesn’t parse correctly, it’d be the same as all the ridiculous things we type in when testing knowing they won’t work.

[AmandaB]

This is what I envision, too. This is most eminently suited to minimal command games like DiBianca’s, I think, but it could certainly work for any game with some careful thought.

[HAL9000]

@HanonO

Seems like a really novel way to do text adventures, especially on a touch screen.

It’s so foreign to me that I’d have to see it in action to have any real opinion, but my mind is reeling with the possibilities. This is definitely worth prototyping. I hope it sees the light of day.

[jbg]

@nephar

Is this the same thing as identifying a puzzle from a player’s point of view? I experience this a lot while playing games. I don’t know if there is a name for the things that look like a puzzle, but aren’t, like red herring for objects but for puzzles instead.

That’s one of the kinds of things I’m talking about. Like sometimes you’ll see something that looks like/is isomorphic to/whatever a class of logic puzzle, and so you immediately look for the state/configuration that can only be accomplished one specific way…only it turns out that the crates in the warehouse aren’t a sokoban/sliding block/whatever puzzle, the devs just decided to implement physics on the boxes but didn’t actually design a puzzle around it. So unless the point was actually to confuse the player or get them to waste time shoving the boxes around, then the game should probably clue the player in that pushing the boxes around isn’t necessary.

There are also a lot of gameplay mechanics that are “meaningful” in that that game actually expects you do to them, but they aren’t “necessary” in that you can complete the game without them. A lot of item-collection tasks are like this. You do have to collect the Nine Keycards Of Prophecy because you can’t enter the File Room Of The Gods without them, but collecting all 1200 Index Cards of Fate from the Rolodex of Squeegeethrax is entirely optional. So the player probably deserves to be told that they really don’t need all those index cards, even if it’s passively (some UI element gives completion percentages, and the keycards are under “Main Quest” and the index cards are under “Side Quests” or whatever).

And sometimes there are complex gameplay mechanics that aren’t supposed to be puzzles in and of themselves, but can befuddle players just because the underlying idea/mechanics don’t initially “click” for them. There’s a DS strategy RPG called Devil Survivor, a spinoff of the Megami Tensei franchise. It has a mechanic called “skill cracking”, which isn’t used in prior megaten titles. Before a battle starts, each of the characters in the player’s party can indicate a specific skill on one of the enemies that they want. If a character takes out the enemy they “called”, they get the skill they selected before the battle. But what a lot of players didn’t realize when the game was first released is that once you crack a skill, it’s just an equipable item that anybody can use. So if you’ve got a character who’s getting all the support skills, you can crack a support skill on a tough opponent using one of your stronger characters and then give it to the support character, instead of trying to come up with an elaborate plan by which the support character can take out the tough opponent. The point being that this wasn’t supposed to be a puzzle or challenge or whatever, but a lot of players ended up banging their head against it because the underlying mechanics were poorly explained.

The unifying point is that it’s okay to make things hard for the player, but you usually really don’t want to make things hard for the player by accident.

[jbg]

@Nathan

I’ve read so many of these “never let the player get stuck” comments over the decades, and I just don’t get it.

For the record, I’m not saying that you should never let players get stuck, I’m suggesting that a good game design is one where the players only get stuck on the puzzles.

I also think that “stuck” is a pretty broad category and some kinds of stuck are better than others. I think whenever possible you should always be providing the player with options, so even if they can’t come up with a solution to a specific problem, that isn’t necessarily halting the game until they do.

And “cruel” forms of getting stuck (you didn’t throw the shoe at the cat during the 2 second window you could do so, and so hours later you will be unable to proceed because you don’t have a rope you have no reason to associate with this chain of events) are probably properly relegated mostly to the past.

[HAL9000]

@jbg

And “cruel” forms of getting stuck (you didn’t throw the shoe at the cat during the 2 second window you could do so, and so hours later you will be unable to proceed because you don’t have a rope you have no reason to associate with this chain of events) are probably properly relegated mostly to the past.

You reminded me of this fantastic rant from over two decades ago. It’s probably compulsory reading by now, but even if it hits one new set of eyeballs, it’s worth dredging up again…

⫸ Death of Adventure Games

[jbg]

@pinkunz

ETAx2: You’d need to generate a word bank of every verb, noun, synonym, and abbreviation in the game. […]

Once you had that word bank, you could crosscheck the input as it was being typed and produce a boolean. The input includes only words in the bank or it doesn’t. You don’t even have to restrict the ability to submit a junk command; it would simply work as an indicator that the input is definitely doomed as is.

The main difficulty I see with this sort of approach (apart from the overhead, which would be negligible on a modern platform like a web browser and prohibitive on a legacy platform like TADS3) is that now you’ve got multiple error reporting behaviors and multiple interface semantics for reporting information to the player. That’s not inherently a problem (this is also true of status lines, for example), but the “naive” IF interface semantics—game presents a block of text, player types a line and hits return, game responds with a block of text, repeat—has the advantage that it’s very predictable and it’s easy to scan: the player always knows where to look and when they can and cannot enter input. I don’t know if there’s any data out there for IF specific design, but in general having separate UI regions for error reporting and other output slows users down and can be confusing.

I’m also a little skeptical of the utility even outside of that kind of thing. Like if the room description mentions pebbles along the path but they’re just flavor text and so when you type >TAKE PEBBLES you get a red X…then the player has to backspace through the entire command? We’re hoping there was something else they wanted to take so they just have to backspace over “pebbles”? They’re just going to hit return and deal with the error message we’ve designed all of this to avoid having to show to them, just because from their perspective it’s less work? Like I’m willing to be convinced here but I’m not sure I really understand the use case.

[pinkunz]

@jbg

I’m also a little skeptical of the utility even outside of that kind of thing. Like if the room description mentions pebbles along the path but they’re just flavor text and so when you type >TAKE PEBBLES you get a red X…then the player has to backspace through the entire command?

That’s hugely helpful information. It tells you the pebbles aren’t implemented at all, meaning you aren’t going to waste time trying look at pebbles or examine pebbles or search pebbles or kick pebbles or etc., etc. You know pebbles is a dead end.

[jbg]

@pinkunz

You know pebbles is a dead end.

Right. But my point is that that’s not something that’s particularly true of any theoretical interface re-design versus just saying “The word ‘pebble’ is not necessary in this story.” or the equivalent, and you’re actually setting the player up for either more work (backspacing through their error(s)) or the same error message they’d get in either case (if they just hit return anyway).

[pinkunz]

>take pebble
That's not something you can take.

I feel like error messages, especially stock ones, are much more likely to be ambiguous, but I grant that this whole thing hinges on execution and communication of player expectations. It can certainly be done poorly.

[HAL9000]

Just curious for people’s opinions on this…

I’m working on a parser interface concept and I’m toying with idea of being in “modes” when it comes to specific input. For example, When in conversation with an NPC, it might be nice to see…

“Do you wanna go to town or what?” he asks gruffly.

> (confirm:) YES

Note: The (confirm:) part is not able to be edited. Just the area after it.

I might be overthinking it, but I like the idea of input being mostly verb + noun so a player could type TALK STAN and the output could show Stan barely glances up from his work. "What's up?", then the command bar could show > (respond to stan:) ASK CARS and what you type is always directed at Stan until you leave the conversation with a LEAVE or BYE. Of course, you can always just do something else to take you out of the conversation, like GO NORTH or TALK LYLE or whatever.

Some games seem to understand the probable target for most commands, but this shows the default intent. I’m just trying to make things as friendly as possible, without getting in the way. That’s the tricky part, does this sound a bit obtrusive or does it sound easier to use? Thoughts?

Edit: Other modes might be > (standing on ledge) if you are traversing a specific part of a room and such. In this case, it reminds the player of their specific situation without having to repeat it in the story output. Just exploring the idea further.

[ramstrong (Harry Hardjono)]

You can just say “Stan:” as opposed to “Respond to Stan:” if you want to indicate that you’re talking to Stan.

How are you going to handle action vs conversation, though? If you’re talking to Stan, and you want to look at the girl in red dress, you don’t want to tell Stan to LOOK GIRL, when it’s you who wants to do it.

Another thing to consider is if you’re talking to more than one person, or that maybe someone is eavesdropping and may interject at any moment.

A Point and Click interface may solve the problem by clicking icons for persons you talk to, but how are you going to handle it with text based parser?

[HAL9000]

@ramstrong

A Point and Click interface may solve the problem by clicking icons for persons you talk to, but how are you going to handle it with text based parser?

Excellent points. I’m not quite sure. Perhaps it’s too assuming with the conversation aspect.

I do like it as a potential description of your character and the state they are in though. Like, if you are in a box, hiding in a room, eavesdropping on other NPCs. > (inside box) or if you are a prisoner > (shackled to wall). I think I’m approaching it as an important indication to the player without having to invoke the LOOK command to know (or remind you) that you are on fire, or dangling from the ledge and such… because when you type your next command, you immediately see that you are doing it from that perspective/situation. I think it may aid in solving puzzles in some way and helping players get into the story more.

Thoughts?

[pinkunz]

It’s probably something you’d have to demo to gauge how helpful and/or obtrusive it is. Otherwise, we’re all just bringing our preconceptions to the table when emulating it in our heads. Might be a good canidate for a Spring Thing Back Garden entry or maybe an Introcomp entry, so you can fold feedback into the finished product.

[HAL9000]

@pinkunz

You are 100% correct, but I’m good with even preconceived notions. I’m definitely not going to argue about the validity of it when it doesn’t even exist. Just looking for feedback as a nebulous concept. So far, the conversation mode critique was quite helpful.

[jbg]

I don’t know what the rest of your design looks like, but it sounds almost like you could lean into the modal stuff and make everything modal. That is, intentionally break up the gameplay into different kinds of tasks or whatever (instead of just specific things like dialog). Think something like Suspended, only instead of just getting different kinds of information from the different robots, you were also using a different vocabulary and syntax in your commands.