The Parser as a Symptom, not a Problem

Emily Short started an interesting conversation about the parser and offered an interesting alternative. Nick Montfort commented about the subject and Emily’s blog post has a sizable number of responses. I highly recommend reading through everything.

I have a great deal of sympathy for anyone that points out the flaws in using the current parsing technology within the available IF platforms. There’s a long history of parser inadequacies starting from two-word commands all the way to guess the verb problems. The most glaring problem is that if you place a person in front of a computer with a blinking cursor and tell them they can type anything, you’ve already failed. The parser is a very limited translation mechanism to a very limited world model.

The IF community has always sort of closed its eyes and waved away the problem by convincing itself that with thorough verb implementations and coded hints within the text that this resolves the problem. There was a belief that we were smart enough to hoodwink users into believing the parser could understand anything they type. We also believed we could create an imaginary world that seemed real enough to make the parser more meaningful than it truly is.

Emily has thoroughly disabused us of that notion. We have to face the fact that although our parser implementations are limited, the user experience is not conducive to new people catching on quickly.

However. I don’t believe our problem is the parser.

The parser does it’s job perfectly well. Once the user is familiar with how it works and determines what subset of english is available in a particular game, they tend to do just fine. So the problem isn’t the parser. That’s just a symptom.

The problem is the user interface.

Why do we do things the way we do them? Because we started out with tools that almost exactly mimicked systems that were designed in about 1975. These original systems were setup before we even had video. That’s right, the original Adventure and Dungeon (Zork Mainframe) games were only available in their original state on an ARPANET paper terminal.

When Infocom ported Dungeon to microcomputers, the only alteration they made was to add a status line at the top of the screen. Other than that, the user interface is exactly the same as using a paper terminal. Later on they added a few other graphical features, but the basic user experience remained.

When Mike Roberts created TADS and Graham Nelson created Inform, we were still using dumb terminals connected to mini and mainframe computers. Up until 1996, I was working almost exclusively on video terminals connected to a DEC VAX.

In the fourteen years since, no IF platform has embraced modern programming constructs. The Gang of Four design patterns book was published in 1994. Do we implement any of those patterns in our platforms? Not really, no. Have we embraced the concept of loosely coupled architectures? No. Have we embraced the concept of component based or layered architectures? No. Have we embraced web technology? No offense to Parchment and all the other Java or JavaScript interpreters, but no, we have not.

In order to truly explore alternate user experiences, IF programming needs to move into the twenty-first century. Our platforms need to provide loosely coupled architectures that leverage modern technologies like AJAX, Web Services, Flash, Silverlight, HTML5. Our platforms need to separate what the actual game engine does from what the user sees and how they interact with the story.

Once we get to that point, then we can start realizing user experiences that support and extend our existing parser technology. And then, through friendlier user interfaces, we can gradually immerse new users into the wonderful world of Interactive Fiction.