I’m looking into parser interface/functionality design and I’m curious, what’s your favourite parser engine from a player’s perspective?
Of your favourite, what would you change about it?
Any opinions or even new ideas on the matter are welcome.
7 Likes
I don’t have strong feelings about “classic” parser design, but in terms of recent-ish games with novel designs, I think my favorite is Baba Is You. Dunno if that’s too much of a trick answer for your purposes, though.
In terms of the way forward, I think that insofar as we can imagine parser games having a future (as opposed to just sorta tooling along as a sort of videogaming repertory theatre), it’ll probably involve using “modern” NLP methods for e.g. sentiment analysis in place of “traditional” tokens-and-productions parsing. So instead of explicitly defining >TAKE [thing] as a valid construction, you’d define a class of take-able objects by associating some gameplay consequences (like moving the object into inventory) with a key present in e.g. WordNet, like “take”.
And then AI parsers take over and we spend all our time trying to convince the parser to just talk about caves full of treasure instead of wandering off into talking about anime all the time.
7 Likes
“Interface” interpretation #1: a lot of this applies to the interpreter I guess, rather than the game’s code. I’m talking only about I7; I don’t know anything about other languages.
I think a player should have full control over text display (font, font size, colors).
It would also be nice if authors could set a default.
I wish that images could scale to window size reliably.
I think configuration should be possible via a GUI.
I think screen reader support should be robust and intuitive.
So far as game design goes, I think that players should be able to toggle use of special characters, since they can annoy screen reader users.
I agree with @HanonO 's recent comment about typing and clicking: I only want to do one. Don’t make me switch back and forth.
“Interface” interpretation #2: I think the current rhetorical model for inputs gives new players a hard time. To me, that’s the real issue with attracting new players. Or the biggest one, anyway. A parser that could understand more variations and synonyms would be great. Or infer player intent (with a decent success rate, this will probably never be perfect) from incomplete commands. I’m not really talking about a chatbot or complete AI package because I want full control of output as a writer. There may be room for an input solution, though. Dunno!
8 Likes
I agree with the points made above, would like to add my own perspective as a gamer who enjoys and prefers parser based IF (old school and modern).
I see parser as a limiting aspect of IF rather than an asset in itself, like a canvas or a frame of a painting. Good games can and has been built by using two-word parsers as well as more advanced ones.
For me the most important feature of a parser is that I have to be able to trust it, and to that end consistency is the key; (e.g.) no unique phrasing for special circumstances please.
3 Likes
I’m looking at the topic from a traditional, enter commands, output more story perspective, but that is a cool game! I never saw it before. The rock I live under must be affecting my knowledge of games somehow. 
I wonder about things like, is it best to keep building the story on the bottom? Seems tried and true. Should error messages (like, you see no such thing) be removed from the story after the next command is entered to remove that train of failed guesses? Would it be better if your commands don’t make it into the story log and just the story results remain? I kind of like it when the command bar is always present and doesn’t scroll with the story log. These are things that I’m thinking about, but nothing is off the table in this topic. Well, within reason.
I wholeheartedly agree. I was just thinking about this yesterday, actually, along with synonyms.
The way to configure the interface should be done with parser commands, I believe. Possibly using a # symbol and a command, like # dark theme. Keep the ideas coming!
The parser as a limiting aspect is exactly why I bring up this discussion. I don’t want the game engine/interface getting in the way of a good story.
The only unique phrases that should be allowed are those that can also be accomplished with tried and true commands. I personally don’t like nondescript verbs, like use and combine. I like simplicity, but not at the expense of deliberate intent going out the window.
2 Likes
Why even accept that input? Give unknown objects (or verbs) a red underline and ignore the enter key. This is the most hostile element of parser games. It was one thing in the 80s when parsing was too slow to do on the fly. At this point it’s just kicking the user to ignore invalid commands until they’ve invested the maximum amount of work entering them.
3 Likes
YES! That game was brilliantly designed! And it speaks to the recent thread about whether or not graphics add to a player’s experience-- that was a game that seamlessly blended parser (at least I think it counted) with graphics.
2 Likes
Interesting. With a command/parser input that remains statically to the bottom of the screen, smaller error message text below it could explain the problem discreetly enough as well. Yeah, it just bothers me to see a long chain of errors (what is essentially not the story) in the story text. Good idea.
For a more traditional parser game, I keep thinking of horizontal slivers of graphics that don’t paint a full picture, but bring visual attention to the subject at hand. Like a weapon being drawn from its sheath or eyes looking to the side, drawing your attention to a shadowy figure behind. Just visual embellishments, I suppose that don’t cause a great amount of scrolling.
1 Like
A red underline is just a very, very unhelpful error message and changing the way the enter key works is making the interface more complicated and less intuitive.
I mean I 100% understand the sentiment, but changing the interface (by blocking the normal “submit” semantics) instead of accepting the input and giving a responsive error message is something that will overwhelmingly confuse and enrage players.
Or at least that’s true in general in UI/UX design. I suppose IF might be a special edge case, but I can’t think of any reason why it would be.
7 Likes
I’m following the All the Adventures blog, and the number of screenshots that begin with two or three failed commands is amazing. Usually dumb stuff too, like a typo or not guessing the right substring of the item’s name to refer to it with. If a seasoned adventurer makes this many errors in transcripts intended for publication, there’s a UI issue. Has me feeling kind of militant.
@jbg I don’t think you’re right about that. There’s a red underline under your name as I type this post, because my spell checker doesn’t know it as a word. If I press Ctrl+Q to quit my browser, there’s a modal confirmation dialog and clicks outside it are ignored. I’ve filled out many forms that disable the submit button until the fields have valid contents. Ignoring the enter key is exactly the behavior of Ubuntu’s Activities overview when there are no results for what you’ve typed. On the other hand I know for a fact that traditional “gotcha” parser behavior is enraging and confusing. And I say this as somebody who likes command lines.
3 Likes
Now imagine if you couldn’t submit your post until you “corrected” it.
You’re right that there are interfaces that do this kind of thing. Sometimes it even makes sense. But for forms in general if you present the user with a disabled element it will cause confusion.
Like grey out a submit button on submission (that is, when used)? First you’re going to have a bunch of users who sit patiently, because they’re not sure if it’s still “thinking”, and they don’t want to end up submitting things multiple times. Then you’ll have some that just wail on the return key in frustration…why isn’t it accepting input? Better try again!
Then if you’re lucky some people will notice the styling elements that indicate that something is wrong. If they’re using a device where that’s visible (and hope you have a more accessible alternative for people who aren’t). But okay they identify that some words are underlined. Now what. Is the input invalid here? Is it invalid globally? Instead of guess-the-verb you’re giving the player guess-the-error.
If your top-line goal is to make the user experience less frustrating, the answer is almost never to make the interface more complicated and less responsive.
7 Likes
also I feel like “visual red wiggly line” and “not accepting keyboard input for things with red wiggly line” is inaccessible in a different way. screen readers don’t read stylings.
edit: I now see jbg said this but just echoing in that case
3 Likes
A big part of learning how a text game works is figuring out what input is acceptable and what input isn’t. That’s true for a lot of games; if you play Ocarina of Time you run around trying to find the borders of the early village, and when you get the sword you try button mashing to see what it can do.
Errors aren’t a problem of parsers, they’re its lifeblood, because text input is so open-ended that it’s almost impossible to know what to enter unless you’re guided. And the main ways of being guided are either having experience (which doesn’t work for attracting new people) or having helpful error messages.
Unhelpful error messages are like ‘you can’t go that way’. Helpful error messages are like ‘You can’t go that way; the only exits from this room are to the north, south, etc.’
You can also guide players with tutorials or suggesting commands via the text (e.g. this phone looks like you could call someone with it).
But errors are still important. Games that remove all errors end up not providing feedback and make for a confusing experience: did something happen because of what I typed, or is it a timed event? Examples include the games Mirror and Queen, My Angel, and Laid Off from the Synesthesia Factory, all on IFDB, and all getting decidedly mixed receptions despite being highly polished.
You can also completely eliminate errors by getting rid of the parser and using buttons, of course. But that removes the illusion of infinite possibility the parser provides.
Edit: One example of unhelpful parser messages is Adventuron’s default message “You don’t see anything special about that” (or something like that). It’s used both for objects that don’t have a description and for objects that aren’t there (i.e. typos). So it’s hard to tell if you typed the wrong name or if the object is just boring.
16 Likes
I think a good high-level exercise for gamedevs is to step back from the design and ask “what’s actually supposed to be a puzzle here?”. And you should absolutely bend over backwards to try to remove any obstacles in the game that aren’t part of the intentional puzzle design. And yeah, I absolutely agree that you should absolutely be liberal in offering hints/options/alternatives for things that aren’t intended to be puzzles but might confuse players.
In gamedev I think you’re constantly switching between wearing your “sneaky DM” hat (when you’re trying to provide challenges for the player to overcome) and wearing your “concierge” hat (where you’re trying to anticipate problems the player might have and how to avoid them)…and it’s really important to differentiate between game design elements that are supposed to be one and ones that are supposed to be the other.
16 Likes
I would like to print jbg’s post onto a shirt and hand them out at a game’s conference.
7 Likes
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. For example, until I have finished Crowther & Woods’ Advent, I kept pondering about the dragon puzzle and canyon with mirror puzzle (among others).
If there are too many of these kind of situations in a game, my frustration rises faster.
3 Likes
I feel like some of these things depend heavily on personal preference and that you’re going to get extremely biased answers because the people here are self-selected to be the ones who like these kinds of games and don’t mind the aspects that other people find off-putting (or even find those aspects to be the enjoyable part).
For one specific example:
Personally I’ve never found the illusion of infinite possibility to be paper-thin and utterly convincing. I can see how it feels to other people, but to me, something like Gruescript games or A Colder Light feel exactly the same as a traditional parser except that a regular parser obfuscates which commands it will understand. I’d much rather type than click buttons, but in all other respects I personally find a button-like interface preferable. I think something like Legend Entertainment’s system (e.g. Gateway etc.) minus the images would be close to my ideal. And I’ve always wished the engines/interpreters were set up so that we could have best-in-class autocomplete instead of ooh, let’s pretend it’s still 1980.
It also seems like people are conflating things that aren’t necessarily linked: things like button interfaces (much like drag-n-drop coding interfaces) can eliminate syntax errors but there are plenty of other classes of errors you can still run into and have fun solving… I do agree that the specific design of the interface matters: a spell-check style underline with no other feedback is both unhelpful and fails to be accessible to screenreaders. But pairing that with info about why it’s an error in a way that gave you instant feedback while you’re typing and didn’t clutter up your scrollback with pointless commands… for me personally, I think I would find that to be a big improvement on what many games currently do.
5 Likes
I’ve not long asked myself that same question as part of designing my own text parser (which I used for my submission to this year’s TALP Jam). I had 6 principles in mind when designing it:
1. Text only
I’m old-school and enjoy text-only games. I like to see graphics in games when they’re done well, but I really like text-only interfaces or only the very occasional image (i.e., not one per location - more like illustrations in a book that crop up periodically to enhance a particular note rather than all the time).
2. Keyboard only
I think this came up earlier in this thread, but the game should be entirely operable through the command line. And that includes cosmetic settings as well as gameplay. I broke this principle a little in my game in that the the endgame gives you some clickable options for how to proceed, but that was only at the endgame, so I was OK with that.
3. No scrolling view
I’ve never liked the way the location description scrolls off screen when you enter a command. I know it’s traditional, but I prefer that I can always see the location description on screen after every command. This also means that because someone can’t necessarily scroll back to see the response to a command they previously tried, there should be no once-only clues given in response to any commands. I did get some feedback from a player used to traditional parser games in that they initially found this ‘odd’ but that they quickly got used to it. I know a sample size of 1 isn’t significant, but I did feel better about this slightly more radical design choice.
4. Limit User Input
Similar to what people have been saying above, I restrict what a player can enter as a command. My game used strict VERB NOUN constructs, so I limited what a player could type to alphabetic characters and a single space. No numbers; no punctuation. I didn’t go as far as restricting players to using only verbs or nouns the game engine understands, but I might go there eventually.
5. Specificity
Something that’s mentioned above, I don’t allow non-specific verbs like USE. If you want to USE SPOON to stir the soup, then use the STIR SOUP command - if you have the spoon, the game engine will figure it out. If you don’t you’ll be told that it’s too hot to stir with your finger (or some other clue). If a player is resorting to using every object in every location to proceed, then that’s a symptom of the game engine getting in the way of gameplay (for me, at least).
6. Don’t let the player get stuck
I find there is nothing worse than getting properly stumped in an adventure game and being unable to continue. So there should be plenty of in-game support available (a HELP command that brings up general help about the game, the interface, command syntax, verbs, etc., and a CLUE command for specific context-sensitive help). Currently, my tutorial adventure allows unfettered use of the CLUE command but in my next adventure, the player must wait a certain number of commands between CLUEs (number to be decided) as I think there’s still a lot of satisfaction from solving a problem yourself and giving players the opportunity to (and the nudge to) try a few more things before they get their next clue. There is always the walkthrough documentation if they get really stuck (and I like when games are accompanied by a walkthrough as a last resort).
As part of this principle, I’d also like to improve my responses in my next game - for example, as someone mentioned above, instead of replying with something like, “You can’t go in that direction,” reply instead with something like, “There’s a wall in the way, but there are doorways to the east and south.” Something context-sensitive, helps the player visualise the virtual environment within which they’re playing, and it provides helpful suggestions about what they might want to try as an alternative.
So those were the principles, my reasons for them, and a little about how those principles were expressed in the UI/UX. Given that I’m about to start building my next game in my new engine, I’ll be keeping a very close eye on this thread!
8 Likes
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. It’s so very disappointing to finally give up and look at a hint (which clearly I will do far less readily than many of y’all) only to discover I was this close to solving it. That kind of thing only makes me try harder first the next time. I don’t find being stuck frustrating so much as exciting.
11 Likes
It’d be interesting to just try it in something like IFComp that records player transcripts.
I think you both make some good points, but I also don’t know if it’s a black and white thing; execution seems to matter quite a bit here. I could imagine two different attempts garnering rather different results.
I also think limiting and clearly communicating the scope of this feature are important. Attempting this with the goal of eliminating all error responses seems unwise. Alternatively, limiting it to a character by character check of whether each word is one recognized by the parser and world model seems more prudent.
For example, this is me typing:
wThe input line is highlighted green and can be submitted.
wiThe input line is highlighted red and cannot be submitted.
winThe input line is highlighted green and can be submitted.
windThe input line is highlighted green and can be submitted.
wind cThe input line is highlighted red and cannot be submitted.
wind clThe input line is highlighted red and cannot be submitted.
wind cloThe input line is highlighted red and cannot be submitted.
wind clocThe input line is highlighted red and cannot be submitted.
wind clockThe input line is highlighted green and can be submitted.
ETAx1: Note that win might have a joke response, and wind by itself would probably still trigger either an error message or a disambiguation.
Note that players might be able to use this instantaneous feedback to more quickly sus out potentially viable words. For example, if this feature were hypothetically implemented on @inventor200 's I Am Prey, then the phrase wind cl would unexpectedly come up as potentially valid, as cl is an accepted abbreviation for climb in the game. Something like this could hypothetically cause a player to pause and ponder what cl is being used for even though they were working on an entirely different command.
ETAx2: You’d need to generate a word bank of every verb, noun, synonym, and abbreviation in the game. You would then need to include any allowed (even if typically ignored) prepositions or similar words (the, to, a, etc.) and any commands or words that work with the standard rules of the parser or the interpreter (quit, attack, transcript, etc.).
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.
3 Likes