…or: What does it mean to be writing interactive fiction?
When asked about outreach prospects for IF at PAX East, I said this:
We have a two-part accessibility problem.
One part is the interpreter: people don’t want to download separate files and don’t want to have to figure out file formats. That structure is unattractive and increasingly out of step with the way casual players play games — and especially with the way that they’re persuaded to try new work. We (as a community) are working on that by developing better browser-based interpreters and making it easier for people to publish material to websites. It’s not true that there’s been no Java Glulx terp at all, but it required its own downloading and does not offer the option of creating an attractive game display within a browser window. Just the last couple of months have seen major strides on this front, with both Quixe and ZMPP reaching the point where they can play Glulx games in a browser window. Zifmia is a project to present games from a server interpreter, while FyreVM is an experiment in letting authors customize their output with channel IO. For TADS 2 there is Jetty, and Mike Roberts is actively working on changes to TADS 3 that would make it possible to do web service of those games. So we’re making a lot of progress here.
The other problem is the parser. When you look at novice reactions to IF — found in responses to IF games posted on indie gaming sites, or in student reactions to playing IF for the first time — the initial reaction is often enraged frustration with the parser. The first few (or few dozen) moves of a new player’s interaction with the game often consists of many many failed attempts that do not move the game forward in any way.
This is alien to most gamers these days. These days, even fairly difficult console games usually guarantee that at the beginning of the experience it’s just about impossible for the player to do something wrong or to fail meaningfully. Interaction options are introduced gradually. By contrast, most IF games are not designed with any kind of tutorial mode or game-opening section, instead offering (at best) a lengthy menu of instructions. There are exceptions (Dreamhold, Blue Lacuna). My own recent games have included an optional tutorial mode (which I think of like training wheels) that give turn-by-turn contextual advice to the player based on what’s currently happening.
It’s not clear to me how well those games have worked in attracting novices and making them comfortable with IF, however. (I just don’t know: I’d love to hear about it if, e.g., there were a bunch of Blue Lacuna players who got acclimatized to IF through that approach.)
Fundamentally, however, we’ve got a bigger problem, which is that the command prompt is a lie. It tells the player “type something, and I’ll understand you.” Which it won’t.
It wouldn’t necessarily make for better games to have a looser parser.
Adrift is partly wild-card based, allowing more keyword-based parsing than TADS or Inform use by default, but the result is often comical misunderstanding when the game fails to consider important elements. More advanced natural language processing approaches have tended to disappoint their users by not accomplishing what’s actually desired or by making it very hard to tell how the player’s input is affecting the results (Starship Titanic, Façade). Brian Moriarty and I (and various other community members) argued about the need for NLP for interactive fiction a few months ago. Since then my own ideas about it have been shifting a bit, though it’s not the case (as Moriarty claims) that the IF community isn’t interested in parser improvements, and I still mostly agree with what I said about the failings of NLP as an interface for games; of course people are nonetheless trying. Even a parser that is genuinely better at understanding input creates some significant problems for a game designer, if it starts to accept adverbs or statements that would require more complete world modeling than the game otherwise needs.
This is why parser improvement work has mostly focused on a few areas: better guessing at what the player means when the useful information does exist in the world model (so we’re not asking the player whether he wants to open the door with the black key or the black forest cake); better identification of player errors so we can offer more guided error messages. Aaron Reed has done some research in this area, and offered his correctives for Inform at least as a set of extensions duplicating much of the behavior he implemented into Blue Lacuna.
But at the end of the day, I agree with Mike Roberts that the trick isn’t to make the parser understand whatever a novice might type, and that the average novice user would actually be happier with a smaller vocabulary that has been spelled out in full.
It’s a matter of making the game better at communicating to the player what kinds of things are valid actions in the first place — indicating the affordances of the system, in other words.
That will also help with the other problem that novices often report: a kind of paralysis of choice. If you can do anything at the command prompt, where do you start?
Yeah. That command prompt is a problem.
While I’m on the topic, I should mention that the parser isn’t a picnic for authors either. It’s thanks to that pesky command prompt that so much development time goes into implementing feedback for completely stupid and inane actions; and who among us hasn’t left in a bad response to >TOUCH MOON or >RUB PARROT, just because the possible combinations of verbs and nouns in our game world was too enormous to think through properly?
These days there are some tools to help with that, and it’s often possible to tighten up the simulation in general rather than deal with every single annoying case individually — for instance, people making far-away things in Inform 7 could do worse than to check out Jon Ingold’s Far Away extension, which would let you designate the moon “far away” and then cope sensibly with all possible moon-fingering behavior.
Still, a huge amount of creative overhead goes into the not-always-thrilling task of creating responses to commands that aren’t sensible, aren’t relevant to advancing the game or story, give the player no interesting character notes about the viewpoint character, deliver no jokey zingers, and are flat-out unlikely to be typed by anyone who isn’t actively trying to break the game.
If you don’t work on that stuff, it makes the game look buggy and unpolished. Because it is buggy, because the player can make things happen that tear a giant hole in the illusion.
But I’d be lying if I said I’ve never wondered why I was bothering, sometime during hour seven of implementing responses to the highly-unlikely instead of working on stuff the player is definitely going to see.
So what then? Do we pitch out the parser and go to a system in which the player’s options are clearly enumerated at all times?
People have played with that idea too. Sometimes the approach is to fill a screen with lots of helps: a compass rose showing directions, a map, sometimes an image of the location, plus a menu or set of buttons representing all the major verbs available at any given moment.
This can get overwhelming. If I’m playing a largely text-oriented game, I prefer not to have the window of text forced into a small corner of the screen while the rest of the territory is taken up with interaction helps. It’s unattractive — and it also represents a style of UI that’s rapidly becoming obsolete. More and more games in the commercial sector streamline away as much as they can in order not to crowd the player’s field of vision with things other than the screen in which the action is happening.
The other way to go is CYOA: not creating lots of helps to deal with a complex interface, but narrowing the choices themselves down to a few narrowly-defined options.
When people talk about CYOA, they tend to mean a format in which the player is offered a handful of explicit options (“To go through the door on the left, turn to page 51. To go right, turn to page 75. To jump out the window, turn to page 9.”).
CYOA is also often associated with its early implementation in book form — Choose Your Own Adventure, the name from which the acronym is taken. Book CYOA either has to make the player keep notes (and trust him to be honest), or skip having any kind of world model or state other than what can be indicated by the page number that the reader is on. Some computer-based CYOA follows the same approach, providing an experience without stats or a model.
That makes for big problems with content generation and plot structure.
If all state is expressed by being on a given page, you either force the storyline to be all branches — every choice the player makes creates a new parallel universe, basically — or you have to rejoin the branches but have the choices before that rejoin be irrelevant forever after, because you can no longer tell which thing the player did. If you want to get a good sense for how that works, structural analyses of many classic CYOA books are online. The state problem explains why the choices in those books were so often arbitrary and unfair: going through the wrong door as more likely to lead to sudden death than to an interesting variation in the late story, because most of the time it was easier just to prune the branch than to continue it.
Structurally, this is no different from the most basic kinds of hypertext; literary hypertext often features a similar statelessness and lack of narrative arc, though it tends to handle that in terms of non-linear time or post-modern narrative structures. And even some literary hypertext tools go further, making it possible to (say) provide guarded links that you can only pass through after seeing other content.
I’m fairly comfortable saying that CYOA without a world model is too limited to express the range of things I’m interested in expressing in interactive storytelling.
Enumerated-choice games with world modeling do exist too. My (evidence-free) impression is that recently they’ve become a bigger part of the gaming scene than they had been for quite a while. (In fact, I got a request to review another such site during the course of writing this post: it’s Unknown Tales, and I can offer no insight on quality, because I’ve been busy writing this…)
Visual novels in Ren’Py are structured to include explicit choices, but it’s possible to set variables and keep statistical information around.
The all-text “Choice of…” series has been enjoying some popularity with the casual games crowd, using a model where the protagonist develops personality stats during play, but the game play is all about making (as their own manifesto indicates) “interesting choices”. (I think Chris Crawford would approve of that part, if not of the non-procedural nature of the rest of the game structure.)
Echo Bazaar flips that model: it’s heavily stats-based and requires the player to grind a lot — that is, to do repetitive actions in order to raise the stats — but offers a wide range of storylets that the player can choose to participate in (and some storylets themselves include multiple choices about what to do inside the story). Your chance of success at a given attempt depends on your stats, and the game retains information about major story threads that you’re part of. Echo Bazaar also features inventory items, money, and limited interaction with other players, making for something that feels a bit more gamelike than the “Choice of…” stories. The tradeoff is that it weakens the narrative arc substantially and forces players to do tedious actions some of the time.
Neither the “Choice of…” games nor Echo Bazaar quite achieves what I’d like to be able to do with interactive stories. EB is too slow and grinding, and I’d like a stronger narrative arc most of the time. The “Choice of…” games weren’t as immersive as I’d like, because there was no chance to engage with the settings or explore small-scale decision-making in the environments. But they’re both far, far closer to ideal than CYOA without a world model.
Maybe as a result of the popularity of these games, possibly in response to some more general zeitgeist, there’s a larger interest in enumerated-choice games within the IF community than I recall seeing for a while.
That’s not to say that there hasn’t been some CYOA following for quite a while. IFDB lists 43, and that’s probably not a complete list of works that were created with that kind of interface and presented to the IF community and/or implemented in an IF language or virtual machine. (It’s certainly not a complete collection of all computer-run CYOA ever, but the IF community tends not to hear of or pay attention to it to the same degree if it’s neither using IF tools nor submitted to an IF competition.)
Jon Ingold’s Adventure Book system provided for CYOA with a world model that tracked inventory and allowed for “magic words”, and there is now an Inform 7 extension that replicates and expands on its functionality.
For a few years the community also ran Lotech comp, a competition explicitly for CYOA-style games. Two entries were particularly interesting with respect to the current issue: Papillon’s One Week and Kingdom Without End by Shannon Cochran.
One Week is a resource-management game with a strong world model, similar to dating sims and virtual novels, in which the player’s choices determined how much time the protagonist spent earning money, making friends, and studying, with effects for the outcome of the story.
Kingdom Without End uses Adventure Book to create something that feels very similar to conventional parser-based IF — the options are to do things like move around and pick up objects, creating puzzles that feel like conventional IF puzzles, but with a significantly reduced range of possible actions.
One significant objection to the enumerated-command approach is the concern that it will eliminate puzzles. If the player is always choosing from a list of options, then where does the figuring out come in?
In practice, I don’t think that is as big a concern than some believe — we talked about this at the April Seattle meet. If the choices the player makes are fairly granular and tied to a predictably-behaving world model, then it’s possible to express many of the same things that a parser-based IF already has in it: making choices to set up a world state in which new choices will predictably become available.
A more significant problem for me is the narrowing of the command space. The average IF game has dozens of available verbs and hundreds of available nouns, and that means there’s lots and lots that’s possible to do. It’s not possible to enumerate that many commands in a way that doesn’t just look like a hideous list. And while I was earlier bemoaning the amount of work that goes into correcting for player input that’s simply useless and meaningless, I also absolutely don’t want to collapse the range of possible action down so far.
Having a lot of verbs is part of what distinguishes IF and provides for its narrative richness. The number of verbs you can perform in, say, Halo is tiny — and that has a direct effect on the kinds of stories you can tell with such a system. Console games especially tend to be very verb-focused in the way they express their affordances to the player — you’re always holding this controller with a relatively small number of buttons on it, and there are often indicators on the screen, or a training process, to help you remember which button means which action.
But a narrow verb set (here I go sounding like Chris Crawford again) means you’re forced to focus all your interactions around a fairly tight set of possibilities. Sometimes that results in a crisp, interactively focused short story experience, but there are a lot of stories for which it’s not so good.
IF is closer in this respect to Sims 3: lots of different objects (nouns) are to be found in the world, and they all have their own affordances. In IF, doors can be open, lamps lit; in Sims 3, the TV can be used for exercise videos or watching movies.
Another problem is that if I’m just clicking or typing numerical choices, I feel less involved in the action, for some reason. I don’t know why that is, but it’s definitely true. I’m fine with clicking on images and radial menus in games like Sims 3, but the interface is also graphical; there’s something appealing about communicating to the computer in the same idiom that the output is using.
So I personally am not ready to ditch the parser entirely, though I’m also interested in games that use enumerated choices over the top of a consistent world model — especially if those games manage to achieve my own aesthetic preferences of allowing some exploration and variability of pacing alongside the narratively important choices.
But I do think we need better ways to communicate the affordances of IF to players.
For some games, a graphical layout with menus or buttons for verbs — Dave Cornelson has very recently been proposing a variation on this — but in many cases I find that approach ugly, and it tends to take up an unpleasant amount of screen real-estate. I start to be uncomfortable when the readable text part of the screen is squeezed down into a tiny corner. Moreover, it’s hard to imagine how that kind of layout would transfer to a mobile device. (Edited to add: Dave points out that we don’t know how these systems would play out with a test market, and this is of course true — like everything I’m saying here, this is my own opinion and not meant to be proscriptive about what other people ought to try out or test. But for my own purposes, I’m not satisfied by this solution.)
Another approach is to retain visual cues but embed them in the main text itself. Bronze and Blue Lacuna both use the technique of highlighting (in bold or in color) important nouns in the text; Blue Lacuna goes on to let the player type just the noun names in order to perform the most obvious interaction with them (such as examining objects and passing through doors). Walker and Silhouette goes the extra step of being largely keyword-driven, though it does allow the player to type something other than the highlighted keywords if he wishes.
One could also provide help at the command line itself, for instance by offering autocompletion lists that would pop up a list of viable conclusions once you’d typed part of a command. One of the things that Ruben Ortega suggested at the Seattle IF meet was the idea of probabilistically generated auto-completion, taking into account the commands given by other players previously trying the same game. That seems like it might often have drawbacks, though — give away puzzle solutions, or else reveal that other players are strangely fond of typing obscenities.
Another approach is to provide suggestions but allow the player to type things besides the suggested command. That’s the approach that Bronze‘s tutorial mode takes; it’s also, in a slightly mutated form, what Jon Ingold’s Dead Cities does — together with providing a hyperlink to click to perform the next suggested action. The difference between the two (aside from the screen layout) is that Dead Cities‘ implementation offers something like a clickable walkthrough, making it possible for the player to minimize interaction and treat the game almost like a book (though I suspect it may be impossible to get to some of the most interesting content this way). (Ferrous Ring explicitly goes all the way with this, letting the user select a mode anywhere from full parser involvement to essentially watching the walkthrough go by.)
Yet another approach would be to offer something that looks like TADS 3/Alabaster-style conversation hints, only for all turns. Unfortunately, that disrupts the flow of the rest of the prose with a lot of mechanically generated content, and with options that will look a lot less diverse than conversation options generally do. I don’t imagine that the results of that would be acceptable.
I don’t have a complete solution to this problem, but here are some passing thoughts.
Hinting to the player about possible actions without listing all of the possibilities is an interesting tactic, but it’s been tried several times and hasn’t exactly set the world on fire yet.
On the other hand, it isn’t possible to list all the possibilities during a given turn of a typical IF game without making the interface incredibly ugly. Even listing all the verbs is unattractive — and, as I’ve tried to suggest, probably not the best way of organizing things, because the interesting possibility space in IF is better organized in terms of the nouns and the interactions they afford than by the verb set. (There are a few exceptions — LOOK, INVENTORY — but most such things could be treated as actions on the player or the room he’s in. Inform already internally translates an object-less LISTEN or SMELL command as LISTEN TO {the room I’m in} or SMELL {the room I’m in}.)
If we had a system where the player could select a noun, see what he could do with it, and select one of those options, that would (Sims-like) both clarify the possibility space for the player and eliminate the TOUCH MOON implementation problem.
Implementing that graphically presents some serious problems, and raises some accessibility issues as well. It’s one thing to click a picture of a television while playing Sims and get a radial menu. It’s considerably uglier to click on a noun in a page of text and get a radial menu of more text. And what happens if a noun is technically in scope, but no text referring to that noun currently appears on the screen? It forces the player to type LOOK and INVENTORY far more often than he’d otherwise have to, which is not good for gameplay or narrative flow. Finally, this is not something that current interpreters are designed to do (so it would require significant tool development), and it’s not clear to me how it could be made accessible for visually impaired users.
Implementing it at the command line seems more doable, maybe, though it has the disadvantage that typing, say, DOOR and getting a prompt with suggested door actions again clutters the transcript with ugliness.
More possible, I think: do like Jon Ingold’s Novel Mode did in My Angel, and move the command prompt down into its own separate window, which gets emptied and refreshed every turn. Keep the space above for game output text. Typing the name of a noun (or perhaps clicking it in the text, if hyperlinks are included) then brings up the list of relevant verbs down in that lower window, which means that at any given time you’re only seeing one such cluttery list, not the last half dozen that occurred during play.
Multi-window modes might be challenging for accessibility too, but it seems less dramatically hard than something that relies primarily on visual clues. One could also create an option to revert to a single-window system for those who wanted to use a screenreader on it in a more classic style.
Doing this well would require language support, because you don’t want the author to have to explicitly indicate every verb that applies to each noun. There would, I think, need to be some kind of “no defaults” system: in other words, the game would need to be able to work out whether a special response has been coded that’s relevant to this noun and verb. If so, the verb is available; if not, not.
Two-object verbs would be more complex, but I think not impossible; the player would pick a noun, get the verb list, and then be invited to specify the second noun.
One could further refine the system by ordering the verb list affiliated with each noun to present the most likely options first. Maybe also allow typing a verb and getting a list of nouns that it could reasonably work on, so that a practiced player who prefers old-style command entry could still choose to type OPEN DOOR instead of DOOR OPEN — it would just reject attempts to pick a noun (or verb) that wasn’t currently available.
This could be combined with text highlighting as well, so that the player would be able to see by looking at the screen which nouns were implemented as interactive — just as long as the player doesn’t have to be able to click on the noun in order to activate it, we avoid the accessibility problems and the need to type LOOK over and over in order to get access to items in the current room.
There’s a (very rough) prototype of what I mean here.
Something like this would permanently eliminate guess-the-verb, though at the cost of removing those rare occasions where we… well, want to make the player guess the verb, because the action is something cool but optional (like TWIRL MUSTACHE). Unquestionably something would be lost.
But think of it: no more TOUCH MOON. Lots less monkeying around with providing intelligent disambiguation and defaulting. The ability to smoothly prompt new-to-IF types of action, like BLACKMAIL or ANALYZE or ANTAGONIZE. The ability to back off from the strictly physical focus of IF by highlighting abstract nouns or ideas in the text as interactive instead. Easier avenues to fully systematic beta-testing. Many fewer pitfalls for novice authors. More scalable implementation, making really long games less onerous to take on.
I dunno, am I crazy?
Emily Short's Interactive Storytelling 
Really interesting article.
I’m currently doing my dissertation on a Multi-Agent data driven dialogue system.
To keep the scope within manageable limits all input and output is symbolic. The idea being that input & output could be approached like translation / compile problem. Separate from the dialogue system.
A Parser or NL front-end and NL back end would be much more natural I think. The more I research NL processing though the more I want to look at other systems.
I looked at something like Dead Cities approach where elements of the response are clickable but that only works for simple queries. Compound queries or comparison based queries don’t work in the system.
Well anyway, interesting article and you got my brain firing on this early Monday morning :)
Emily, this is fantastic.
Of course, there’s nothing keeping both the current and new parser approaches from being publishable at the same time. IF as it is will be around a long time.
But I think you’re hitting the problem on the head here. This hit all my design instincts comfortably. And there are already common text and UI design idioms to draw from that new audiences are familiar with. The filter box comes immediately to mind for your noun-verb-noun structure. Instead of seeing the list in the text bar before you type, it brings up a sub-window below the cursor of the remaining available options as you type. The noun-verb-noun structure also models how we -think- about these worlds, spatial main noun first, which would be quick to pick up.
NL has been an unnecessary stumbling block for decades. It should be pursued, but not constraining in the meantime. What makes IF unique is the depth of detail and interaction in a given space, not the parser itself.
I’ve read only half of the article, so better write down my thoughts now before they leave me. I’ll finish the article later.
Adam Cadre has been cutting all unnecessary verbs in his games, resulting in a neat group of verbs needed for the story. I think, he uses this since Narcolepsy (or it becomes evident for me since that game). I don’t know if that approach is good or bad, but as an interface it is perfect because the player founds that “I don’t understand that verb, type help to see the list of verbs”. You lose the advantages of opaque interfaces, but gain in efficiency.
So, a good and neat explanation of how the interface works, could help a lot (yeah, I know, nobody read instructions nowadays).
About the CYOA topic, there’s something in my head for a long time… Is it possible to generate a CYOA interface dynamically from a complex model world? For example, a layer of CYOA interface above an IF game, made for children of 7 age or less, it would be perfect. An interface that detects automatically the options at hand and present them to the player (a more longer list than traditional CYOA games. It should loop for all objects present in the room and list neatly all the actions to do).
Roguelikes work like this, with adaptative lists of objects, menus and options and actions, depending of the state of the model world. But of course Roguelikes are not the place to go, they have the worst and more inaccessible interfaces ever.
So, a good and neat explanation of how the interface works, could help a lot (yeah, I know, nobody read instructions nowadays).
Yes, you’ve pretty much summed it up here — the standard advice in commercial game development both in the “casual” and “hardcore” sectors is that players do not want to read instructions; they want to start playing the game. If they can’t start the game and get somewhere, they will give up and move on.
And the industry has come to the conclusion that the instructions must be inserted in the first stages of the games (tutorials). I don’t want to start a debate of if this is good or bad, but undoubtley IT IS working. So I think your own efforts and others such us put a beginner in the first turn of the adventure, is a really good idea, and that provides an elegant solution for the “presuntely” problem of the parser as an interface.
One more thought: we have all the tools for make interfaces as easy and intuitive as an author wants: beginner tutorial, instructions sheets, highlights text, hypertext, list of clickable verbs. But the problem of all this is that is a decision of each author… For example, there is a library to make minimal parser interface games suitable for portable devices, but it is useless as is because only the games that uses them by the explicit decision of the author, has that kind of easy interface. That is, if I want to play Spider and Web in my imaginable palm pilot, I can’t have that interface because the game isn’t compiled with it. So the same occurs with all that solutions for beginners. We should try to accomplish to have the interface separate of our stories, so whatever interface could be applied for each platform and kind of player.
One step for this goal, would be to have some of the solutions for the interface and newbies integrated in the development systems. But the ideal would be to have the kind of interface in the interpreters.
We should try to accomplish to have the interface separate of our stories, so whatever interface could be applied for each platform and kind of player.
This is a nice idea, but I think it’s only workable to a point. Some games could work with only clickable commands, but others couldn’t — for instance, anything that’s doing advanced parsing with freeform numbers (“SET DIAL TO 1537”) or allowing the player to enter the name of something (“NAME THE DOG FIDO”). So I suspect the reason we don’t have such universal tools is at least partly that one size doesn’t fit all here.
anything that’s doing advanced parsing with freeform numbers (“SET DIAL TO 1537″)
Though your point is generally well taken, point-and-click room escape games have you set dials to 1537 all the time. You could use a similar interface for anything involving numbers, though at that point it’d be easier to type it in — which is actually something that occasionally happens in other point-and-click games.
On the general point, part of the reason that you can’t play Spider and Web that way is that (for reasons I mentioned downthread) Spider and Web just wouldn’t work with this kind of interface. Ruber has a good point that it’d be better to have a front-end that let you play general games like this than to only be able to play games that had keywords (or whatever) enabled. OTOH, if we’re looking for ways to introduce IF to people, do we want introductions that will close people off from being able to play games with freeform parsers? That would make it seem as though we would be replacing traditional IF with something else.
One possibility is having a keyword-based mode that supplies the command you’d be typing if you were entering it into a freeform parser. I don’t know how appealing that would be, though.
OTOH, if we’re looking for ways to introduce IF to people, do we want introductions that will close people off from being able to play games with freeform parsers? That would make it seem as though we would be replacing traditional IF with something else.
We’ve tried to train players. We’ve had interpreters with auto-completion and typo correction. We’ve had games that came with handouts, manuals, help menus, built-in tutorials, training wheels in the form of suggested commands each turn, etc. I’d love to see evidence to the contrary, but it does not appear to me that those solutions have addressed the fundamental problem. I used to think the problem was one of degree — if we just did more of this sort of thing, it would be enough. I now think the issue is something more fundamental: simply, that the standard command prompt is a bad piece of design because it communicates nothing about the affordances of the system. After you’ve been through a tutorial and maybe learned the dozens of verbs that are standard in all IF, what happens if you forget some of them? What is there in the interface to remind you?
So, yes. I’m no longer simply looking for a way to introduce IF in its current form to people. I’m looking for a way to fix what I have come to see as an essential defect in what IF’s current form is, while keeping as much as possible of its current charm and expressiveness.
Calling the parser a defective interface is a bit harsh. It’s an audience-limiting interface. Operating systems still have command line interfaces, and they provide a lot of power and benefit to expert users. But we don’t expect everyone to use them.
Calling the parser a defective interface is a bit harsh. It’s an audience-limiting interface. Operating systems still have command line interfaces, and they provide a lot of power and benefit to expert users. But we don’t expect everyone to use them.
Also: in the vast majority of cases, people only use them because they have to. I am glad to have Terminal, but I use only a handful of commands regularly enough to remember the syntax, and for anything else I have to read man pages. And there are all sorts of things I don’t know how to do and have to google.
This is very interesting and I feel like giving my opinion as a neophyte IF player whose favorite IFs so far would be Photopia, 9:05 and Lost Pig.
Auto-completion of the input is something I thought of as I was reading your post. The good thing, in my opinion, is that it would at least indicate the validity of what the player is typing. Pushing that idea further, it might not be necessary to even auto-complete… but rather pre-validate what the player is typing. Why let him press Enter on a command that is guaranteed not to lead to anything (that is, when the syntax is not correct or when part of it is not recognized). Computers have come a long way and should be able to immediately check the syntax as it is typed or at least *just* as typing ends and point out what is not understood… potentially offering a suggestion like spellcheckers do? (assuming it’s a typing error) Nothing would be revealed, but the player would quickly know if his verb is not even recognized… or if the noun is mispelled.
As a side note, I wanted to say that I played Gateway II and I never used the graphical list of verbs and nouns. I did appreciate the compass rose (unless finding the exit is a puzzle, it should be stated clearly) and liked the illustrative pictures if only because it made it easier to recognize where I was (I’m a visual person).
Finally, what about point’n’click adventure games? Lucas Arts games have (had?) a list of verbs that remained throughout the game (well, except once or twice, as a joke), yet it didn’t make everything utterly obvious thanks to the sheer number of items (inventory AND on site). I even remember the Leisure Suit Larry games allowed one to type actions in a very limited parser (you really could only input a verb). In that last case, it wasn’t that great because it was only used a few times, mostly for “secrets”, and it was not a tool that came to mind when looking for a solution). Yet, maybe there’s an idea there… something that needs refinement.
Doing a bunch of backreading and came across this comment from four+ years ago. Has anyone done anything with autocompleting verbs in parser IF by now? I know autocomplete is definitely very helpful when I’m using the console to customize/manipulate Source games. It wouldn’t even have to list all implemented verbs; as a primarily newbie-orienting feature, it could just draw from a list of the most common or important “starting-out” verbs for the particular game, which leaves room for exploration as well once the player has acclimatized (not to mention the idea about expanding the autocomplete list based on verbs the player has discovered).
Also, four years late to the conversation, but yes, I have definitely introduced people to parser IF using Dreamhold. However, it should be noted that this was a “playing together” kind of experience, where we shared the same physical space and I was there to do a live demonstration of what playing parser IF looks like in order to pique their interest (“I wanna try now!” is music to my ears). While this was a sustained interest — I was asked for a rec list later, and also for links/instructions to continue playing Dreamhold at home — it started out with an in-person, hands-on introduction. Also, the most interested person was a fellow bibliophile, so, you know. Might have been a factor.
Obviously, this is something I’ve been interested in for a while.
I think the article summarizes things well: the cursor prompt offers a significant blocker to both players and designers. Some easier way of introducing players to what they can do – guiding them through their interactions – is going to make a huge difference to the playability of IF.
One major thing is the error-reporting, as you mentioned. IF is unique in computer games in that it forces you to look at all your bad input to the extent of obscuring the actual game. It’s a little like having a 3d game put the word “oops” to a random point on screen every time you hit a wall, and then leave it there for five minutes — most newbie’s experience of IF is, within seconds, all the meaningful text is gone and all they can see is their own failure to play correctly.
My Angel used a separate window for reporting errors, as well as the player constructing input, so only valid, meaningful, worthwhile commands “graduated” to the main game output. I still think this is a good idea (regardless of the input method, really).
However, the layout of windows is only an artefact of the old-school Z-machine format. Modern text-editors are contextual and fluid and an IF game should be too. A modern interpreter should, say, allow typing at the current point in the output and then “fold away” errors so they are hidden once they are out of date.
I like the idea of a noun->verb structure for exploring commands, as your prototype does. Then I’d imagine it writing the successful command out into the main window to help show players what sort of commands work (assuming typing would be allowed at all.)
On the other hand, if the game didn’t allow any typing and all input was noun->verb then, hmm. I think it’s a good structure for exploring possibilities but it’s not the way I think: if I know that I need to open the door then “DOOR -> OPEN” feels a lot less natural than the usual “OPEN DOOR” : the verb here is the place where I start.
So that makes me wonder if a combination of Verb->noun selection interface (scroll through verbs that populate with suggested nouns) and a separate noun “explorer” (investigate what’s around and see what you can do with it) might cover both bases?
Perhaps one is integrated into the output (highlight the noun with your mouse and verbs appear – click to perform); the other is part of the prompt (hold mouse down to make verbs appear – follow them to receive relevant nouns – click to perform).
The nice thing about deep contextual menus is they are (hopefully) rich enough to discourage brute-forcing and encourage the sense that, if you imagine a command, you’ll find it in there. The main drawback I can see is that noun lists get very very big very very fast.
if I know that I need to open the door then “DOOR -> OPEN” feels a lot less natural than the usual “OPEN DOOR” : the verb here is the place where I start.
Sure — the prototype still allows typing standard-style commands. I wouldn’t want to give that up, because I find it the natural approach myself.
You may be right that it should echo the player’s correct commands, though; that would also address the issue that a lot of the standard library refers to “that” or “it” or “those” in a way that only makes sense if the command line is interleaved.
I still think deep verb menus are likely to be a challenge to build and navigate, but I’d be happy to play with a sample; I could well be wrong.
A modern interpreter should, say, allow typing at the current point in the output and then “fold away” errors…
Back in the very early days of IF — 1980 or so — there was a TRS-80 game called “Xenos,” a fairly well-done text adventure with a full sentence parser (not great by today’s standards but quite acceptable for the time). One remarkable thing about Xenos, though, was that its parser didn’t let you enter invalid input: if you typed in a sentence that it didn’t understand, it would flash a short error message by the offending word, something like “What?” or “Which?” and leave the cursor in the correct place to fix the problem. I was a little surprised to never see this approach ever come up in later, more advanced IF.
One more thing:
But we are trying to improve the parser to new heights because some novices has trouble in the very first turns of the game. Eventually, they will learn the kind of interface and enjoy the story. So, it really deserve the effort to improve the power of the parser? Just for a few turns? I think it is better to have a proper instruction sheet and in game hints about. Simply, a parser is a kind of interface, so a proper explanation of it will improve the experience for that novices.
However, maybe that improvement of the parser may arise with new forms of interaction… but this is just a wishful thinking, so maybe it doesn’t deserve the effort either. Well, at least I could imagine a thing where a better parser will help a lot: PNJ conversation.
You can see an non-parser implementation of the interface in a Spanish adventure of the 90’s:
Yeah, you loose something.
Very interesting — thanks for sharing the link!
Awesome article.
I used to love IF. I went to college with the intent of getting hired at Infocom (of course, they went bust at about that time…) I was thrilled to discover TADS and Inform. And I lost all interest in IF when I realized I was trying to make games that I could not persuade my wife to play.
I’m excited to see that people are looking for alternatives. The suggestions you make at the end of the article are similar to ideas I’ve had myself, but I didn’t have the drive as a lone developer to implement such things. I look forward to trying out your prototype, and eagerly await further developments.
My thoughts have been running along these lines as well — how to constrain the input system while keeping the rich worlds traditional IF can provide?
As most are aware:
Some old graphical adventures used a list of verbs to select, then you clicked on an object in the inventory or scene (and maybe again to combine objects).
Others let you right-click on any object and choose from an eye, hand, or mouth to examine, manipulate, or speak/eat it. A variation was right-clicking to cycle the cursor through those icons (some included a Walk icon and others), and whatever icon was showing would be performed on any object clicked on in the scene or inventory.
Flash escape-the-room games just show your inventory, and everything can be solved by directly clicking the scene, or clicking an inventory object and something on the screen or another inventory object to use them together. Some also have an option to examine an object more closely, manipulate it, and use other objects on parts of the object.
These formats would certainly work on a highlighted text — click on a list of verbs then a highlighted word, or just click on a highlighted word and choose from a context menu that floats above it then disappears when you select.
I’d also considered a single click for EXAMINE and a double-click for TAKE/MANIPULATE/TALK. A one-second mouseover could also be a third verb.
One could argue that these interactions aren’t very granular, and that wanting to taste the red fluid with the mouth icon only to get “I can’t talk to that” is also a problem.
You mentioned the issue of acting on objects that aren’t in the text on screen at the moment. I came up with a prototype that works fairly well: the room description stays visible at the bottom, and the results of your actions show in bold above it. The room description changes as you manipulate objects in the room.
You and other posters mentioned the context-sensitive “auto-fill” command line. It seems like it would spoil some puzzles, like type in DOOR and see BURN DOOR come up right away. Perhaps that means we should also be writing more literary works that are not about finding clever verb-noun uses, but about using richer but limited actions in compelling ways to influence characters and plot.
Excellent ideas, I think. I can imagine limiting the parser exactly as you suggest being an excellent system.
The most intuitive IF I can recall is all by Pacian. I don’t think it’s at all a coincidence that they are also usually the easiest to enjoy (whether they are the best IF or not being an entirely different question, though I do love them.) I’d like to polish his approach into a more elegant system – if I knew exactly how that should be done.
I’d like to polish his approach into a more elegant system
By “his approach”, do you mean specifically the keyword system in Walker & Silhouette?
Excellent article, Emily.
A little caveat, or thoughticle: I think that the use of guess-the-verbs can go beyond TWIRL MUSTACHE and other little optional responses. (Though I admit that while I was reading I was thinking about the use of xvff in Walker and Silhouette.) There are some moments in great IF that get their impact from the player’s thinking of an option themselves without having it presented for them. Most of these are puzzles — as in “Spider and Web” — but “Photopia” and “The Ebb and Flow of the Tide” both have moments that get emotional impact from the player thinking of a new verb to use. And that impact would be entirely blunted if a little alert popped up saying “New verb unlocked!”, and even mostly blunted if the verb showed up in a drop-down menu in a place you might not have thought to look for one.
This could also be used to set up moral choices. Think about using something like the “No Russian” level from Modern Warfare 2 as part of a serious moral narrative — you’re part an armed group, you start fighting bad people, but the things you do get more and more shady until eventually you’re in a situation where you’re just called on to mow down innocent civilians. And at this point it becomes an option to shoot your comrades instead of the civilians. Wouldn’t that be more powerful if the player had to think of “shoot comrades” out of the blue, rather than having it show up as one of the options? In the case I’m thinking of you could just enable shooting your comrades at any time, with it usually leading to a fail, but not every case might be easily treated that way.
Someone, I think over at In the Company of Grues, said that the difference between CYOA and IF is that CYOA is about figuring out what you want to do and IF is about figuring what you can do. Figuring out what you can do can be a real pain, but I think it can open up some greater depth that might be hard to get to without some sort of open universe of commands.
Well, the >TWIRL MOUSTACHE (cool thing you can’t believe the author implemented) along with the sensation of coming up with a solution to a puzzle in everyday life and racing back to the game to try it out are the two things that make IF the best genre of game, IMO. I don’t know that I’d personally want to create a game that robbed the player of a chance for either of those two things. But I also believe there’s grammar in all kinds of games – the gun that shoots nuclear missiles in Fallout 3 being unable to take out the wall of a building is just as bogus as a text game not understanding an adverb.
But, of course, there’s room for both types of text adventures. I coincidentally restarted Spellcasting 101 this weekend because I finally wanted to solve the last two chapters and see the ending. I like the layout, which is similar to the Legend games linked. But I’ve never clicked on a word in the list. Making games with that UI is totally cool, though – people aren’t going to suddenly stop making Infocom-style text games and even if they do, there’s more games in the archive than anyone can play. The new UIs are exciting and look sharp.
I don’t think this would have to mean that you could never get stuck or could never have a puzzle whose solution you think of later. Much of the time the challenge of coming up with a puzzle solution is in realizing that a given command will have an interesting result, not that it’s something you could type at all. (I think this applies even to That Puzzle in Spider & Web: the grammar isn’t secret. It’s just realizing the correct moment and method of application that makes a difference.)
Well — spoiler rot13ed: One of the things about That Puzzle is that lbh unir gb oernx n ehyr gung jnf rkcyvpvgyl fgngrq va gur Nobhg grkg. I really can’t think how to implement it in a system like Jade’s, where it seems like you’d have to present all the relevant choices to be fair.
Also, hiding the solution in a forest of uninteresting commands could still be a problem. I guess the problem under discussion is “I don’t know how to enter a command at all,” but “Every command I enter yields an uninteresting error message” seems like it’s still a problem. Some frustration may be necessary, because the pleasure of solving something is the pleasure of overcoming frustration, but a raft of “You jump on the spot, fruitlessly” messages doesn’t seem like it would be that much better for the novice than a raft of “I only understood you as far as wanting to jump.” — Though here we may be getting into the limits of the world model rather than anything to do with the parser.
hiding the solution in a forest of uninteresting commands could still be a problem. I guess the problem under discussion is “I don’t know how to enter a command at all,” but “Every command I enter yields an uninteresting error message” seems like it’s still a problem.
That is still a problem. But there’s a lot of territory between “puzzle solution” and “boring output” — in fact the majority of what many IF games print when the player knows how to play. I’m talking about descriptions, sensory reactions, standard manipulations (open/take/drop/switch on/etc.); mechanical systems that you fiddle with and get feedback on for quite a while before you work out how to handle them right; all that good stuff. A non-trivial percentage of good IF puzzles involve using totally obvious verbs to create a chain of actions with a non-obvious result. Take the pillow, drop it on the floor, put the vase on the pillow. That sort of thing.
Knowing the verbs — and even having a pretty short list of verbs that matter — doesn’t keep the player from having to understand the simulation in those cases.
Also, re. spoiler:
vg’f orra n juvyr fvapr V cynlrq, ohg vfa’g gur qrny gung gur nobhg grkg gryyf lbh bayl gb hfr Lrf naq Ab va pbairefngvba? Ohg nethnoyl jung lbh fnl vfa’g cneg bs gur pbairefngvba; vg’f na bcgvba gung’f nyjnlf orra cerfrag va gur tnzr. Gur gevpx bs ernyvmngvba vf zber bar bs ernyvmvat jung’f va fpbcr ng guvf cbvag, ernyvmvat gung lbh pna tvir gur ibvpr pbzznaq engure guna nafjrevat lbhe vagreebtngbe.
A non-trivial percentage of good IF puzzles involve using totally obvious verbs to create a chain of actions with a non-obvious result.
Very true. I guess I’m worried about restricting IF to the obvious verbs, though; I hate to agree with Pudlo but the “wander around pushing buttons and picking things up and using them and sometimes giving them to people which almost never works” paradigm is very constraining. — Not to say that people can’t do great work within that paradigm, just that it’s a constraint that needs to be overcome.
You can introduce new verbs that can be broadly attempted but that usually produce unproductive results — like “insult” in Raising the Flag on Mount Yo Momma. And, well, maybe that is the solution. Though the new verb in the menu becomes more like an object that you know you have to use somehow, and the puzzle is then figuring out the right way to use it. And I start to wonder whether it might not be more interesting to go to “USE OBJECT” — instead of chaining together the same actions with different objects, have an object with an unexpected use in an unexpected place, but don’t make you guess which verb you need to type to use it. Which seems to take us ever closer to point-and-click games in text.
FWIW I usually don’t much like mechanical systems puzzles in IF, like the stuff at the beginning of Slouching Toward Bedlam. Visual media do a better job at giving me feedback there. (In STB’s case, I completely forgot that a crucial button was there, because the description was so elaborate — wouldn’t have happened in a graphical medium.) But I may not have played the right games — do you have any good mechanical systems games to recommend?
About that puzzle: This contains a massive spoiler. Don’t rot13 unless you already know the solution to That Puzzle in Spider and Web (even if you don’t care if you get spoiled, it won’t make much sense if you don’t know).
Lbh’er evtug gung gur Nobhg grkg znl or yvgrenyyl gehr, nygubhtu vg’f fgvyy qryvorengryl zvfyrnqvat (abg n pevgvpvfz). Ohg V qba’g frr n jnl gb vzcyrzrag vg va n flfgrz jurer gur vachg cebzcg pbzzhavpngrf gur nssbeqnaprf bs gur flfgrz. Guvax nobhg na vagresnpr jurer gur pbzzba ireof ner pyvpxnoyr. Vs lbh qba’g tenl bhg rirelguvat ohg “lrf” be “ab” va gur eryrinag fprar, gura lbh nera’g pbzzhavpngvat gur nssbeqnaprf, ner lbh? Gur cynlre jvyy fheryl gel ybgf bs fghss gung jba’g jbex orsber ernyvmvat gung “lrf” naq “ab” ner gur bayl guvatf gung jbex, naq jvyy trg sehfgengrq — gubhtu creuncf sehfgengvba vf nccebcevngr gurer. Ohg lbh pna’g unir “gnatb” be “jnygm” fhqqrayl tb hatenl rvgure.
(Fvapr V’z gnyxvat nobhg guvf chmmyr, znlor V fubhyq eryngr zl rkcrevrapr. V’q orra pbafhygvat n jnyxguebhtu — guvf jnf n ernyyl cbbe pubvpr sbe nobhg gur sbhegu be svsgu tnzr gb cynl, naq V’z hfrq gb cynlvat nybat jvgu jnyxguebhtuf sbe rfpncr-gur-ebbz tnzrf juvpu bsgra erdhver fbzr guvatf V svaq cerggl vapbzcerurafvoyr ng gur ortvaavat, naq gurer jnf ab jnl V jnf tbvat gb svther bhg gung lbh unq gb whzc gb trg gb gur tnc va gur prvyvat engure guna chfu gur obkrf bire gb vg. BX, fb V tbg gb gur vagreebtngvba ebbz, naq V jnf yvxr, “Nun! V org gur obzo vf fgenccrq gb gur obggbz bs gur punve.” Naq V pbhyqa’g erzrzore juvpu jbeq ghearq vg bss naq juvpu jbeq ghearq vg ba. Gung jnf sehfgengvat. V qba’g qenj nal zbeny sebz gung.)
I obviously haven’t proven this myself, but I think it would be completely fair to have actions in the actions menu that usually produced interesting but non-functional text and then sometimes produced valuable results. The player never forgets what the word is or that it’s available, but still has to apply some reasoning about when to use it.
Re. mechanical systems: I was thinking about machines a little (I also disliked the Slouching example, because it was needlessly obscure and the descriptions hard to understand, but I did like e.g. the orrery in Dreamhold); but I was also thinking of things like simulation-rich puzzles where you need to put a heavy thing on a scale but any heavy item in the game will work. Or, for that matter, systematic puzzles of other kinds, like the magic language in Suveh Nux. Enchanter-style spells would work too: you get a new spell verb added to your menus when you discover it (no need to fuss around with the spellbook), but it’s still up to you to realize in what cases it’s worth casting.
I guess what I’m saying is that I’d divide up responses to IF input thus:
1) I didn’t understand that at all.
2) That was a default behavior that the author didn’t plan around, so you get a default library response. (NB: this default library response may actually be buggy, as when someone types JUMP in a room that’s supposed to be in midair or whatever.)
3) Action achieves nothing, but it’s interesting. (Sensory verbs; actions that don’t solve puzzles but help you understand how the system works.)
4) Action achieves something standard, but it’s not interesting. (Take, drop, open, switch on, etc., when they’re acting in their default way.)
5) Action achieves something non-standard and interesting. (Puzzle solutions that take the world to a new state.)
3, 4, and 5 are all useful and all count as affordances of the system, I’d argue. 2 is less useful, so we wouldn’t recommend those actions to the player, though we might still choose to understand them when typed in, giving some kind of bland response.
1 we want to avoid entirely, unless the player intentionally is typing gobbledygook.
I was also thinking of things like simulation-rich puzzles where you need to put a heavy thing on a scale but any heavy item in the game will work.
I suppose you don’t want to name Metamorphoses here, but that’s one thing I was thinking of. I was going to say that I don’t remember too many multi-step puzzles there, but there’s one. Suveh Nux (which was also one of the first games I played) didn’t work too well for me; I had to go all the way into the hints to figure out gur chmmyrf gung vaibyirq hfvat gvzr-qrynlf va beqre gb fgnpx fcryyf; part of that was me just not understanding the feedback I was getting. (And once I read those hints I had a fine time with the rest of the game.)
I’m still kind of worried about emphasizing clockworky kinds of puzzles any more than is already done; Amanita may make more entertaining clockwork devices than anything that can be done in text, because you can see the clock working. But I can’t honestly say that this concern is inherently connected to the open parser.
I’m still kind of worried about emphasizing clockworky kinds of puzzles any more than is already done;
No, but really one of the things I think this would give us is a way to more easily introduce verbs that are non-standard to IF in general but important to this particular game. So there could be social manipulation activities or other similar kinds of things, which in the current system might be hard to teach the player. (I really want a way to get away from everything being about opening boxes and turning on machines.)
Yeah, true enough — something like “insult” in Raising the Flag on Mount Yo Momma could be implemented pretty easily in that sort of system. (Actually I think RtFoMYM could translate to a graphical adventure very smoothly.)
But RtFoMYM is definitely a game where the NPCs are locks you need to find the right key to. I’m a little skeptical about social verbs like “blackmail,” one you’ve mentioned — it seems a little high level, like it’d be more satisfying to do the thing that amounted to blackmail instead of waving your blackmail wand.* Might depend on how clear it was that you could blackmail the character now.
But we’re pretty far afield from the parser, because you could do what I’m thinking of with “Show incriminating photographs to culprit/ask culprit for money.” So I’ll give it a rest, on this thread at least.
*I had this reaction to “kill” in at least one game — “I need to unlock and open every door by hand, but KILL HIM works?” Though that actually was a guess-the-verb that would’ve been solved with a verb menu…. though again, it’d have been disconcerting to have “KILL” presented as the option right away.
I don’t know. I agree with most of the article, but still feel a real love for the openness of the parser. I think, in general, that a cheatsheet – a minimum list of verbs required to complete the game – would be helpful. And the shorter that is, the better. But for implementation . . . I don’t know.
When I play, I try lots of things that probably aren’t implemented. I pray. I swear. And if given the concrete limitations of my actions, I would miss that. It would close the world somehow.
On the other hand, it would be nice in some way – hunt the verb is no longer any fun. I do think that tutorials should be a semi-standard feature, though, and training expectations is important.
Another interesting game in this context is Treasures of a Slaver’s Kingdom, where there is a very, VERY short list of necessary verbs — REGARD, SEIZE, USE, PARLEY, and ASSAIL, plus directions of travel. But this works largely because it condenses down the action space so that for any given object, there’s only one sensible kind of use. Most NPCs are really only responsive to one of PARLEY or ASSAIL, too — they’re either friendly or they’re attack-fodder.
Of course, I have no data about novice use of this game and how difficult they found it.
As another fan of “discovered verb” puzzles (let’s clearly distinguish this from “guess-the-verb” bugs, please!) and the idea that the verb list should be driven by the story and perhaps not not fully known in advance, I think the first step may be to stop claiming that the parser “understands natural language”. As you say, this is a lie. It’s a misconception founded in decades-old advertising hype.
In reality, the parser understands Caveman English: “Thog, get rock”. This should be made clear to players who may already have unfair expectations – or who might, instead, have *no* expectations. (For every first-time IF player who types full sentences and is frustratingly misunderstood, I bet there’s another who just doesn’t have any idea what to type at all…until somebody tells them to “just type anything” or “type in English”.)
In fact, Caveman English is a *better* interface than English for commanding a text-world avatar. “get rock” is an efficient, clear way to invoke an action. “I pick up the rock now.” is almost three times as long. With just a little practice, standard IF commands are much faster and more fluid than more natural sentences would be. Caveman English is a better tool for this job; I recommend we skip the hype – in fact, actively discourage the misconception – and clearly acknowledge this as a feature, not a bug. (While continuing to improve the parser’s response to typical player utterances.)
Personally I’d like to see more experiments in the “Dreamhold” direction: the narrator giving extra out-of-world coaching to the newbie player specifically – e.g. by detecting floundering – with the goal of teaching them how to play standard IF.
Like you said: “indicating the affordances of the system” is key.
I think it’s a bit unfair to say “even fairly difficult console games usually guarantee that at the beginning of the experience it’s just about impossible for the player to do something wrong”. It’s not that a newbie can just dive in and play these games with no trouble. Rather, many of them open with extensive tutorials (often straining the sense of immersion, as in Halo when in-game characters ask you if your y-axis should be inverted – not you the player, but you the player character!). And real newbies are likely to spend a few moments bumping into walls and staring at their shoes. Or trying to touch the Moon, for that matter.) They’re just not leaving a paper trail while they flounder helplessly. But I think the lesson here isn’t that IF controls are harder to cue. Graphical games bend over backwards to explicitly train players in their (much more limited) control schemes. The lesson is that IF games may need to open with tutorial scenes or the equivalent.
Jon Ingold’s comment about the meaningful text scrolling away to make room for an error log seems like a much more important IF-UI concern than the parser prompt! Good point, Jon!
I think it’s a bit unfair to say “even fairly difficult console games usually guarantee that at the beginning of the experience it’s just about impossible for the player to do something wrong”. It’s not that a newbie can just dive in and play these games with no trouble. Rather, many of them open with extensive tutorials
Well, yes — the tutorial is part of what I meant, though. And even when the extensive tutorial is over, there is very often a range of feedback to help remind the player of what he can do, and how.
I think it really depends what kind of game you want to make.
The IF parser is exceptionally good at depicting a certain kind of person (an amnesiac suffering from something between autism and Asperger’s, along with a magpie’s obsessive collecting), in a certain kind of physical space (broken into roughly equal-sized rooms), doing certain kinds of things (manipulating mechanical things, usually with fine motor skills, to make them open; sometimes manipulating people, as if they were mechanical things, to make them open).
In essence, it is good for telling stories about antisocial, compulsive fiddlers who fiddle their way into some sealed-off sanctum.
That’s why Metamorphoses or Dreamhold or even Spider & Web and Trinity work so well.
It is much less successful when the story involves different heroes, spaces, or goals.
One thing that strikes me as interesting is that, from a mentality standpoint, the hero of almost any IF would fit just fine as the hero of any other IF.
I wonder if the popularity of the parser — or lack of sensitivity to its problems — results in part because members of our community are, generally speaking, probably further along the autism/Asperger’s scale than most (maybe a standard deviation). Indeed, the very mindset necessary to make an IF world of separate rooms and endless enumerated objects and scarcely any human interaction is the not so different from the mindset of the kind of characters who inhabit these worlds. (What empathetic person would design a maze of twisting passages, all alike? What social person would navigate it?)
The problem is that most gamers, although still probably inching in the Asperberger’s direction when compared to the general population, are not as obsessed with fiddling and measuring and counting.
Those players just don’t think, “wake up; exits; out; look; exits; enter bathroom; look; x soap; get soap; turn on water; lather hands; put soap in dish; rinse hands; dry hands; x hands.” They just get up and do all that on autopilot while thinking about the NBA finals or whatever. I’m not saying that most IF creators/fans are at the point of starring in As Good as It Gets; but they’re far enough along that they can enjoy roleplaying that personality.
I think Emily’s suggestions would go a way toward attracting a wider cross-section because CYOA and Visual Novel games *are* able to tell stories that involve bold actions, natural conversations, non-confined spaces, and so forth. But I think you would thus destroy a niche game that appeals to a peculiar subset of the population. It’s not clear why that peculiar group should destroy the very kind of game that they like simply to make people who are likely already happier than them even happier still. . . .
It seems like autocomplete ought to work. It’s familiar from search engines and mobile phones, makes input significantly easier (particularly on mobile phones), but the game can avoid giving away puzzles by not making suggestions until it’s clear you have something like that in mind. There’s a lot of room for creativity in tweaking the algorithm for deciding when certain suggestions show up.
Some IF terps for mobile devices do allow that, but I’m not sure it does enough to tackle the “I have NO IDEA what to do now” problem.
That suggestion gets us part of the way to the “TWIRL MOUSTACHE” problem, but not all the way there. Or rather, it only works for optional Easter eggs like “TWIRL MOUSTACHE,” not when you need to do something unusual to advance the plot. Think about the example from Photopia (you’ve played it, right? If not, you should; you won’t run up against a wall); there’s a word that could be made clickable there, but it would bizarre to have it clickable but not highlighted, and the whole point is the apparent discovery of something new to do. (Which the game makes easy to do.) I’m just not sure that there’s a way to do that without a seemingly open interface.
These examples are very hard to pull off, though. You have to set up certain expectations for the player and then give them a fair clue that they have to violate those expectations while still making it seem to be their own idea. A lot of games say something like “You could TWIRL your moustache” to let you know that there’s a non-standard verb in the offing, which I think is a good idea in general, but obviously removes the serendipity.
There’s a parallel to point-and-click games here. (I’ve only played Flash versions, not the old classics.) Some of them have the cursor change when you pass over a point of interest, some don’t. The ones that do are generally more successful — when they don’t there’s a lot of pixel-hunting, which is the IF equivalent of guess the verb, in that you may think you want to interact with something (say, look at the left side of some desk) but not know that you can only look at the left side if you click just there; when you click somewhere that you think should work, but doesn’t, it leads you to think that you can’t do it at all. There are some games that do something maybe equivalent to your suggestion — the cursor changes when you mouse over a hot spot, but the hot spots can be pretty non-obvious. This usually doesn’t work for me — I’m thinking of “Daymare Town,” of which a commenter and JayIsGames said “Making progress in this game invariably means careful mouse-sweeping of each screen.” But other players seem to like it.
FWIW the moments in point-and-click games that have an impact like the Spider and Web example are in Trapped Part 2: The Dark, whose cursor does change. But you have so many objects that there’s still a lot to try out, and there’s a wham! moment when you realize “Holy cheese, I have to do that?” Which suggests maybe we can get this effect with highlighted verbs and nouns, as long as there were enough that the player wouldn’t just try to plow through. In the example I used earlier, “Shoot comrade” would work even if “Shoot” and “comrade” were part of a limited set of words you’d been using.
The Photopia / Spider and Web examples are often brought up in discussions of why we should keep the parser as is. It’s fair enough – they’re great demonstrations of effects you can get from a “hidden input” interface.
But the real question is – what is any particular game trying to achieve? And when we discuss generalities like this, what are we trying to achieve? If we want Photopia-moments then, yeah, the parser’s a good way to do – but at a significant cost, as noted by many beginners (and those who never get further than the second prompt of any game.)
It’s worth remembering that the Photopia/S&W examples were examples constructed *for* the existing interface. If we vary the interface we may lose some capabilities; but if it’s a good interface we hopefully gain others.
I’d argue that we should be aiming for comparable moments of “insight and discovery” but across a medium-term rather than on a command-by-command time-scale. Let the player discover things through their actions, plural.
You’re definitely right that there’s no sense in a one-size-fits-all approach. People might want to write games that work for people who are used to parsers. (FWIW, the JayIsGames review for Daymare Town, the game I criticized above, said it was only for advanced point-and-clickers; so other genres have an issue with getting used to their grammar too.)
What are you thinking of as examples of the medium-term time scale? Is it something like what happens in Byzantine Perspective? Or something like, you discover that chaining commands together in a certain way has an interesting effect? It seems like an admirable, but different effect to me.
“That suggestion gets us part of the way…”
Absolutely – when I said ‘a cheap trick’ I mean just that. I’m not suggesting it’s a full solution! :-) As Jon points out below, any move away from hidden-input will lose something in translation, because these effects are an explicit reaction to its advantages and limitations.
On guess-the-verb and pixel-hunting; I guess the ideal would be that you have a hierarchy of degrading complexities, where people who want guess-the-verb can still do it but there are ways through for the rest. So the hardcore IF / experienced point-and-clicker zeroes in on a good guess after a few attempts, and the highlighting doesn’t distract them. A more casual player gets a benefit from the highlighting or the hot spot. Someone who’s stuck can text-sweep mechanically, or hold down CTRL to get sonar on hot spots, or take advantage of a hint system. But each lower level of complexity is tucked out of the way of the rest, most of the time. I don’t really think you could get the best of all possible worlds this way, but you could probably satisfy a wider audience.
The thing I think is important to understand is that creating a highly usable user interface is not a random occurance. It is an iterative research process that uses emperical results to improve the user experience. To create something that 100 or 500 people think is nice is relatively easy. To create something that thousands or tens of thousands or millions of people like requires a scientific and iterative effort.
Such testing gives you an interface that is highly usable for those represented by the group you tested. There’s no single IF interface that will be best for everyone.
Regardless, we can learn from best practices used by other software interfaces. Other interfaces don’t use the same window for input and output. Other independent games don’t require players to install an unfamiliar runtime engine. Other interfaces benefit from having toolbars, hypertext, and auxiliary information panes.
Alan Cooper’s _About Face_ recommends designing interfaces for “perpetual intermediates”, so the users can take off training wheels once they get started, but also aren’t expected to know everything the system can do. Command line interfaces can be very powerful, but they are expert level interfaces. I don’t think IF is a niche because people don’t like text; I think it’s because they have more fun things to do than become expert IF players.
I agree. But I believe we could figure out several standards that encompassed many people and then figure out ways to write our games so they can be accessed in any of those forms. One of the reasons I get so frustrated with the current VM+IO model is that it makes this process very difficult, if not impossible to work through. Until everyone realizes that we can’t move forward until we rip the UI out of the game, we won’t progress.
I don’t think anyone is suggesting doing away with traditional IF, nor will it disappear as long as there are people who enjoy reading and writing it.
However, standard IF was designed around certain technological constraints. Today, we’re not limited by technology (NLP and similar puzzles aside), we’re limited by the user, who has come to expect different things from what he/she plays and reads.
In the 80s, thousands of kids might not have started reading when they did if it were not for trying and liking CYOA books. And thousands of people might not have been very interested in computers, except for Adventure, Zork, and others.
People still read books, and even pay full price to read texts on their Kindles and iPhones. The casual game market is booming on computers and mobile devices. Production and distribution has never been so easy or cheap, and even making money from micropayments or ads is becoming very feasible. Interactive Fiction (of some kind) seems an obvious market at that intersection.
“What kind of interactive fiction do I want to create?” If the answer to that are similar to previous ones and can be played with a parser, then IF will keep looking like it always has, and that’s cool for those who answered that way. But if, like Emily has mentioned, there’s an interactive story you want to tell and several attempts have failed with the traditional parser, then find something that works, a medium that fits your story.
“What kind of interactive fiction do consumers want to read (and buy)?” Apparently, the answer to that for most people isn’t traditional IF or CYOA. Again, it’s time to find something that fits the story. I think interactive stories could be popular (again), we just have to tell them in a way that gets heard.
I think it’s worth noting that a form of CYOA lives on in very mainstream games: BioWare’s conversation trees, e.g. Dragon Age. I have mixed feelings about this: sometimes one of the options really nails what I wanted to say, other times none of them work for me, and I really just want to say ASK ALISTAIR ABOUT DOG.
Many of these suggested interfaces are not mutually exclusive, or even necessarily “interfaces” so much as interface features that can be mixed and matched. One example: Ingold’s suggestion of folding-up (or deleting) parser messages works well with your (Emily’s) DOOR example: What would you like to do with the door: opening, knocking, listening at, or breaking down? Disambiguation messages are easily doable and can be folded up afterward.
Similarly, enumerating the most fruitful actions at a point can likewise be done: a LIKELY command displays a short list. LIKELY can sit in the same work as the above verb disambiguation and transcript-neatening. A work can allow auto-LIKELY as an option, and optionally disallow typing-in command prompts. Again, these are all interface features, not interfaces themselves.
Hyperlinks and other mousing-around work with all of the above, even simultaneously.
So I don’t see that’s there’s much choice to be made here, especially as some features are more useful in some parts of a game than others. A usual example: CYOA in dialogue but typed commands elsewhere. Another example: enumerated choices early in the game, until the player is sufficiently invested in the story (and empowered in the gameplay) to segue into the wide-open parser.
I had blogged about using certain non-imperative sentence modalities as input, specifically the words could, would, and should. Language as input is potentially very powerful, and while I recognize utilizing it in a design requires a heck of a lot of thinking-through (like most innovations), I believe we should concentrate our energies there. Throwing up our hands in the air and saying we don’t need language input [because videogamers don’t think they need it] is just crazy talk.
I enjoyed graphical adventures, with their much-more-limited set of verbs. Especially those which had a few verbs which were almost explicitly useless and existing only for flavor, because they allowed some of the optional exploration experience that good parser-IF has. (The “smell” and “taste” icons in Space Quest. I don’t recall if they EVER did anything useful, but they were entertaining to poke at.)
I’ve enjoyed a lot of different possibilities in games, including explicit lists of nouns and verbs.
But I wouldn’t want all games to move towards the high-accessibility standard. Part of the joy of parser IF is getting in sync with it… feeling that you understand, and are interacting with the game on an equal level. The game gives you text, you give the game text. That balanced level of interaction can’t really be achieved in other video games. It’s still an illusion in many ways – or a Facade if you will (Which I still haven’t played and ought to) – but it’s something special to the genre.
There’s a lot of information about “how to play a text adventure” that old hands have digested over the years, and it takes a good bit of work to train new players to the same standards. But the same can be said for a lot of videogames. There are genre conventions that are incredibly obvious to old hands and very confusing to newcomers. Some games build in tutorials and work you through learning the skills. Other games expect you to have played some other games first.
Has anyone run a Tutorial Comp? Something for games whose sole purpose is to take a newbie and train them in the tricks of the trade (in a fun way) so that they can come to grips with more advanced entries in the genre? I’m pretty sure there have been calls for easy games good for beginners, but I’m not sure how many of them really thought of themselves as performin the role of the interactive tutorial and starting from scratch with how to look and move.
Has anyone run a Tutorial Comp?
Well, sort of. There was the Beginners’ Comp:
http://ifdb.tads.org/search?searchfor=tag:IFBeginnersComp
…and Sleeping Princess and Mrs. Pepper’s Nasty Secret are in line with what you describe, more or less. There are also Nine Points and Dreamhold, which are attempts at other, non-compy times to accomplish the same thing.
i’m just beginning to read the article, but I thought you’d like to know that the first time you mention “NLP” in the text it isn’t clear what it stands for. (Well, at least to me.) Cheers.
I’ve added a link from the abbreviation here: http://en.wikipedia.org/wiki/Natural_language_processing
Interesting topic.. got me thinking about command lines and worlds with special cases.
One of the things that makes command-lines powerful in computer interfaces is the ability to chain together commands in novel ways (e.g. in Unix, listing files, and piping the results through a filter).
Guess-the-verb still exists (because nobody knows every possible command), but the user can (theoretically, at least) develop facility with all of them independently – anything can be filtered. There aren’t any special cases where the commands suddenly behave differently. All of the possible outcomes emerge naturally from combinations of commands.
The game-world analogue for this is a physical simulation – given a number of universally available options (walking, lifting things, letting things go, throwing things), and all outcomes emerge from combinations of these, in the context of the universal world rules (e.g. mass, gravity, the rigidity of objects, friction).
A given puzzle (e.g. press a button high up on a wall) might have many solutions – stack some boxes, throw a ball at it, etc., and perhaps only one or two of them were anticipated by the scenario author.
Once you get to a certain level of facility (e.g. you’re no longer trying to pick up the air, or ‘throw’ when you’re not holding anything), every sequence of actions does at least have an outcome. (Though you might not like it!)
In CDLIB (MUD software – I’m not sure how this compares with Inform), the situation is quite different.
While there are global verbs, like ‘north’ – many verbs are made available to the player by relevant objects. I can’t ‘smoke’ anything except a cigarette – I can’t ‘smoke twig’. (Unless I’m carrying a cigarette, in which case I might be told ‘You can’t smoke that.’) I can load my sling with pebbles, but not a stick of chalk.
Successful smoking and sling-loading are special cases, outcomes that were pre-planned. Many attempts to invoke these concepts result in no outcome at all.
Pocket interactive fiction occupies a very awkward position, to my mind. Immersion requires the promise that you could do anything, but specifying the flammability of every object in the game world is a crazy investment when all you want to do is let the player enjoy a post-coital toke in scene six.
One complicating factor is that a lot of the actions we wish to support in IF are very high-level. Smoking consists of numerous small actions (open packet, get cigarette from packet, put cigarette in lips (not mouth!), get match from matchbox, rub match on matchbox, touch cigarette with match, shake match).
Another complicating factor is the highly idiomatic nature of language – it only makes sense to ‘smoke’ a handful of things, but it’s immersion-breaking if we simplified and forced users to type ‘consume cigarette’.
So we resort to writing special cases needed to make the game go… but then we’re left repairing the immersion by writing endless witty no-outcome responses to unsupported actions like ‘smoke chalk’.
The best IF is that which guides you through the story, prompting decisions, choices and responses that develop the narrative.
The touch moon problem only occurs if the player’s bored or just wants to test the parser. It’s not something I’d be particularly concerned about.
All fiction is a lie and relies on some degree of complicity between reader and author. For me, this play is one of the strengths of IF. No–one genuinely expects a “realistic” experience, but we like to pretend we’re interacting freely with the author’s world.
The answer to your problem lies (I think) in the quality of the writing, particularly narrative and logic, rather than the invention of new formats. It’s actually pretty hard to write well, so it’s perhaps unsurprising that lots of IF falls apart at the seams.
That’s sort of funny actually. I had been thinking about the same problem over the winter, and I made a tiny prototype IF game in February with an interface very similar to what you described in your post:
http://www.user00.com/my2iu/games/stolenhearts/
I was going to explore this interface direction further, but, not having any experience with IF game engines, I wanted to study how existing IF world models worked first to see how they would be adapted to parserless IF (conclusion: much of the complexity of IF world models comes from needing to support arbitrary user input–i.e. touch the moon–but this problem goes away once you remove the parser, meaning that you can use a simpler world model and focus more of your programming effort into the game).
Unfortunately, I then ran into writer’s block. I’m more of a game mechanic person than a plot person, so I couldn’t really think of any particular story or game that I wanted to write in IF form that didn’t require a lot of additional innovation in IF gameplay mechanics. I’m hoping something will come to me before the IFComp though.
Would it be plausible to use the command prompt as kind of a movie director, or conscience? Changing the text before the > depending on certain factors?
For instance, entering a phone booth would make the prompt turn into:
Sandra asked you to call her>
or
Dial 0 for the Operator>
I’m still new to writing IF, which is why I ask about plausibility – but I think I might try this out with my current pulp adventure. Release one version without it, and then implement it for the second.
This is a bit late, but I posted some mock-ups of interfaces without a command line, and I’m hoping for input from the community.
A couple of thoughts on this…
I agree that a parser is intimidating to those that are new to IF, however as stated the beauty of the genre is being able to do ‘anything’.
These days I think many people are used to more ellaborate UIs than a command prompt. That being said it is something that the majority of us are used to, as many people text, instant message and e-mail among other forms of communication. The difference being there is another human being on the other end being able to interperate what it is you say. However there is slightly more of a communication barrier when one of those is a computer. So to me I think a user-friendly IF interface would be a cross between MSN and a ouija/spirit board as this would give the user the ability to interact via icons or give explicit commands using the parser.
The biggest issue of course is still design and the interface would need to be unobtrusive to the work, elegant and instantly understandable but I believe that such a design would be possible.
“I agree that a parser is intimidating to those that are new to IF, however as stated the beauty of the genre is being able to do ‘anything’.”
But you can’t do “anything”. You can only _try_ “anything”, usually to little or no result. That’s where the frustration comes in, especially when you look back at your transcript and see that many, many of the game’s responses are variations on “that didn’t work”.
And there I was trying to be careful with what i said, you’re totally correct, you can only try.
I truly believe that the UI is the most important thing to the survival of IF, especially with the growing popularity of touch screen displays.
“Yet another approach would be to offer something that looks like TADS 3/Alabaster-style conversation hints, only for all turns. Unfortunately, that disrupts the flow of the rest of the prose with a lot of mechanically generated content, and with options that will look a lot less diverse than conversation options generally do. I don’t imagine that the results of that would be acceptable.”
It’s not obvious to me that this would be unacceptable.
In Blue Lacuna, every object has a default verb, usually “examine.” Adding a list of verbs to the end of “examine” descriptions doesn’t seem too disruptive, as long as you only saw the list on examination.
Like this:
A large heavy *cabinet* stands at the far side of the room.
A *manticore* with no teeth is staring you down.
You can also see a *table* (on which is a *bowl* (in which is a *poison-fruit*)) here.
– CABINET
The *cabinet* is made of heavy, reddish wood, with round bronze *bosses* on the doors.
(You could *open* the *cabinet*.)
I think it might be good to emulate some of the better programming IDEs- perhaps as you type, words could get syntax highlighting, so you can see before hitting enter that the verb you typed isn’t recognized or that it doesn’t work without a noun, just as some IDEs will let me know a variable is undeclared or a command is missing a variable without compiling.
After all, playing an IF game can be compared to writing a program to ‘solve’ the game scenario, and a play-through actually is a program to be run in the game.
Fascinating discussion. I’ve only just stumbled on it. (I really ought to get out more.)
My frustration is this: I can see several ideas here that I’d like to try, such as folding parser errors … but it’s not at all clear what sort of software tools I might be able to use (short of writing my own game engine in C++) that would allow me to employ most of them.
I expect a Glulx multi-windowing system will do some of the basic things, such as keeping a list of currently useful verbs on display. But since I’m not a real programmer, developing anything beyond a standard parser UI is not something I feel competent to try.
Maybe I’ll have a fresh look at Glulx windowing, though.
–Jim Aikin
A fascinating read. I’m a part-time author that’s looking into new ways to present stories, so I’ve been researching IF a while.. but.. I’m not sure a system exists that will let me go from a static, linear presentation to a more immersive and interactive experience! I write character driven romance in several genres (comedy, mystery, horror) and The Parser Problem is certainly a thorn deep in my side. How to get the player/reader emotionally involved when they’re going to spend a LOT of time figuring out The Right Way To Say Things?
This has been a very thought-provoking discussion.
In an effort to connect better with a new user base, the text-based multiplayer game GemStone IV actually implemented a click-and-list interface in the form of their StormFront front end. It would indeed highlight meaningful objects and then give you a list of options (did you want to look at the book? pick it up? read it? do some rp command relating to it?) As far as I know, this was not widely adopted by the user base, as typing worked far better for those already familiar with the game – but it was still a cool idea.
Several years ago, I wrote a small IF. Though I enjoyed the experience and was relatively happy with the result, the problem of needing to support large numbers of verb-noun combinations that most players would likely never see resulted in me deciding to never attempt a larger IF. I would have no problem limiting the choices of the player (I spent a little time trying to implement a solution of ‘pitching the parser’ through a hypertext interface)… in the one game I created I tried to ensure that the game could be completed using only ‘look’, ‘get’ and ‘use’. But not supporting other verbs still felt like bugs, so I spent alot of time doing work that I feel was mostly wasted.
I do hope that a ‘good’ solution is found for this. I would enjoy creating more IF, but not with the current tools.
So we want to keep everybody happy: The experienced IF player, who likes to type commands and knows the language and limitations of the parser; as well as the novice (and all those who have been frustrated by guess-the-verb and similar experiences). That seems to call for a hybrid.
I am thinking of a sidebar on the screen (which may be turned off at the click of a mouse). Clicking in the sidebar types commands or parts of commands in the command line.
I agree that a verb-based menu is not very helpful. I find myself thinking objects rather than verbs: What am I going to use now, examine now, etc. This may be incompatible with English grammar, with its subject-verb-object structure, but fits S-O-V languages, such as Latin, naturally. (canem verbera baculo = dog hit with club, etc.)
On the other had, purely noun-based is not ideal either. In reality, the essence of an action sometimes lie in the verb, sometimes in the object, sometimes in the indirect object or instrument. (WHISTLE to the parrot; push the LEVER; open the door with the CROWBAR.) My solution is to present a menu of verb choices as well as noun choices; and those nouns can be used as object, indirect object, instrument, etc.
For instance, player clicks on KEY; the command line reads [______] KEY. The sidebar now shows various options involving keys, such as DROP KEY, EXAMINE KEY, GIVE KEY TO _____ and OPEN ______ WITH KEY.
Or the player clicks GIVE; the command line reads GIVE [______] TO [______]. The cursor now appears in the first “field”; player types GIFT, then [tab] or [space] or [enter], and the cursor automatically jumps to the send “field” to be completed.
Naturally, the lists of possible nouns and even verbs will be too long to display at once. The question is what to display, in what order, etc. I should work this out in more detail. By making smart choices, several difficulties are resolved, at least partially: (1) the novice is made aware of typical possibilities and how to type them; (2) truly meaningless combinations are weeded out by not showing them; (3) the author/tester has an overview to help chase down mismatched responses; (4) “guess the verb” is reduced to a minimum because all possibilities are shown in the menu.
I believe that a sidebar menu of this type can also be of great use in a development tool. For a given game item, the sidebar could indicate to the author which commands have been implemented, which commands elicit a negative response, which commands inherit positive behavior from an ancestor class, etc.
I think the problem-space would be significantly reduced if the interpreter were made to support tab completion.
This is a behavior implemented in bash and all the other command-line shells of note: type something, hit TAB, and a sensible completion pops up. Just how that completion is selected depends on what you typed. If the last thing you typed was a space, the shell takes what you’ve typed already as the name of a command, perhaps with some options; it looks up the file types associated with that command; it looks in the present folder for files of that type; and it shows you the first one. Hit TAB again, and it switches that out for the second one, and so on for however many times you feel like tabbing.
If you haven’t typed a space yet–and you are therefore in the middle of typing the name of the command–then the shell looks through the names of all the commands it knows, and gives you one that starts with what you typed. Or, if you’ve typed a space and then some other stuff, that would tend to be the name of a file, for which see above, but consider only files that start with the appropriate characters.
The really snazzy command lines–often branded as “quicklaunchers”–will *show* you an available completion even *before* you’ve pressed tab, but it isn’t considered actionable unless you actually press tab.
With nouns for files, and verbs for commands, this behavior could be reasonably added to an IF interpreter. Perhaps it would be best, for beginners, to offer completion even when they haven’t typed anything–make it default to LOOK or something. And by way of accomodating the players who type stuff that makes no sense, some enterprising library author might write manuals for each individual verb. When the parser gets input it can’t use, it does a full-text search through those, to find the verb most likely related to what the player wanted.
Come to think of it, that last might make a worthwhile game mechanic. Instead of [LOOK UP boss’s number IN phone], type [boss’s phone number] to do a search through all the documents you have access to, including but not limited to the game’s and interpreter’s manuals.
Those ‘parsers’ are still complete shit right now. And not only because these tools are poorly developed. The entire ideology of if-developers who create ugly games that can understand ‘hello’ but can’t parse ‘hello X, how are you?’ or even ‘hi’ is obsolete.
If text-based game fails text processing, noone plays it. Noone likes ugly design and primitive mechanics. These design solutions worked 30 years ago, but not now.