gemini - kennedy.gemi.dev

💾 Archived View for gemini.ctrl-c.club › ~nttp › writing › intfic › rescue-the-parser.txt captured on 2024-03-21 at 16:17:07.

-=-=-=-=-=-=-

Rescuing the interactive fiction parser from oblivion
=====================================================

It's 2016, and for the first time (in over two decades) <a href="http://versificator.net/detectiveland/">a game with no parser</a> won the Interactive Fiction Competition. Not only that, but in spring <a href="http://birdland.camp/">a game made in Twine</a> swept the XYZZY Awards for 2015. And two-thirds of the Spring Thing entrants, including <a href="http://astriddalmady.com/deep.html">one of two winners</a>, were choice-based.

Why does it matter? Because no earlier than 2014 there was a huge dispute over parser-less games raising to prominence in the IFComp. And doubts about the future of the parser stretch all the way back to 2010 -- not coincidentally, the year Twine started getting notice.

How ironic that just a few months before *that* it was hard to find an interactive fiction piece made with anything except Inform 7.

No wonder that fans of the parser can get defensive. Not that parser-based games are going anywhere, but, you know. Down from the top of their game, and all that. (Pun not intended.) Worse, there's a simmering dread that the parser failed to keep up with the times and appeal to new players even as interactive fiction slowly became mainstream again. And not for lack of trying.

You see, in the very first text adventure commands didn't get more complex than "get lamp". Not ten years later, as the so-called parser wars peaked, any commercial game worth its salt could understand "knight, pick up the magic sword from the wall and attack the orc with it". And it still wasn't friendly enough to newcomers. So developers upped the ante, adding techniques borrowed from chatterbots (Siri's ancestors), and even adverbs: "throw the rope vigorously across the river" -- a real example -- actually made a difference. As it turned out, however, most games couldn't benefit from the added smarts, and while these new parsers understood more, they didn't do it any *better*. New players were still lost.

Which is why graphical adventures quickly moved from parsers to clickable words to just letting players click directly in the picture, where all the action took place by now. Late text adventures also tried long lists of verbs and nouns players could click instead of typing.

It didn't save them from failing in the market. Perhaps because it didn't really change what they were.

Enter the hobbyist interactive fiction era of the 1990s, courtesy of Inform and TADS. For starters, the new crop of authors went back to basics to fix the parser: add more synonyms, recognize more phrasings, ask for clarifications, give useful error messages. Which made the genre much more accessible to players already used to its conventions, but still left most newcomers to stumble. Even increasingly better-written tutorials didn't seem to help much, if at all. In a valiant effort, the very best authors tried adding beginner modes to their works, that detect when you're stuck and suggest likely commands. I can only imagine the amount of work involved, but it must have been a lot more than the gains, because the method quietly fell by the wayside after the first few attempts.

Look, I'm a fan of command lines. From DOS through Linux to MUDs I used many such interfaces. Even created a couple, more recently. And in all of them, users are faced with a couple of basic difficulties: 1) figuring out what commands there are and 2) figuring out what each command can apply to. The former can only be fixed by having an up-to-date, comprehensive list available at all times -- not that it helps much when there's a lot of them. For the second, modern operating systems use something called <a href="https://en.wikipedia.org/wiki/Command-line_completion">tab completion</a>: the ability to get a list of suggestions for what to type next, that changes based on context.

And neither is possible in text adventures, both because it would spoil some puzzles (though if players want spoilers, who are we authors to say no?) and because virtual machines such as Glulx simply don't work that way. They're so abstracted, the user interface code has no way of peeking at the working memory of the game if it wanted to. And without that ability, you can only have the most primitive tab completion, based on the raw text recently output.

So it happens that a feature designed long ago to maximize portability -- the reason why you can play the exact same story files on dozens of very different machines -- is now getting in the way of making them playable by the very people who need the most help.

All this may sound like the parser is doomed to a slow death, as people who discover interactive fiction today can enjoy a vast and growing body of work that doesn't require them to learn a command-line interface. But don't despair yet. A couple of novel approaches, both represented in this year's IFComp, might just change the way we think of the parser, and give it a new lease on life.

For one thing, conventional wisdom has long held that players want more. More objects, more verbs, more ways to combine them. (Only the map is expected to be minimal, for some reason.) To support this, modern authoring systems provide dozens of verbs by default; it's hard to even think of ways to give them all meaningful uses in any given story, let alone do all the coding and testing it would involve. Players are encouraged to experiment, but seldom are they given any fun discoveries for their efforts. Cue disappointment.

Well, what if you did the exact opposite? Instead of many irrelevant verbs, have just a handful, but give them a variety of uses. Multiple syntaxes. Heck, bring back adverbs. Make your game deep, not broad and shallow like a puddle. Sure enough, <a href="https://heterogenoustasks.wordpress.com/2016/05/18/narrow-parsers/">narrow parsers</a> as they are called turn out to give a game focus, and reduce mental overhead. The _Peterkin Investigates_ games, that I <a href="https://notimetoplay.org/cgi-bin/wiki/Two_story_games_where_you_are_the_detective">reviewed not so long ago</a>, are positively refreshing in that sense. It takes fighting the authoring system to get rid of the chaff, but oh well.

How few verbs can you get away with? The usual answer seems to be five or six, but as graphical adventures ultimately demonstrated, you can make do with just one, "click", that applies the most sensible action to its target depending on context (pushing buttons, examining scenery and so on). The interactive fiction equivalent would be keyword parsers, of which my favorite example remains _[Starborn](https://github.com/juhana/starborn)_ (Juhana Leinonen, 2011). Basically, rather than typing complete commands, you just enter the name of an object to focus on. In bigger games, it can be tricky to figure out how to advance the story, since after all you're limited to pointing and grunting. But then the latter is true of any mouse-driven software.

None of the popular authoring systems have built-in support for keywords, though they can be coerced into working that way. In fact I only know of <a href="https://github.com/incompl/dream">one dedicated engine</a>, and clearly the author ran into a guess-the-keyword kind of issue, because all current choices are listed in a sidebar. Might as well put links on them and dispose of the parser entirely.

Which just serves to illustrate the biggest problem with command lines in general: they're great for incremental refining of complex repetitive operations, but most of the time pressing a button can express intent just fine. We need interactive fiction that takes advantage of the parser's unique qualities in ways nothing else can match, or else people will settle for good enough, and we'll be left behind.

Wouldn't that be a loss.