Newsgroups: rec.arts.int-fiction
Path: gmd.de!Germany.EU.net!mcsun!sunic!news.lth.se!pollux.lu.se!magnus
From: magnus@thep.lu.se (Magnus Olsson)
Subject: Re: Non-English adventures (was Re: Adventure design)
Message-ID: <1993Feb17.001132.22543@pollux.lu.se>
Sender: news@pollux.lu.se (Owner of news files)
Nntp-Posting-Host: lena.thep.lu.se
Organization: Theoretical Physics, Lund University, Sweden
References: <1lp2faINNeb@life.ai.mit.edu> <1993Feb16.143037.12175@pollux.lu.se> <neilg.729896286@sfu.ca>
Date: Wed, 17 Feb 1993 00:11:32 GMT
Lines: 72

In article <neilg.729896286@sfu.ca> neilg@fraser.sfu.ca (Neil K. Guy) writes:
>magnus@thep.lu.se (Magnus Olsson) writes:
>
>>So the parser should really be accomodating, and accept the following
>>forms of the command:
>
>>"Ta den r{\"o}da dolken" ("Take the red dagger").
>>"Ta r{\"o}da dolken" (still definite form, but only one definite article)
>>"Ta r{\"o}d dolk" ("Take red dagger") - never mind if it sounds stupid!
>>"Ta en r{\"o}d dolk" ("Take one red dagger") if there are several.
>
> Hmmm... Well, given what you've said I don't *think* it's necessary
>for a TADS game (sorry to keep going on about TADS for all those
>non-TADS users; it's the only system I know in any detail) to have a
>"purist" parser, as you put it. Each object can have more than one
>noun and adjective associated with it, making implementation easy.

Well, I suppose it all depends on the level of "understanding" you
require from the game. Your solution will work, and will in many
circumstances be indistinguishable from a more ambitiously "correct"
one. It will be a linguistic kluge, but it will work in most
circumstances. I can't give any examples offhand where it wouldn't
work. Maybe it's not so much of a problem after all, but I'd sure prefer
to work with a parser that's suited for  the input language to having
to work *around* one that isn't.

>>So the parser really should know a lot more about grammar than in the
>>equivalent English case.
>
> It sounds to me more like the implementer has to think about more
>grammatical permutations and then code them in - it's not really the
>parser that's doing the work here.

Yes. I suppose it's a matter of design philosophy, but again I'd
prefer having the parser (and other early stages of the program) handle
as much as possible of the natural language processing.

>>Another problem is how to represent characters that aren't in ASCII.
>
> This could be a real problem here. Until such time that TADS accepts
>platform-dependent character sets this might be dodgy. 

For pure text, I think the best solution right now would be for TADS
internally to use ISO-Latin, and let the compiler and run time system
convert from/to the hardware's character set. That would run into
problems if the author wanted to include line-drawing graphics or
special characters only found on some hardware, though.

>You could put
>together a cheap hack in which the accents are ignored. Your dagger
>example might have adjectives set as 'rod' and 'roda', and a user
>could type in unaccented words. 
[...]
> That's what I'm thinking of doing with my pipe-dream French game. The
>big drawback is that if there are two different words distinguished
>only by accents then the game may be unable to distinguish them
>properly. (does this happen in Swedish?)

Yes, so I'm afraid such a solution would be unacceptable, unless the
implementer worked *really* hard to eliminate ambiguities. 

To pick nits, the letter {\"o} isn't viewed as an accented o, but as a
separate letter in Swedish. But this isn't so important, since there
are languages where similar differences are called accents. The
important point is that the pronunciation is totally different, and
that the sens may differ, too.

              Magnus Olsson                | \e+      /_
    Department of Theoretical Physics      |  \  Z   / q
        University of Lund, Sweden         |   >----<           
 magnus@thep.lu.se,  thepmo@selund.bitnet  |  /      \===== g
PGP key available via finger or on request | /e-      \q
