A Game That Represents What An IF System Should Do?
okbl...@my-deja.com
be), which game would you use to demonstrate its power. Setting aside
for a moment any new things it might do, which game would you want to
port to demonstrate that your system could do whatever the current
systems could do?
"Collossal Cave", of course, should be ported to every new system :-).
--
[ok]
Sent via Deja.com http://www.deja.com/
Before you buy.
chads...@my-deja.com
okbl...@my-deja.com wrote:
> If you were looking to build a new IF system (as many people seem to
> be), which game would you use to demonstrate its power. Setting aside
> for a moment any new things it might do, which game would you want to
> port to demonstrate that your system could do whatever the current
> systems could do?
>
> "Collossal Cave", of course, should be ported to every new system :-).
> --
> [ok]
I think there are several games that IF systems should use to
demonstrate their power; first "Adventure", like you mentioned. That
would demonstrate basic capabilities. Then Zork, because that parser is
today's standard. Then perhaps games with multimedia- can it make
Arrival? Myst? Tetris? Admittedly, these are bonuses, but could still
be used as examples.
Chad Schultz (chads...@hotmail.com)
okbl...@my-deja.com
chads...@my-deja.com wrote:
>
> I think there are several games that IF systems should use to
> demonstrate their power; first "Adventure", like you mentioned. That
> would demonstrate basic capabilities. Then Zork, because that parser
is
> today's standard.
I would have thought something later than "Zork" might be preferable,
say "Curses". (But even "Curses" is relatively old.)
> Then perhaps games with multimedia- can it make
> Arrival? Myst? Tetris? Admittedly, these are bonuses, but could still
> be used as examples.
Heh. Tetris. (Was Tetris done in Inform or just Z-code assembler?)
I was thinking just of plain ol' text adventures. Fancier presentation
options could run the gamut from "Arrival" to "Grim Fandango", but the
main thing I was curious about is which game people feels best exercizes
all the power of the modern IF system.
--
[ok]
Kevin Forchione
> I would have thought something later than "Zork" might be preferable,
> say "Curses". (But even "Curses" is relatively old.)
Curses may be relatively "old", but it is *the* benchmark for what an IF
system should do. A system that could not give us "Curses" hasn't made it
into the modern era of IF. Having said that, as the source for Curses has
never been released it is difficult to judge the facility with which it
accomplishes what it does.
Perhaps the behaviours and presentation of a "Curses" or an "Adventure"
could be replicated by a low-level language, such as assembler -- but
Inform's implementation of the story is, presumably, a demonstration of the
elegance and relative ease of the Inform language.
So facility in implementation of the game is an important aspect of its
representation of what an IF system should do.
--Kevin
Dan Schmidt
| <okbl...@my-deja.com> wrote in message news:80f5cf$8mr$1...@nnrp1.deja.com...
| > I would have thought something later than "Zork" might be preferable,
| > say "Curses". (But even "Curses" is relatively old.)
|
| Curses may be relatively "old", but it is *the* benchmark for what an IF
| system should do. A system that could not give us "Curses" hasn't made it
| into the modern era of IF. Having said that, as the source for Curses has
| never been released it is difficult to judge the facility with which it
| accomplishes what it does.
|
| Perhaps the behaviours and presentation of a "Curses" or an "Adventure"
| could be replicated by a low-level language, such as assembler -- but
| Inform's implementation of the story is, presumably, a demonstration of the
| elegance and relative ease of the Inform language.
I shouldn't be posting while Graham's around to give the real story,
but my understanding is that the first version of Curses was basically
written in assembler.
From the Technical Manual:
Inform 1, then, was the assembler "zass" rewritten and with certain
shorthands added. ... "Curses" was written in Inform 1 code for
about two years before being translated into modern syntax.
--
Dan Schmidt | http://www.dfan.org
Dylan O'Donnell
> <okbl...@my-deja.com> wrote in message news:80f5cf$8mr$1...@nnrp1.deja.com...
> > I would have thought something later than "Zork" might be preferable,
> > say "Curses". (But even "Curses" is relatively old.)
>
> Curses may be relatively "old", but it is *the* benchmark for what an IF
> system should do. A system that could not give us "Curses" hasn't made it
> into the modern era of IF. Having said that, as the source for Curses has
> never been released it is difficult to judge the facility with which it
> accomplishes what it does.
Christminster's source, on the other hand, has been released, and
that game contains a number of Hard IF Things (detailed NPCs, liquids,
fire, multiple identical objects); porting it successfully would be a
good sign that the system's capable of handling the tough stuff. I'm
not sure offhand where the licence stands on ports, however.
--
: Dylan O'Donnell : "Nothing matters very much, and few :
: http://www.fysh.org/~psmith/ : things matter at all." -- A.J. Balfour :
Graham Nelson
<URL:mailto:df...@harmonixmusic.com> wrote:
> I shouldn't be posting while Graham's around to give the real story,
> but my understanding is that the first version of Curses was basically
> written in assembler.
>
> From the Technical Manual:
>
> Inform 1, then, was the assembler "zass" rewritten and with certain
> shorthands added. ... "Curses" was written in Inform 1 code for
> about two years before being translated into modern syntax.
Yes. It was an assembler with certain high-level features added,
notably an "if" statement. But again, this is laying too much
emphasis on syntax. The syntax was clumsy but the functionality
of the library and its world model were fairly strong. In
particular I think it impressed people to find dialogues like:
>look up bach in book
(first taking the Encyclopaedia of Composers)
(putting the tuning fork in the rucksack to make room)
"J. S. Bach (1685-1750) had a pet aardvark called Nigel...
At the time, I think only TADS 2 and Inform could do this sort
of thing with any comfort.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Jonadab the Unsightly One
> Christminster's source, on the other hand, has been released, and
> that game contains a number of Hard IF Things (detailed NPCs, liquids,
> fire, multiple identical objects); porting it successfully would be a
> good sign that the system's capable of handling the tough stuff. I'm
> not sure offhand where the licence stands on ports, however.
[...]copyright (c) 1995-1997 by Gareth Rees. Verbatim copies may
be freely copied and distributed provided that they are distributed
together and not piecemeal; modified versions of these files may not
be distributed.
I'm afraid ports aren't allowed by that wording, although
you could _ask_ the author for special permission.
What about Ruins?
"Virtual Reality has nothing on Calvin." -- Susie Derkins
chads...@my-deja.com
okbl...@my-deja.com wrote:
> In article <80f1rk$5t9$1...@nnrp1.deja.com>,
> chads...@my-deja.com wrote:
> >
> > I think there are several games that IF systems should use to
> > demonstrate their power; first "Adventure", like you mentioned. That
> > would demonstrate basic capabilities. Then Zork, because that parser
> is
> > today's standard.
>
> say "Curses". (But even "Curses" is relatively old.)
Why? After all, the Infocom parser is today's standard.
> I was thinking just of plain ol' text adventures. Fancier presentation
> options could run the gamut from "Arrival" to "Grim Fandango", but the
> main thing I was curious about is which game people feels best
exercizes
> all the power of the modern IF system.
Actually, that might _be_ one of the older games.
Chad Schultz (chads...@hotmail.com)
okbl...@my-deja.com
Well, it's not really the Infocom parser, is it? I mean, all we're
really using from Infocom is the Z-machine standard. It's Graham's
parser. And even it's changed from "Curses", although perhaps not much.
And, an IF system is more than its parser, eh?
> Actually, that might _be_ one of the older games.
"That" being "Curses"?
--
[ok]
chads...@my-deja.com
okbl...@my-deja.com wrote:
> In article <811egj$2u6$1...@nnrp1.deja.com>,
> chads...@my-deja.com wrote:
> >
> > Why? After all, the Infocom parser is today's standard.
>
> Well, it's not really the Infocom parser, is it? I mean, all we're
> really using from Infocom is the Z-machine standard. It's Graham's
> parser. And even it's changed from "Curses", although perhaps not
much.
The standard as in what TADS, Inform, and Hugo try to live up to in
terms of capability. I didn't mean it was the specific parser _used_
today, just basically the parser that "If your parser can't handle what
this can, it's no good".
> And, an IF system is more than its parser, eh?
>
> > Actually, that might _be_ one of the older games.
>
> "That" being "Curses"?
"That" being:
>which game people feels best exercizes all the power of the modern IF
>system.
Chad Schultz (chads...@hotmail.com)
okbl...@my-deja.com
chads...@my-deja.com wrote:
[stuff that made sense]
Thanks for clarifying.
--
[ok]
Matthew T. Russotto
}In article <811egj$2u6$1...@nnrp1.deja.com>,
} chads...@my-deja.com wrote:
}>
}> Why? After all, the Infocom parser is today's standard.
}
}Well, it's not really the Infocom parser, is it? I mean, all we're
}really using from Infocom is the Z-machine standard. It's Graham's
}parser. And even it's changed from "Curses", although perhaps not much.
Yep. The Infocom parsers are much different. I had started
deciphering a couple of them at one point (an offshoot of some work I
was doing on ztools, which resulted in a more informative infodump
-dc1), but real life intervened.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Graham Nelson
<URL:mailto:russ...@wanda.vf.pond.com> wrote:
> }> Why? After all, the Infocom parser is today's standard.
> }
> }Well, it's not really the Infocom parser, is it? I mean, all we're
> }really using from Infocom is the Z-machine standard. It's Graham's
> }parser. And even it's changed from "Curses", although perhaps not much.
>
> Yep. The Infocom parsers are much different. I had started
> deciphering a couple of them at one point (an offshoot of some work I
> was doing on ztools, which resulted in a more informative infodump
> -dc1), but real life intervened.
Since Infocom did not have a "library", but merely copied code
from one game to another and mutating it each time, the parsers
are all subtly different; and some early and very late ones are
entirely different. I think c. 1987 games have a much friendlier
feel to them than c. 1982 games, too, because they have "x" for
"examine", and "undo", and better handling of "it" and "all".
This easy-going and evolved style is indeed "today's standard".
Inform's parser tries to have the same facilities, but that's
all. Internally I think I can reasonably claim that it's a lot
more powerful than Infocom's parser: you won't find too many
adventure parsers which can parse all of...
> ; 4+PotPlant.water(cold_water, times++)
> nimm den frosch von ihm
> set the alarm to quarter to 6
> write "Hello, Sailor!" on the blackboard
...without any modification. Not that I'm boasting at all.
As if I would ever boast.
Arcum Dagsson
<gra...@gnelson.demon.co.uk> wrote:
Indeed, that is one reason why I generally prefer inform games to tads.
The base level of the parser, for a beginners game, is higher...
--Arcum Dagsson
--
"Real children don't go hoppity-skip unless they are on drugs..."
"Everyone was acting normal, so I tried to look nonchalant..."
David Glasser
Please do not make unqualified statements about opinions.
TADS certainly handles the fourth one, and as far as I know the third.
The second would require writing a translated library, but Graham is
exaggerating for Inform, as it does there also. The first won't show up
in the end game that you will play.
The TADS Parser has its fans too, you know; for example, it has an extra
stage of validation that often makes disambiguation work better. Both
parsers are good.
--
David Glasser | gla...@iname.com | http://www.davidglasser.net/
"It's good to explore the G.U.E. caves / It's good to explore the G.U.E.
caves / You can count all the leaves / You can KILL TROLL WITH SWORD /
You'll get stuck but you won't be bored"-Joe.Mason, rec.arts.int-fiction
okbl...@my-deja.com
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>
> Inform's parser tries to have the same facilities, but that's
> all. Internally I think I can reasonably claim that it's a lot
> more powerful than Infocom's parser: you won't find too many
> adventure parsers which can parse all of...
>
> > nimm den frosch von ihm
> > set the alarm to quarter to 6
> > write "Hello, Sailor!" on the blackboard
>
> ...without any modification. Not that I'm boasting at all.
> As if I would ever boast.
I can't *tell* you how often I've had to type every one of those *and*
in that exact sequence in an IF game. ;-)
Gene Wirchenko
Get those Comp '00 entries ready, people.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Arcum Dagsson
(David Glasser) wrote:
> Arcum Dagsson <arcum_...@hushmail.c.o.m> wrote:
>
> > In article <ant1923180b0M+4%@gnelson.demon.co.uk>, Graham Nelson
> > <gra...@gnelson.demon.co.uk> wrote:
> >
> > > > ; 4+PotPlant.water(cold_water, times++)
> > > > nimm den frosch von ihm
> > > > set the alarm to quarter to 6
> > > > write "Hello, Sailor!" on the blackboard
> > >
> > > ...without any modification. Not that I'm boasting at all.
> > > As if I would ever boast.
> >
> > Indeed, that is one reason why I generally prefer inform games to tads.
> > The base level of the parser, for a beginners game, is higher...
>
> Please do not make unqualified statements about opinions.
>
> TADS certainly handles the fourth one, and as far as I know the third.
> The second would require writing a translated library, but Graham is
> exaggerating for Inform, as it does there also. The first won't show up
> in the end game that you will play.
>
> The TADS Parser has its fans too, you know; for example, it has an extra
> stage of validation that often makes disambiguation work better. Both
> parsers are good.
All right, I should have phrased that, seems to be better, IMHO, at the
base level. I do like the multiple levels of undo TADS provides, and the
html support. I guess I'm still a little ticked at one of the comp tads
games that didn't have the word "it" implemented...
Graham Nelson
<URL:mailto:gla...@iname.com> wrote:
> > > > ; 4+PotPlant.water(cold_water, times++)
> > > > nimm den frosch von ihm
> > > > set the alarm to quarter to 6
> > > > write "Hello, Sailor!" on the blackboard
> TADS certainly handles the fourth one, and as far as I know the third.
But of course. Infocom's parsers could not, however.
> The second would require writing a translated library, but Graham is
> exaggerating for Inform, as it does there also.
It doesn't, though, because there is a choice of two excellent
German translations of Inform already in existence, one by
Ralf Herrman and another by Toni Arnold: and these have been
used to compile substantial games, including the German
translation of Advent as "Abentueur". There are complete
Spanish and Italian translations, too. Moreover the point of
the structure of the Inform parser is that it doesn't require
translating the library -- instead the same parser is used with
different language definition files, and its concepts of pronoun
and so forth are abstracted. So you only need to change the
tables of pronouns, articles and messages: you don't need to
change the library. And when a new library comes out, you don't
need to change a thing in the translation.
> The first won't show up
> in the end game that you will play.
Well, except by accident. Didn't one of this year's competition
games...?
> The TADS Parser has its fans too, you know; for example, it has an extra
> stage of validation that often makes disambiguation work better. Both
> parsers are good.
Yes indeed. And both are better than the core functionality of
Infocom's parser, and were developed independently of it, which
is really the point I was somewhat vaingloriously making.
TADS is excellent and I certainly wasn't saying anything to the
contrary.
John Elliott
>>> > nimm den frosch von ihm
>>> > set the alarm to quarter to 6
>>> > write "Hello, Sailor!" on the blackboard
> Get those Comp '00 entries ready, people.
Hmm... I can just see someone marking off each game on a little list:
Responds to XYZZY y/n
Responds to PLUGH y/n
Responds to PLOVER y/n
Responds to FEE FIE FOE FOO y/n
Responds to ZORK y/n
...
Responds to FROTZ y/n
Responds to REZROV y/n
...
Responds to TANGO y/n
Responds to WALTZ y/n
...
Responds to ; 4+PotPlant.water(cold_water, times++)
nimm den frosch von ihm
set the alarm to quarter to 6
write "Hello, Sailor!" on the blackboard
y/n
It's a good job we've got glulx, because soon a Z8 file won't be big
enough for all the stock responses to magic words.
(apologies if I omitted your favourite magic word :-) )
--
John Elliott
Gene Wirchenko
A pretty good list, but I didn't like the out the author gave
himself. The last responds to wasn't broken down into the four
separate commands: they were just lumped together. What about "y2"?
8.
David Glasser
Graham Nelson wrote in message ...
>> > > > ; 4+PotPlant.water(cold_water, times++)
>> > > > nimm den frosch von ihm
>> > > > set the alarm to quarter to 6
>> > > > write "Hello, Sailor!" on the blackboard
[snip my "TADS is good too" and Graham's "I know, that wasn't my point"
> The TADS Parser has its fans too, you know; for example, it has an extra
>> stage of validation that often makes disambiguation work better. Both
>> parsers are good.
>
>Yes indeed. And both are better than the core functionality of
>Infocom's parser, and were developed independently of it, which
>is really the point I was somewhat vaingloriously making.
>TADS is excellent and I certainly wasn't saying anything to the
>contrary.
Yes, I realize what you were saying. I wasn't responding to your message,
but
to this comment of Arcum Dagsson:
> Indeed, that is one reason why I generally prefer inform games to tads.
> The base level of the parser, for a beginners game, is higher...
This, I do disagree with, to some degree. Certainly I understand
what *you* were saying.
--David Glasser
John Elliott
> What about "y2"?
Well, as the Very Big Cave Adventure would say, ynot?
--
John Elliott
Rick Litherland
> [snip main discussion in favour of a side issue]
> I guess I'm still a little ticked at one of the comp tads
> games that didn't have the word "it" implemented...
Could you be a little more specific? I don't know about the other 11
TADS authors, but I'm thinking "Does he mean my game? And what
exactly does he mean by not implemented?" Any TADS game
implements the word `it' to some extent[1]: by default, the parser takes
`it' to refer to the direct object of the last command. Sometimes that's
not the right thing to do; the library will catch some of these, but not
all. You presumably found some (many?) cases the author didn't deal with;
they may or may not be easy to fix. I'm aware of some places in _Erehwon_
where the game won't understand perfectly reasonable uses of `it';
some I've now fixed, others I haven't figured out how to. There may be more
I'm not aware of, and I'd like to know about it if you've found them.
While I'm on the subject, maybe somebody can help. Consider the following
exchange:
>OPEN BOX
Opening the steel box reveals a four-sided die.
>CLOSE IT
Closed.
>OPEN BOX
Opening the steel box reveals a four-sided die.
>EXAMINE IT
It's a small steel box with a coat of arms painted on the lid, and seems to be
exceptionally well-made. It's open, and contains a four-sided die.
>NO, YOU FOOL, EXAMINE THE FERSHLUGGINER DIE!
[Response suppressed as too embarrassing]
Does anyone know of a way to deal with this? I'm not asking for a general
algorithm to decide what the player means by `it' in every case; what I'm
asking about is how to write TADS code to handle those cases that I _have_
noticed.
Perhaps this has all been thoroughly discussed already. If so, my apologies,
and could you point me to the right thread? Thanks,
Rick.
[1] I suppose this ain't necessarily so; you could deliberately arrange
for `it' not to be recognised, but I can't imagine why.
--
----------------------------------------------------------------
--- Rick Litherland : rali...@bellsouth.net ---
--- "Je voudrais que le dernier des rois fut ---
--- etrangle avec les boyaux du dernier pretre." ---
--- Jean Messelier, 1733 ---
----------------------------------------------------------------
Andreas Larsson
> Opening the steel box reveals a four-sided die.
>
>>EXAMINE IT
> It's a small steel box with a coat of arms painted on the lid,
> and seems to be
> exceptionally well-made. It's open, and contains a four-sided die.
The problem I see here, is not the coding
(I'm not even gonna think about how to do that),
but the players thoughts. It's impossible for the game to know
if the player would like to continue fiddeling with the box or
with the things inside the box. Consider if there are, let's say,
three things in the box. Should 'it' then refer to the box, but
refer to the die if the die is the only thing in the box.
For now, I like it the way it is.
/Andreas "Menur Seldrim" Larsson
Stephen Granade
> While I'm on the subject, maybe somebody can help. Consider the following
> exchange:
>
> >OPEN BOX
> Opening the steel box reveals a four-sided die.
>
> >CLOSE IT
> Closed.
>
> >OPEN BOX
> Opening the steel box reveals a four-sided die.
>
> >EXAMINE IT
> It's a small steel box with a coat of arms painted on the lid, and seems to be
> exceptionally well-made. It's open, and contains a four-sided die.
>
> >NO, YOU FOOL, EXAMINE THE FERSHLUGGINER DIE!
> [Response suppressed as too embarrassing]
>
> Does anyone know of a way to deal with this? I'm not asking for a general
> algorithm to decide what the player means by `it' in every case; what I'm
> asking about is how to write TADS code to handle those cases that I _have_
> noticed.
The function "setit(obj)" will do what you're talking about. In the
box-opening code, call
setit(four_sided_die);
Stephen
--
Stephen Granade | Interested in adventure games?
sgra...@phy.duke.edu | Visit About.com's IF Page
Duke University, Physics Dept | http://interactfiction.about.com
T Raymond
>>OPEN BOX
>Opening the steel box reveals a four-sided die.
>
>>CLOSE IT
>Closed.
>
>>OPEN BOX
>Opening the steel box reveals a four-sided die.
>
>>EXAMINE IT
>It's a small steel box with a coat of arms painted on the lid, and seems to be
>exceptionally well-made. It's open, and contains a four-sided die.
This is all standard TADS handling. In the other hand, once the player
opens the box, if they examine the die, 'it' will refer to the die
intead of the box.
If you want to change this when the box is open, just use setit(obj)
in your open code, in this case setit(die). Personally I would find
that strange behaviour, but that might just be me.
Anyway, this is off the top of my head, so please look setit up in
your manual to make sure I've got it right. Hope this helps.
Tom
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Tom Raymond adk @ usa.net
"The original professional ameteur."
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ross Presser
>>>EXAMINE IT
>>It's a small steel box with a coat of arms painted on the lid, and
>>seems to be exceptionally well-made. It's open, and contains a four
>>-sided die.
>
>This is all standard TADS handling. In the other hand, once the player
>opens the box, if they examine the die, 'it' will refer to the die
>intead of the box.
>
>If you want to change this when the box is open, just use setit(obj)
>in your open code, in this case setit(die). Personally I would find
>that strange behaviour, but that might just be me.
>
>Anyway, this is off the top of my head, so please look setit up in
>your manual to make sure I've got it right. Hope this helps.
>
If you do change "it" from the box to the die by means of code, make SURE
the text makes that die seem damned interesting, so the player isn't
surprised by the change:
>OPEN BOX
You open the box, and discover a wildly colored, fabulously interesting
die. Wow! You've never seen such a fascinating die!
>ROLL IT
(taking the die)
The die comes up a nine. Oh, did I mention it's a twelve-sided die?
--
Ross Presser
ross_p...@imtek.com
"And if you're the kind of person who parties with a bathtub full of
pasta, I suspect you don't care much about cholesterol anyway."
Andrew Plotkin
> alt.disting...@see.the.sig (T Raymond).wrote.posted.offered:
>
> If you do change "it" from the box to the die by means of code, make SURE
> the text makes that die seem damned interesting, so the player isn't
> surprised by the change:
>
>>OPEN BOX
>
> You open the box, and discover a wildly colored, fabulously interesting
> die. Wow! You've never seen such a fascinating die!
>
>>ROLL IT
> (taking the die)
>
> The die comes up a nine. Oh, did I mention it's a twelve-sided die?
I'd still be surprised by the change. I expect "it" to refer to the last
thing *I* mentioned, not the last thing the game mentioned, in all
circumstances.
Ideally, make this a player option.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Lucian Paul Smith
: Ross Presser <rpre...@nospamimtek.com.invalid> wrote:
: >>OPEN BOX
: >
: > You open the box, and discover a wildly colored, fabulously interesting
: > die. Wow! You've never seen such a fascinating die!
: >
: >>ROLL IT
: > (taking the die)
: >
: > The die comes up a nine. Oh, did I mention it's a twelve-sided die?
: I'd still be surprised by the change. I expect "it" to refer to the last
: thing *I* mentioned, not the last thing the game mentioned, in all
: circumstances.
This has indeed come up before, though I'm not up to searching deja right
now trying to use the keyword 'it' ;-)
There was no clear consensus, but I think we agreed that at the very
least, having 'it' always refer to the last thing the player typed is
consistent, and therefore easier for the player to figure out, even if
they get bitten a couple times.
It was also proposed that perhaps a new word be introduced for this
situation: 'that'.
>EXAMINE BOX
The metal box has a hinged lid.
>OPEN IT
Opening the box reveals a die.
>EXAMINE THAT
The die is a red six-spot.
It should also be noted that Inform will, by default, shift 'it' around
constantly to behave like the proposed 'that' above. If you do not want
this behavior, you must include:
Constant MANUAL_PRONOUNS;
at the beginning of your code.
-Lucian
Richard Litherland
> Rick Litherland <rali...@bellsouth.net> writes:
>
> > While I'm on the subject, maybe somebody can help. Consider the following
> > exchange:
> > [snip example]
(Pine refuses to let me post a message with more included text than new
text.)
> The function "setit(obj)" will do what you're talking about. In the
> box-opening code, call
>
> setit(four_sided_die);
>
Sorry, I didn't make myself clear. If I do `setit(four_sided_die)', then
>CLOSE IT
will be taken as a request to close the die. Generally, the meaning of
`it' is fixed before the parser starts to interpret a command, either by
the default rule or by a call to `setit()'. I'm wondering if there's any
way to have the meaning of `it' depend on the command currently being
parsed, so that >CLOSE IT will close the box, but >EXAMINE IT will examine
the die. (As Andreas Larsson has pointed out, maybe that's not the right
response here, but for the sake of argument suppose it is.)
Rick.
--
----------------------------------------------------------------
--- Rick Litherland : lit...@marais.math.lsu.edu ---
----------------------------------------------------------------
Stephen Granade
> On 23 Nov 1999, Stephen Granade wrote:
>
> > Rick Litherland <rali...@bellsouth.net> writes:
> >
> > > While I'm on the subject, maybe somebody can help. Consider the following
> > > exchange:
> > > [snip example]
> (Pine refuses to let me post a message with more included text than new
> text.)
> > The function "setit(obj)" will do what you're talking about. In the
> > box-opening code, call
> >
> > setit(four_sided_die);
> >
>
> Sorry, I didn't make myself clear. If I do `setit(four_sided_die)', then
>
> >CLOSE IT
>
> will be taken as a request to close the die. Generally, the meaning of
> `it' is fixed before the parser starts to interpret a command, either by
> the default rule or by a call to `setit()'. I'm wondering if there's any
> way to have the meaning of `it' depend on the command currently being
> parsed, so that >CLOSE IT will close the box, but >EXAMINE IT will examine
> the die.
Short answer: yes, but it's complex to do.
Long answer: you're going to have to monkey around with the parsing
routine. One possibility is to hack preparse(). You can search for
"it" and replace it with the object you wish "it" to refer to, or call
setit() with the proper object.
Arcum Dagsson
<rali...@bellsouth.net> wrote:
> arcum_...@hushmail.c.o.m (Arcum Dagsson) writes:
>
> > [snip main discussion in favour of a side issue]
> > I guess I'm still a little ticked at one of the comp tads
> > games that didn't have the word "it" implemented...
>
> Could you be a little more specific? I don't know about the other 11
> TADS authors, but I'm thinking "Does he mean my game? And what
> exactly does he mean by not implemented?" Any TADS game
> implements the word `it' to some extent[1]: by default, the parser takes
> `it' to refer to the direct object of the last command. Sometimes that's
> not the right thing to do; the library will catch some of these, but not
> all. You presumably found some (many?) cases the author didn't deal with;
> they may or may not be easy to fix. I'm aware of some places in _Erehwon_
> where the game won't understand perfectly reasonable uses of `it';
> some I've now fixed, others I haven't figured out how to. There may be more
> I'm not aware of, and I'd like to know about it if you've found them.
>
Well, this particular game had to do some tinkering with the library, most
likely, and most people weren't likely to be fiddling with the word 'it',
so I can see how it was missed.
The game was Exhibition. Any use of the word it, produces 'I don't know
the word "it"'. Mind you, I still think it was a pretty good game, but the
bug was still irritating[1].
[1] It's also rather irritating, on second thought, that I failed to send
a bug report, and just threw it forth here. Sorry about that. I've been a
bit on edge lately, since I've been trying to get my other computer back
online. (Just got it working again, BTW...)
Rick Litherland
> This has indeed come up before, though I'm not up to searching deja right
> now trying to use the keyword 'it' ;-)
>
> There was no clear consensus, but I think we agreed that at the very
> least, having 'it' always refer to the last thing the player typed is
> consistent, and therefore easier for the player to figure out, even if
> they get bitten a couple times.
>
I sense a fairly clear consensus now. If I may summarise, what I was asking
how to do is:
(a) possible, but technically tricky (Stephen Granade);
(b) a bad idea anyway (everybody with an opinion on the matter).
I'm sure Stephen is right on (a), and I now agree with (b). Thanks, all, for
helping to set me straight.
Rick.
--
----------------------------------------------------------------
David Glasser
> It should also be noted that Inform will, by default, shift 'it' around
> constantly to behave like the proposed 'that' above. If you do not want
> this behavior, you must include:
>
> Constant MANUAL_PRONOUNS;
>
> at the beginning of your code.
For what it's worth, I wrote a module, ManPro.h, that lets the user (not
the author) decide whether to use it or not; it's in
/if-archive/infocom/compilers/inform6/library/contributions. Of course,
it's tailored to library 6/7 and is somewhat confusing as it really
should have allowed the player to toggle *automatic* pronoun assignment,
not manual assignment which is really just the lack of a feature. Oh
well.
--
David Glasser | gla...@iname.com | http://www.davidglasser.net/
rec.arts.int-fiction FAQ: http://www.davidglasser.net/raiffaq/
"Maybe Glulxification will cause people to start using Scheme for IF. Or
maybe not. Anyhow, I just like saying 'Glulxification'." -andyf on ifMUD
T Raymond
>For what it's worth, I wrote a module, ManPro.h, that lets the user (not
>the author) decide whether to use it or not; it's in
>/if-archive/infocom/compilers/inform6/library/contributions. Of course,
>it's tailored to library 6/7 and is somewhat confusing as it really
>should have allowed the player to toggle *automatic* pronoun assignment,
>not manual assignment which is really just the lack of a feature. Oh
>well.
>
And just for the sake of silly, this post contained 5 instances of the
word 'it' ;)
Tom (needs some sleep)