Adventure design
Anders Haavie
I want to make an adventure program based on a norwegian tv-series made in the
1970's. Good idea? I like it. The only problem I have is that I want to make the
whole in norwegian, and all the "adventure design programs" are made in english.
Is there any way to solve this problem?
Anders
P.S: Which program is the best? Tads? Alan?
Magnus Olsson
>
>I want to make an adventure program based on a norwegian tv-series made in the
>1970's. Good idea? I like it. The only problem I have is that I want to make the
>whole in norwegian, and all the "adventure design programs" are made in english.
>
>Is there any way to solve this problem?
Not that I know of. All adventure design systems of which I've heard
are based on English, and Englih grammar is sufficiently different
from Norwegian grammar that you'd not only have to change all the
messages, but do _extensive_ rewriting of the parser.
If you do feel up to doing that, I owuld recommend you to using
Advsys, since for that program the entire source code is freely
available.
The problem of IF in non-English languages is certainly interesting.
I've only seen one adventure game written in a language other than
English. This game is called Berg ("Mountain") and is written in
Swedish, directly from scratch in Turbo Pascal. It was pretty small
and simple (I think the authors intended it as a "test balloon" for
later games).
Personally, I had never seriously considered writing IF in any language
other than English (probably because one gets so used to all games
being in English that anything else would seem unnatural, and of course
also writing in English maximizes the potential audience), but this
game made me do some serious thinking about the issues.
One obvious problem with writing an IF parser in Swedish (or
Norwegian, which is very similar) is the definite articles. The
Nordic languages use suffixes to indicate the definite form as well as
plural, and these suffixes are far from regular. In English, you can
often simply let your parser ignore all definite and indefinite
articles: "Take the box" and "take box" would in most situations be
totally equivalent. Furhtermore, the word "box" would always be used
in referring to it; "There is a box here", "you drop the box", etc.
In Swedish, a room description could end with 'Det finns en l{\aa}da
h\"ar' - "There's a box here" (I'm using TeX notation for the special
Swedish characters), but if you wanted to take the box, you would have
to say "ta l{\aa}dan" - "take the box". "Ta l{\aa}da" would sound very
strange. This will make the parser as well as the representations for
objects more complex.
A less obvious problem is that Swedish is far
less tolerant of ellipses than English. For example, the telegraphic
style used in a typical IF command: "Take red dagger. Put it in
purse." is at least almost correct English, but anyone expressing
himself similarly in Swedish would sound like a half-wit. This not only
makes the required parser more complicated, but also makes it far more
cumbersome to play the game. I remember reacting to that in Berg - I
had to type a lot more than I was used to from English-language
adventures.
A final note: The authors of Berg are Fredrik Kilander (f...@dsv.su.se)
and Mats Wiklund (whose mail address I've forgotten). And "su" means
"Stockholm University", it has nothing to do with the top-level
ex-USSR domain :-)).
Magnus Olsson | \e+ /_
Department of Theoretical Physics | \ Z / q
University of Lund, Sweden | >----<
mag...@thep.lu.se, the...@selund.bitnet | / \===== g
PGP key available via finger or on request | /e- \q
David Whitten
to you as the programmer. As far as I know, neither of these interactive
fiction development systems has 'hard coded' text that you are unable to
over-ride with your own. So from an output/running/using point of view,
there is no way you can tell the language that was used to write the program.
IMHO, I feel that some kind of Germanic-derived natural language makes the best
root to derive a programming language from, since you want a language that
has 1) shorter (on average) command words, 2) separate prepositions. 3) A
grammar based complexity generation structure rather than a affix based
structure.
Thinking about this, I realized that this is an interesting topic in its own
right, so I have crossposted to sci.lang to give the linguistics folks a chance
to comment on what natural language makes the best basis for a formal
unambiguous computer language.
David (whi...@fwva.saic.com) US:(619)535-7764 [I don't speak as a company rep.]
Tom Almy
>whole in norwegian, and all the "adventure design programs" are made in
>english.
>
>Is there any way to solve this problem?
Get an adventure design program provided in source form (such as ADL), and
rewrite the command parser. I know it's a lot of work, but somebody's got
to do it. :-)
Tom
--
Tom Almy
tom....@tek.com
Standard Disclaimers Apply
Neil K. Guy
>I want to make an adventure program based on a norwegian tv-series
> made in the 1970's. Good idea? I like it. The only problem I have
> is that I want to make the whole in norwegian, and all the
>"adventure design programs" are made in english.
>Is there any way to solve this problem?
You might, of course, find that whoever owns the rights to this TV
show might complain...
Anyway, yes. I'm also somewhat interested in the whole issue of
translating games. I'm still toying with the idea of making a French
language version of the game I'm working on. I'm using TADS, and as
far as I can tell it should be possible to get a rudimentary system
going. The problem is that Norwegian would have to have the same basic
grammatical structure as English to work. (does it? I don't know.) If
you can formulate sentences as "verb the direct object with the
indirect object" or whatever, you should be able to change the names
of all the nouns, adjectives, verbs, etc. to Norwegian words.
Of course, if the language is far removed from English - like
Japanese or something - and doesn't use Roman letters and a vaguely
similar sentence structure you'll be out of luck.
TADS 2.0 does let you change the error messages generated by the
parser, so that's not a problem. One potential stumbling block is the
entry of accented (diacritical) letters. On the Mac TADS right now I
can't enter accented vowels (TADS thinks they're punctuation) and so
I'd only be able to accept non-accented vowels. Which would be
unacceptable to a French speaker. You can *display* accented
characters (and any characters in the extended Mac character set) just
fine - it's entering them that's a problem.
An interesting problem, in any event...
- Neil K. (n_k...@sfu.ca)
Neil K. Guy
Magnus, you write:
> In Swedish, a room description could end with 'Det finns en l{\aa}da
> h\"ar' - "There's a box here" (I'm using TeX notation for the special
> Swedish characters), but if you wanted to take the box, you would have
> to say "ta l{\aa}dan" - "take the box". "Ta l{\aa}da" would sound very
> strange.
Actually, is this necessarily a problem using TADS? I know nothing
about Swedish grammatical rules, but given what you've said couldn't
you do this in TADS:
laada: item
sdesc = "l{\aa}da"
adesc = "en l{\aa}da"
ldesc = "Det finns en l{\aa}da h\"ar. "
noun = 'l{\aa}dan'
location = Stockholm
;
Since TADS uses different strings to represent nouns (entered by the
user) and description text (displayed by the computer) the player
could refer to the box as one thing (l{\aa}dan) even though the
computer would talk about there being a "l{\aa}da" here. Does this
make any sense?
> [...] the telegraphic
> style used in a typical IF command: "Take red dagger. Put it in
> purse." is at least almost correct English, but anyone expressing
> himself similarly in Swedish would sound like a half-wit. This not only
> makes the required parser more complicated, but also makes it far more
> cumbersome to play the game.
Actually, I'd say that anyone saying "take red dagger" in English is
likely to sound like a half-wit. :) But how is Swedish different in this
sense? Isn't there an imperative form of verbs that is at least vaguely
similar in structure? Or do verb forms change, like in German, depending
on the case (nominative, dative, accusative, etc.) Longer forms of
verbal commands should be possible, assuming that they can be broken
down to something reasonably close to verb-noun.
Of course, having access to the parser source might make or break such
a project, and TADS source isn't available. You might be able to construct
weird hacks to get past certain problems, by using certain words as
prepositions when they're really not, or by using the compoundWord feature
to glue parts of words together to make for easier processing. I've had
to do this in my (English) game in order to get the game to accept such
sentence constructions as "Who am I?" or "What's the weather like?".
I'll probably have to do this to get French to work. Most imperative
verbs should be able to work (albeit in a clumsy fashion) but there are
some sentence forms that might be extremely difficult. Articles shouldn't
be too much of a problem. Just as English TADS doesn't distinguish
between the user typing "a box" or typing "the box," a French game could
just treat "le bo^ite" and "la bo^ite" as the same thing, even though
boxes are feminine. (of course, it would always display "une bo^ite"
on the screen.)
Anyway, not to go on about TADS, but I haven't used ALAN and I've
never been able to get AdvSys to work. Just some vague ideas...
- Neil K. (n_k...@sfu.ca)
David Librik
>aha...@ulrik.uio.no (Anders Haavie) writes:
>>
>>I want to make an adventure program based on a norwegian tv-series made in
>>the 1970's. Good idea? I like it. The only problem I have is that I want to
>>make the whole in norwegian, and all the "adventure design programs" are
>>made in english.
>>
>>Is there any way to solve this problem?
>>
>>Anders
>>
>>P.S: Which program is the best? Tads? Alan?
>
>I think this is a confusion of two ideas. The system you use is only visible
>to you as the programmer. As far as I know, neither of these interactive
>fiction development systems has 'hard coded' text that you are unable to
>over-ride with your own. So from an output/running/using point of view,
>there is no way you can tell the language that was used to write the program.
That's not what he's talking about. Adventure design systems have a lot of
inherent assumptions about the nature of language built into them. We're
not talking about the programming language per se, but the fact that it
is designed around the idea of "nouns" "verbs" and "adjectives", all as
separate words, with "articles" ignored, and the command word order as:
_verb_ _noun_, or _verb_ _noun_ _preposition_ _noun_. In many languages,
things happen to nouns when they are used for different purposes -- they
get their endings changed (often irregularly), or their initial consonants
mutate, or vowels change ... none of this is beyond a computer's ability,
of course, but at least in TADS the parser is already provided, and it
parses English sentences. You'd have to take something like ADVSYS or ADL
where you get the source code, and rewrite the parser to understand the
system of the new language. And if you don't have the idea of "command-
form of verb", "direct object" and "indirect object", the whole flow of
control of TADS is thrown off.
But I think it's a brilliant idea if you want to take it on.
- David Librik
lib...@cory.Berkeley.edu
Andries Brouwer
:That's not what he's talking about. Adventure design systems have a lot of
:inherent assumptions about the nature of language built into them. We're
:not talking about the programming language per se, but the fact that it
:is designed around the idea of "nouns" "verbs" and "adjectives", all as
:separate words, with "articles" ignored, and the command word order as:
:_verb_ _noun_, or _verb_ _noun_ _preposition_ _noun_. In many languages,
:things happen to nouns when they are used for different purposes -- they
:get their endings changed (often irregularly), or their initial consonants
:mutate, or vowels change ... none of this is beyond a computer's ability,
:of course, but at least in TADS the parser is already provided, and it
:parses English sentences.
Yes, although the irregularities are not so much of a problem.
When I wrote "hack" I also had to make sure that the right choice
was made between "is" and "are", and that plurals like "teeth",
"homunculi", "knives" etc. were handled correctly.
For a Dutch version of such adventure programs I found the verbs
very painful to handle. In English you say "drop object", but in
Dutch that becomes "laat ding vallen", where the verb is spread out.
This means that while for simple applications in English a trivial
parser or sentence generator suffices, one has to do more work in
many other languages.
Tommy Nordgren
preparse function is used to transliterate national characters into
english characters. In source code vocabulary specefications the replacement would
have to be done manually.
Swedish and Norwegian applies suffixes - often irregularly - to nouns in
determinate form. Innate objects have two different kinds of genus (total 4)
Adjectives are bend according to genus ow words.
To get around this, it is possible to declare BOTH forms of noun and
adjective in object specification. This will make the vocabulary twice as large,
so if may be necessary to override the default settings to compile.
A side effect is that the parser will accept illiterate phrasings as well.
Displaying text is of ,course no problem.
Disambiguating might present some problems, in the scandinavian languges,
this form : the yellow one - den gula will have an empty special-words string.
Tommy Nordgren, Stockholm , Sweden.
David Baggett
> Actually, is this necessarily a problem using TADS? I know nothing
>about Swedish grammatical rules, but given what you've said couldn't
For this specific example, TADS may be able to handle what you want to
do, but in general it's a serious problem, using TADS or any other
English-based adventure authoring system (except one, of course, where
you define all the workings of the parser yourself).
The fact that English doesn't in general mark case makes adventure
games much easier to write. But the oversimplification does cause
problems, even in English:
Me:
sdesc = "you"
thedesc = "you"
...
>x me
It looks like an ordinary you.
>kick bucket
I don't see how kicking the wooden bucket would help matters.
>kick me
*I don't see how kicking you would help matters.
(Should be "kicking yourself...")
TADS doesn't really pay attention to objective vs. nominative case (or
any other kind of case, for that matter), because it doesn't generally
matter in English. You could always rewrite ADV.T to deal with it, of
course, but that won't help the parser any.
To work for outputting other languages, ADV.T would at the very least
have to be updated to have "desc's" for number, gender, and all the
various syntactic cases.
In languages like Russian where cases are marked through some
process(es) (rather than something memorized, like definite articles in
German), you'd get into trouble. At the least you'd have to have
separete nouns for each case of every object.
And that's only scratching the surface. Consider a language like
Japanese; they use Chinese characters to write things and don't put
spaces between words, and hence it's an AI-complete problem to
just figure out where the word boundaries are. (You can do pretty
well with simpler methods, of course, but not perfect.)
Languages like Turkish will be problematic because they're so
morphologically productive. In "natural" writing you end up getting
words that are huge by English standards. Such things would have to be
analyzed into morphological (affix) components. Not trivial at all.
(A similar problem exists for German.)
I hope I don't have to even mention so-called "free word order"
languages like Walpiri at this point. :) (Japanese allows
extensive scrambling of words as well, for that matter.)
> Actually, I'd say that anyone saying "take red dagger" in English is
>likely to sound like a half-wit. :) But how is Swedish different in this
>sense?
I'm curious about this also. Oops, I mean
>ask Magnus about Swedish
Dave Baggett
__
d...@ai.mit.edu Natural Language Processing MIT AI Lab
ADVENTIONS: We make Kuul text adventures! Ask about Unnkulian 1, 2, 0, 1/2
PO Box 851 Columbia, MD 21044 USA / CIS: 76440,2671 / GEnie: ADVENTIONS
Neil K. Guy
>>x me
>It looks like an ordinary you.
It's a shame how languages are so irregular... I've found I've had to
special case a whole ton of these things, just to avoid weird
messages. I've also put in plural functions so the game can respond:
>shout at the privet bush
The privet bush doesn't pay any attention to you.
>shout at the frogs
The frogs don't pay any attention to you.
That sort of thing is pretty easy to do. But verb cases do get
awfully messy sometimes, even in English.
>To work for outputting other languages, ADV.T would at the very least
>have to be updated to have "desc's" for number, gender, and all the
>various syntactic cases.
As someone pointed out earlier, gender articles could probably be put
in, as long as the language wasn't dependent upon accurate use of
articles. Thus it'd be possible to type a grammatically incorrect
command, but the game would accept it anyway.
Well, I guess it's all part of the fun. I don't know if Esperanto
would be any easier to code than Hungarian as a text adventure, but I
think language irregularities are just part of the richness of human
experience...
- Neil K. (n_k...@sfu.ca)
Magnus Olsson
OK. You ask Magnus about Swedish. Magnus considers the question for
some time, and then replies:
I've thought about this a little more, and come to the conclusion that
the problem is not so much that the "adventure way of talking" sounds
more stupid in Swedish. One crucial difficulty with the Scandinavian
languages, as opposed to other Germanic ones, is that we put the
definite article as a suffix, not as a separate word.
This means that altough the method suggested by Neil (I think it was
by him, but the original post has expired), i.e. to use the definite
form of nouns in the vocabulary, but the indefinite when talking about
things, could work. It'd be a kluge, though. One disadvantage would be
if you wanted to translate this:
: There is a knife and a fork here.
> Take the knife and the fork.
: Taken.
> Drop the knife and the fork into the well.
: The knife falls into the well.
: The fork falls into the well.
Here, you have to use both the definite and indefinite forms of nouns
when referring to them. Of course, this can be fixed by having two
fields in the description of an object, one for the indefinite and one
for the definite form.
However, the big problem is when parsing commands like "take the red
dagger". The correct Swedish translation of this is "Ta den r{\"o}da
dolken", where both the adjective and the noun are in the definite
form. "den" is the explicit form of the definite article.
As long as one can accept a purist parser, that only accepts
grammatically correct sentences, there wouldn't be any big difficulty
(that's the way chosen by the authors of Berg). However, imagine how
tedious it would be always to have to type your commands as full
sentences. People would want to shorten their commands; at least I was
constantly annoyed when playing Berg by not being able to do that.
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.
So the parser really should know a lot more about grammar than in the
equivalent English case.
Another problem is how to represent characters that aren't in ASCII.
The letter I've written as {\"o} above (which is o-diaresis or
o-umlaut or "o with two dots on top" or whatever you want to call it)
would be represented as '|' on a system that uses the 7-bit Swedish
character set, as some code > 127 on an IBM PC, as another 8-bit code
on a Mac, and as a third 8-bit code on other systems.
I don't know if TADS is 8-bit transparent, but even if it is there
would be difficulties porting the adventure between different
platforms.
Neil K. Guy
>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.
So, the standard "takeVerb" would have a verb of 'ta'. Then the
dagger could have 'dolken' and 'dolk' as nouns and 'r{\"o}da' and
'r{\"o}d' as adjectives. Since articles ( 'den' and 'en' ) are
ignored, they can be put in anyway. Of course, this makes it possible
for the user to input grammatically weird commands (presumably "Ta en
r{\"o}d dolken" is totally wrong) and have the parser accept them.
Which shouldn't be a problem, right? I mean, this is supposed to be a
text adventure and not a computer-assisted Swedish-language training
program. :)
>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.
>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. 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. To make it less horrible, you could
also put a platform-dependent preparse function in that would turn all
accented characters into their unaccented equivalents.
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?)
>I don't know if TADS is 8-bit transparent, but even if it is there
>would be difficulties porting the adventure between different
>platforms.
Yes. You'd have to do some minor rewrites and recompile each port.
Since there are only two supported TADS 2.0 platforms out there now,
this isn't a problem. But who knows in the future?
Anyway. Sorry if this is boring anyone who doesn't care much about
writing non-English games. Heck, I find it kind of interesting,
though. Let's just not start a thread about "Computer Writes Swedish-
Language Book." :)
- Neil K. (n_k...@sfu.ca)
Magnus Olsson
>mag...@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.
Greg Maddog Knauss
>
>>kick bucket
>I don't see how kicking the wooden bucket would help matters.
>
>>kick me
>*I don't see how kicking you would help matters.
>(Should be "kicking yourself...")
Not if the actor is a a player-controlled golumn instead of the player
himself. It's a minor point, but you can finagle out of a lot of limitations
just by being a little creative with your explanations. (Bugs become
features. Heh.)
I, personally, hate reading room descriptions like, "I see a small,
dusty chair, leaning up against the door." But "I don't see how kicking
you would help matters" is at least a correct response in that context.
--
Greg Knauss (gr...@quotron.com) "Llamas, dammit! Llamas!"
David Baggett
> I, personally, hate reading room descriptions like, "I see a small,
>dusty chair, leaning up against the door." But "I don't see how kicking
>you would help matters" is at least a correct response in that context.
You mean, "I don't see how kicking you would help matters, and besides
that I can't, since you're on the other side of that glass screen." :)
Neil K. Guy
>In article <greg.730420810@duke> gr...@Quotron.COM (Greg "Maddog" Knauss) writes:
>> I, personally, hate reading room descriptions like, "I see a small,
>>dusty chair, leaning up against the door." But "I don't see how kicking
>>you would help matters" is at least a correct response in that context.
>You mean, "I don't see how kicking you would help matters, and besides
>that I can't, since you're on the other side of that glass screen." :)
Well, it's part of the whole thing of what role the computer is
playing. In my TA I've consciously phrased every comment by the
computer as an omniscient narrator. But it can get confusing at times.
I mean, say the player types "walk north." Well, according to
convention, the player is really saying "walk ME north." Okay. Fair
enough. But if the player says "kiss me" then is the player saying
"kiss myself" or "computer, you kiss me?"
I get kept up at nights thinking about this problem, lemme tell ya!
- Neil K.
(actually, Zork had an interesting inconsistency this way. If you
said "drink water" the computer would say "Thank you. I was feeling
thirsty" or somesuch, as though the command had shifted from having
the player being the subject of the verb to the computer. Kinda
confused me when I was a kid. :)
Kjetil Torgrim Homme
> player himself. It's a minor point, but you can finagle out of a
> lot of limitations just by being a little creative with your
> explanations. (Bugs become features. Heh.)
Delta Software's "Bored of the Rings" had some of this, and it was
very refreshing (and confusing). The prose was strictly in the third
person and in the past tense. I.e. something like:
> n
Fordo walked north.
When he arrived in Rivendull, he saw ...
It gives a quite different feel, don't you think? I'm not sure if the
prompt was changed from the usual "What now?" to "What then?", but
such a simple shift would make me, as a player, feel that *I* am the
story-teller. It is interesting to note that in "normal" prose, the
past tense is the norm, and present tense is mostly used for some
effect, while it's the other way around in interactive fiction.
Kjetil T.
Stu Galley
: Well, it's part of the whole thing of what role the computer is
: playing. In my TA I've consciously phrased every comment by the
: computer as an omniscient narrator. But it can get confusing at times.
:
: I mean, say the player types "walk north." Well, according to
: convention, the player is really saying "walk ME north." Okay. Fair
: enough. But if the player says "kiss me" then is the player saying
: "kiss myself" or "computer, you kiss me?"
:
: I get kept up at nights thinking about this problem, lemme tell ya!
:
: - Neil K.
Here's another interpretation: the earliest Infocom manuals (and maybe
the latest ones too) said '[The game] always acts as though your
sentence began with "I want to ..."'
And in the games I wrote at Infocom, for the first few moves the
prompt was 'What would you like to do?'
: (actually, Zork had an interesting inconsistency this way. If you
: said "drink water" the computer would say "Thank you. I was feeling
: thirsty" or somesuch, as though the command had shifted from having
: the player being the subject of the verb to the computer. Kinda
: confused me when I was a kid. :)
Probably the Original Implementors of Zork thought that this
unexpected shift in interpretation was pretty funny, but I too thought
it could be confusing.
--- Stu Galley
<Gal...@think.com>
Paul Christopher Workman
adventures .. by Stu Gal...@think.com
> the latest ones too) said '[The game] always acts as though your
> sentence began with "I want to ..."'
>
> : said "drink water" the computer would say "Thank you. I was feeling
> : thirsty" or somesuch, as though the command had shifted from having
> : the player being the subject of the verb to the computer.
That's how I sort of interpreted IF conventions. Usually,
you issue commands to the IF piece in the imperative tense,
as if you were controlling a remote android or something.
But then, the descriptions are usually in second person,
which is an UNUSUAL style in normal fiction. These two
conditions contradict each other, and form a weird relationship
between the player and the representation of the player in
the game. You tell the representation what to do, imagining
it to be in the IF Space, whereas the representation tells
you what's happening as if you, the player, were in the IF
space, but were somehow unable to perceive it without help.
Each participant in this relationship (the player and the
representation) thus sees itself as absent from the IF Space,
and the other as present in it. Weird. I guess you could
interpret this as a division between mind and body, though...
in which both mind and body refer to the other as "you."
You could resolve this contradition by changing the behavior
of the representation of the player, that is by ceasing to
interpret it as a representation of the player but rather
as a separate entity within the IF Space. Here's a possible
example (Player's commands start with a ">"):
------
I'm in a room. There are three doors. I hear a growling sound
from behind the third door. What should I do?
> What do you have with you?
A bottle of water, a sword, a length of string.
> Tie the string around the door handle.
Done.
> Move away from the door.
Moved.
> Wield your sword.
Done.
> Pull on the string.
The door opening, and a wolf came out! It's running at me!
What should I do?
> Kill it!
Done. It was wearing a gold collar.
> Take the collar.
-----------
The effect is as if you were commanding a stupid soldier
from a radio linkup. You can see the correspondances
to normal IF (`What you you have with you?` being the same
as `inventory`); only the phrasing is slightly different.
You could make this seem closer to reality by allowing
the commanded entity in IF space to act without your
guidance if you choose not to command it. So you get:
-------
I'm in a room. There are three doors. I hear a growling sound
from behind the third door. What should I do?
Hello?
Hello?
I'm going to open the door.
Oh no! A wolf! Argggg.....
[CONNECTION CLOSED. BOB IS PRESUMED DEAD.]
----------
Have there been any IF games like this?
--paul