Foreign Languages in IF
Duane Morin
was met with lukewarm response.
How interesting would it be to set up a world where, in order to speak to
the NPCs, you had to use a different language (than the typical English)?
You could still enter commands, etc, in English, but when the time came
to talk to a dwarf or something, you'd have to speak to him in his own
language for him to understand. He would, of course, respond in his own
language. The reason I thought of this was that English s*cks to parse,
I'm pretty sure everyone will agree to that. Other than doing some simple
things like:
>Dwarf, Hello
>Ask dwarf about treasure
You can't really have a conversation. But other languages are MUCH easier
to parse, particularly if you've created a language solely for the sake
of the game. Some variant of Esperanto or Loglan might make it possible
for you to hold a relatively deep conversation with the NPCs, rather than
just experimenting until you hit the right keyword. (I remember one
game where that's exactly what it was, keywords:
>Ask guard about his job.
"I guard the Prince of the castle!"
>Ask guard for a job
"I guard the Prince of the castle!"
etc...
Anyway. Suggestions? My main point of interest is "conversational" AI,
much like the original Eliza syndrome. IF has the potential to provide
some very fun experiments in this field.
Duane
Duane Morin
be expected to learn this new language. Good question. :) I don't have
a great answer, although the idea of offering a dictionary of the langauge
(ala Klingon) to registered users as an incentive sounds kinda neat.
Maybe put a virtual version of the book in the game, or let the player
find some sort of translation device that can do simple sentences for
them. Of course, if all you're going to do is translate English into
this new language, you might as well just use English!
Ah, well, maybe it's not as neat as I thought.
Duane
Jocelyn Paine
you writing a parser from scratch, or have you looked at what's
described in some of the more recent books on AI programming? It's
certainly possible to construct parsers that will do better than the
kind of keyword-driven analysis you exemplified, covering a fairly wide
selection of sentence structures. For example, there was a book
published in 1987 or so by Ramsey and Barret (Ellis Horwood) called ``AI
in Practice'' that contained a surprisingly broad grammar. And this code
was based on an earlier package written by Sussex University that's
given away free with Poplog, and that has been around since at least
1983.
True, there are still problems. One is the lexicon - most syntax-driven
parsers will require you to provide morphological, syntactic and
semantic descriptions for every word in your language. But if your dwarf
spoke Loglan, you'd have to give all the players a Loglan word-book,
since it is (to say the least) not widely known. So instead, why not
give them a book specifying the English words they're allowed to use in
conversing with the dwarf, and limit the size of your English lexicon
that way?
Another problem is trying to cope with ungrammatical sentences - and
with sentences that, while grammatical to an English speaker, are not in
the range covered by your parser's grammar. Loglan actually gives you
some help here because it's possible to infer the syntactic class of any
word from its consonant-vowel pattern. But again, if your dwarf spoke
Loglan, you'd have to give your players a description of how to
construct grammatical Loglan sentences. So instead, why not give them a
description of which _English_ sentence structures will be accepted by
your parser?
Incidentally, Eliza _was_ based on keywords, and could easily be fooled
in exactly the same way as your example!
Jocelyn Paine
Bob Newell
>be expected to learn this new language. Good question. :) I don't have
>a great answer, although the idea of offering a dictionary of the langauge
>(ala Klingon) to registered users as an incentive sounds kinda neat.
>Ah, well, maybe it's not as neat as I thought.
Something just like this was done in "Border Zone" and I found it just
turned out to be a very annoying form of copy protection. I didn't want
to carry the book around with me everywhere (I like to play on laptops in
airplanes, etc.) Although, a game I am (perpetually) working on will
require that you know a little German or at least have access to a
dictionary. This is probably a lousy idea but I'm pretty far down that road.
Duane D Morin
:) I seem to be known on rec.games.programmer for doing just that. Although
I like to think of it as "Learning about a subject enough to do it well,
instead of trusting that someone else has already done it perfectly."
>True, there are still problems. One is the lexicon - most syntax-driven
>parsers will require you to provide morphological, syntactic and
>semantic descriptions for every word in your language. But if your dwarf
>spoke Loglan, you'd have to give all the players a Loglan word-book,
>since it is (to say the least) not widely known. So instead, why not
>give them a book specifying the English words they're allowed to use in
>conversing with the dwarf, and limit the size of your English lexicon
>that way?
>
>Another problem is trying to cope with ungrammatical sentences - and
>with sentences that, while grammatical to an English speaker, are not in
>the range covered by your parser's grammar. Loglan actually gives you
>some help here because it's possible to infer the syntactic class of any
>word from its consonant-vowel pattern. But again, if your dwarf spoke
>Loglan, you'd have to give your players a description of how to
>construct grammatical Loglan sentences. So instead, why not give them a
>description of which _English_ sentence structures will be accepted by
>your parser?
In both of your suggestions, you have the game limiting the English that
the player can use to converse. But can you justify this within the scope
of the game, convincingly? The best you could really do, it would seem,
would be to have lots of "The dwarf looks at you, puzzled." type of
responses when you say something wrong. I won't/can't write in
the docs of a game, "Ok, if you want to talk to an NPC, here's the way
to form a sentence:" I mean, that's not natural language. That's
commanding a computer to do something. Conversely, it would be easy
to justify that, of course this new race is speaking in a language that
you don't know. It would be a mistake to use 100% of a different
language, like Loglan, but something based on that could probably
pass.
>Incidentally, Eliza _was_ based on keywords, and could easily be fooled
>in exactly the same way as your example!
>
My fault for a bad example. I meant, "Conversational AI, such as a
conversation between two parties where the computer party can talk on
a subject chosen by the human." More like a Turing Test wanna be. Or,
Doug Lenat's Cyc project. Eliza is just the most common example associated
with that type of AI.
>Jocelyn Paine
Maybe a simpler version of my original proposal. Have the player have to
learn enough "dwarf" speak so that he/she'd be able to dress up like a
dwarf and sneak past the guard into the gold mines by giving the secret
password, or something like that. Player could earlier have hidden and
heard a conversation between two dwarves, and have a little phrase book
to figure out what it was that they said. This doesn't satisfy my
initial request, though, but it seems much more doable. And it could add
some flavor.
Duane
smeg...@castlebbs.com
IM>Is this a good thing? Naturally, there shouldn't be too many player
IM>deaths in a game, otherwise it gets frustrating. But if you insult a
IM>very large man with a very big gun, you should expect ill effects.
True. However, this didn't occur in a lot of the situations posed by
Lucas Games. Maniac Mansion, Zak McKracken, Secret of Monkey Island (I
and II), Loom, DOTT... even Indiana Jones didn't get shot, as far as I
played through it.
They have a bit of tact in their usage of deadly weapons... if you want
a game with a lot of big men and big guns, ask them to make an action
game, and pop into one of the other PC games newsgroups. :)
Big guns that kill don't seem to be Lucas's style. No harm, no foul.
-K.C.
---
Save space. There are users with 10-line .sigs in Canada.
smeg...@castlebbs.com
dam...@b63519.student.cwru.edu writes:
ID>>Is this a good thing? Naturally, there shouldn't be too many player
ID>>deaths in a game, otherwise it gets frustrating. But if you insult a
ID>>very large man with a very big gun, you should expect ill effects.
ID>In the LucasArts games at least, it works very well. Certainly, it would
ID>be possible to require the player to save often and restore after every
ID>mistake, but does this actually add anything to the game?
ID>Of course, a good UNDO feature eliminates this argument, but an UNDO
ID>would be easy to fit into the structure of a graphical system like
ID>LucasArts's SCUMM.
Well... without trying to start an argument over it, I think that really
depends... not all of Lucas's puzzles stem from simply performing
actions, which would make for the simplest UNDO implementation... it's
rather subjective.
---
.sig destroyed to make way for cyberspatial bypass
Mike Roberts
>In the LucasArts games at least, it works very well. Certainly, it would
>be possible to require the player to save often and restore after every
>mistake, but does this actually add anything to the game?
>
>Of course, a good UNDO feature eliminates this argument
Well, I'd actually say it doesn't eliminate it entirely. The main
thing that's bad about RESTORE is not the inconvenience (although
that's a really bad thing, too, especially if you haven't saved
lately), but that RESTORE doesn't take place within the story -- it
forces you to do something not in the persona of the main character,
but explicitly as the user. UNDO is the same way.
From a game design perspective, I think you can always think of ways
to avoid killing the player. The LucasArts games mostly accomplish
this simply by never creating a situation where the player can be
killed, but once in a while they use the other possibility: come up
with some reason that the apparently deadly situation didn't kill the
player after all.
While applications of these techniques sometimes end up looking a
little contrived, in that they can occasionally subtract from the
realism of the story, I claim that RESTORE and UNDO are always 100%
unrealistic.
--
Mike Roberts mrob...@hinrg.starconn.com
High Energy Software 415 493 2430 (Voice)
PO Box 50422, Palo Alto, CA 94303 415 493 2420 (BBS)
Paradise is a place exactly like where you are right now, only
much, much better.
--- Laurie Anderson
Jonathan D. Feinberg
> While applications of...techniques [like LucasArts'] sometimes end up
> looking a little contrived, in that they can occasionally subtract from
> the realism of the story, I claim that RESTORE and UNDO are always 100%
> unrealistic.
You can provide user servives like UNDO, RESTART, and SCRIPT with a wink if
you design the replies to match the scenario:
> SCRIPT
A secretary walks in from the east, and starts recording the
proceedings on a pad of shorthand paper.
or
> SCRIPT
You turn on your handy mini-cam, in order to preserve for posterity
your doings in this place. Otherwise, who would believe you?
or
> UNDO
You wake up with a start... You realize that your last action, "kill
troll with toothpaste," was merely a dream. Not sleeping well, lately?
Well, it's a thought.
--
Jonathan "JD" Feinberg j...@panix.com Sunny Brooklyn
Mike Roberts
>> SCRIPT
> A secretary walks in from the east, and starts recording the
> proceedings on a pad of shorthand paper.
Great ideas! I guess you can work these external commands into a game
after all. These would work best if the game already had a light tone,
but most adventures do. Of course, now you're going to have to explain
how the pad of paper makes its way into your DOS file system...
Jonathan D. Feinberg
(Mike Roberts) wrote:
> j...@panix.com (Jonathan D. Feinberg) writes:
>
> >> SCRIPT
> > A secretary walks in from the east, and starts recording the
> > proceedings on a pad of shorthand paper.
>
> Great ideas! I guess you can work these external commands into a game
> after all. These would work best if the game already had a light tone,
> but most adventures do. Of course, now you're going to have to explain
> how the pad of paper makes its way into your DOS file system...
MAC file system, if you please. :-)
--
j...@panix.com Jonathan "JD" Feinberg Sunny Brooklyn
J D Feinberg
(Jamieson Norrish) wrote:
> The big problem with this for me is how to fit it into the game at all
> - secretaries don't just come from nowhere, and would only fit certain
> genres and settings. And then, does this secretary count as a proper
> NPC for the purposes of interaction? If not, why not? To me, the
> addition of this feature would destroy the atmosphere more than if the
> script command was not linked into the game world at all.
I think you've taken my example a bit too literally! I'm suggesting that
you might create a "SCRIPT" functionality that IS consistent with your
design. But, if you were to insist on using the secretary as an example,
I'd reply that it's not difficult to endow the secretary with a set of
random responses that indicate clearly to the player, "I'm not important to
the story, I'm just here for the ride. Go ahead with your game." A
secretary, or an "administrative assistant" (a "Boswell," or "Watson")
might make sense in many scenarios.
Jamieson Norrish
mrob...@hinrg.starconn.com (Mike Roberts) writes:
j...@panix.com (Jonathan D. Feinberg) writes:
>> SCRIPT
> A secretary walks in from the east, and starts recording the
> proceedings on a pad of shorthand paper.
Great ideas! I guess you can work these external commands into a
game after all. These would work best if the game already had a
light tone, but most adventures do. Of course, now you're going to
have to explain how the pad of paper makes its way into your DOS
file system...
The big problem with this for me is how to fit it into the game at all
- secretaries don't just come from nowhere, and would only fit certain
genres and settings. And then, does this secretary count as a proper
NPC for the purposes of interaction? If not, why not? To me, the
addition of this feature would destroy the atmosphere more than if the
script command was not linked into the game world at all.
Jamie
Jamieson Norrish
Feinberg) writes:
My objection (and you're right, I should have taken your example less
literally) is that I would want the script device to be a fully
integrated part of the world - so that I could interact with it as
fully as I could with any other character/object.
Jamie