Newsgroups: rec.arts.int-fiction
Path: gmd.de!Germany.EU.net!EU.net!howland.reston.ans.net!news.moneng.mei.com!uwm.edu!cs.utexas.edu!uunet!world!dmorin
From: dmorin@world.std.com (Duane D Morin)
Subject: Re: Parsers
Message-ID: <CM4Jpq.82r@world.std.com>
Organization: The World Public Access UNIX, Brookline, MA
References: <1994Mar1.140641.23498@schunix.dmc.com> <CM2o4I.AB3@world.std.com> <jdrukman.762721714@dlsun87> <2l5ho6INNqrt@life.ai.mit.edu>
Date: Fri, 4 Mar 1994 05:10:36 GMT
Lines: 107

In article <2l5ho6INNqrt@life.ai.mit.edu>,
Carl de Marcken <cgdemarc@ai.mit.edu> wrote:
>I do research in parsing natural language, and know a lot about building
>parsers, from simple adventure-game templatic stuff to real ones built around
>complex linguistic theories.  Let me suggest that as far as adventure games go,
>stick with the simple stuff and don't get sidetracked by the misconception that
>a better parser would significantly improve a game.

The question I'd prefer is, "What would it hurt?"  I don't want to write a 
full blown IF game.  I'd much rather write a good parser and give it to someone
else to use in their game.  I'm not wasting any time "reinventing the wheel",
because the currently available wheels don't really roll the way I'd like.
Besides, I've always wanted to visit a Wheel Making plant.

>You see, the problem is that the more capable the language interface is, the
>more likely it is that people are going to be fooled into believing your game
>is smart.  This is a classic problem- it comes up all the time in natural
>language interfaces, 

Eliza syndrome?  In a way, what's wrong with it?  

>especially in speech interfaces.  The advantage of a
>primitive TADS-like parser is that its capabilities can be described succinctly
>to a game player.  After they learn what the 3 or 4 simple templates they can
>type in are, that's all they try.  So they don't get disappointed and confused
>by typing "Walk south but just far enough south that I'm in the doorway." and
>finding out that the game's world just isn't complex enough for that to be
>a reasonable command.

I'll claim that many of the people that try such a statement will already
have been so Wow'd by the game in the first place that they won't pause
for a second before trying something else.  They'll think that it's their
fault that they've done something the computer doesn't understand, and
try something else.

Typical example.  Way back when, I wrote a simple Eliza type program (Hey,
who didn't?)  I thought it sucked, because I could break it by typing in
the right things, making it produce garbage.  Time came for a computer
show (I was working at the local high school) and the computer teacher said
"How to we make a demo out of your program?"  I told them no, I wouldn't
show it off, I didn't think it was good enough.  But, sure enough, they
demo'd it without me, and I found a roomful of people crowded around
a computer that was basically spitting out gibberish, to me, but absolute
magic to them.

When I write a natural language database query, I don't want to trick my
user into thinking that the computer is smarter than it really is.  They
should know how every word of "LIST ALL THE RECORDS WHERE THE ZIPCODE IS 
BETWEEN 01604 and 02184 AND THE LAST NAME STARTS WITH S" breaks down
into a request, so that they can efficiently use the program.  But,
right now, we're talking about games.  There's no need for efficiency.
There's just a need for fun.  Ideally, I suppose, a good parser should
give you the feeling that you're talking to someone, instead of the 
typical:

<verb> [<object>] [<direct object>...]

I mean, granted, there's no real sense to experimenting if you don't 
stop thinking "I'm just telling the computer what to do."  I don't have
a particularly good solution that doesn't involve this, though, but 
I'm working on it.

>Think about some of the advertisements companies like Apple have been printing
>for their speech recognition software.  They show people saying "Open my
>favorite word processor."  It's a mistake they're making.  The reality is that
>the underlying technology is only capable of executing predefined macros when
>cued by a specific word sequence.  So, a person who sees one of these ads and
>says "Open my SECOND-FAVORITE word processor" is going to be sadly disappointed
>and may not understand why it didn't work.  If this sort of confusion happens
>in your game, it will leave a naive player with a far worse impression than if
>they had merely been told that the game understands only VERB NOUN.

I disagree first that people will be so quick to experiment like that.  
Users, in many cases, are frightened of what they're doing.  They don't
want to do what they haven't been told to do.  If no one tells them that
they can say "second-favorite word processor", then odds are that most
of them never will.  The few that will are the ones that know enough
about the technology to say, "Hey, I wonder if it will understand this..."
"Oops, I guess not."  But now we're talking about games, not applications.
The most that's going to happen in a game is your character dies.  People
will tend to experiment more.  The trick is to push them i the right
direction (by supplying some examples) without letting them fall into
that template trap.

>So while you may feel that it would be really cool to be able to type in
>real sentences, or have the parser disambiguate complex prepositional-phrase
>and relative clause adjunction phenomena, 

I was willing to take you at your word that you know parsers.  Thanks for
the proof.  :)

>the reality is that it is very
>unlikely your underlying world representation will be capable of supporting
>this level of language understanding, and the result will be confusing for
>most players.

<shrug>  I say they'd be confused until they learn what does work, and then
they'd stick with that.  You don't keep trying to same things over and over
if you've already been given an error message.  

>
>Carl de Marcken
>

Duane


