NPC Conversation ideas

11 views
Skip to first unread message

michael...@ey.com

unread,
Aug 3, 1998, 3:00:00 AM8/3/98
to
I've been trying to hammer out a way to make NPC conversation more context
sensitive -- that is, I would like NPC responses to vary based upon what
you've already asked and/or shown them.

Actually coding responses would be a matter of capturing instances with
if/then and switch statements. What I'm really searching for are ideas on how
to store the information simply & efficiently.

I've already come up with one idea. First, make conversation topics objects
in their own right. Then, assign each NPC and each topic a value, then create
a 2-dimensional array with a slot for each NPC cross-indexed to each topic.
Each position can contain a 1 or a 0 to indicate whether or not you have
asked the NPC about that particular topic -- or, if you want to get really
sneaky, the position can contain an integer indicating *how many times*
you've asked the NPC about it.

If anyone can think of a better or easier way to do it, I'd love to hear your
ideas. Also, if you see potential problems with the method above, please point
them out.

Here's another thing to chew over: I played a game once where ASK and TELL
were disabled, and all NPC conversation syntax worked thusly:

> BOB, <x>

...which essentially meant, "Ask/Tell/Converse with Bob about <x>."

So NPC interaction looked a bit like:

> BOB, HOLLYWOOD
"A filthy den of target-audience marketing and mediocrity," Bob says sullenly.
"There hasn't been a decent movie out of Hollywood in twenty years."

> BOB, WOODY HARRELSON

"Now there's a fine actor," Bob notes, perking up a bit. "Did you ever see
'The People vs. Larry Flynt'? Amazing movie, not like most."

> BOB, HAND ME THAT SPOON
Bob has better things to do.

The idea was that, although it breaks mimesis somewhat, it's easier on the
fingers, since you don't have to type "ASK BOB ABOUT whatever" over and over
again.

What do you think about that format? Good or bad? Would you rather just type
it all out, or does the shortcut appeal to you? There's also the clever
shortcut used in "She's Got a Thing For a Spring," where you typed in ASK MAN
ABOUT something, and in subsequent commands you simply typed in the topic and
nothing else, like so:

> ASK BOB ABOUT UFOS
"Oh, I do believe they exist," Bob says earnestly. "There's no question that
intelligent life exists apart from this planet."

> ROSWELL
"Keep your voice down," Bob whispers. "The government doesn't want anyone to
know about that."

> GOVERNMENT
Bob says nothing; he just lays finger alongside his nose and winks at you.

How well did that work for people?

I write in Inform exclusively, but comment from TADS people are welcome too.
Basically, I'd love to hear any discussion about NPC interaction that doesn't
involve a tree vs. ask/tell debate.

--
--M.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum

Richard G. Clegg

unread,
Aug 3, 1998, 3:00:00 AM8/3/98
to
In article <6q4rng$gn1$1...@nnrp1.dejanews.com>, michael...@ey.com wrote:
>I've been trying to hammer out a way to make NPC conversation more context
>sensitive -- that is, I would like NPC responses to vary based upon what
>you've already asked and/or shown them.
>
>Actually coding responses would be a matter of capturing instances with
>if/then and switch statements. What I'm really searching for are ideas on
>how to store the information simply & efficiently.

Well, one nice (but rarely used in my experience) method would be to
have some sliding scales which modify the characters responses slightly.

For example, you could have an int from 0-10 representing how
angry the character is then code like this (pseudo-code, while
since I used inform):

if (anger < 3) print "`Sure, I can tell you about that' says the barman."
else if (anger < 7) print "`Hmph... well, I suppose I could tell you
about that' grunts the barman."
else { print "`I really don't see that's any of your business.';
return;
}
print (exciting scene setting information/hint/whatever).

This way, you get a little bit of a feeling that your actions are
affecting people (in a minimal way). If you want some example inform
code then mail me.

If you want to avoid repeating too much code but avoiding having
characters repeat themselves, you might also like to consider wrapping
it all up in a function such as (pseudo code, not inform again, sorry -
code is intended to be demonstrative, not to work or provide an
example of "good code"):

#define BAR_MAN_BEER 0
#define BAR_MAN_BAR 1
#define BAR_MAN_STUFF 2

void bar_guy_speaks (int topic)
{
static int repeat_count[3]= {0,0,0};

if (repeat_count[topic] > 3) {
print_rejection(); /*Function which will print something along the
lines of "I already told you about that */
return;
}
if (repeat_count[topic] > 0)
print_already_said(); /*Function which will print something like
"I already told you but I'll tell you again" */
repeat_count[topic]++;
if (topic == BAR_MAN_BEER) {
print "It's very nice beer.\n";
return;
}
.
.
.
}

>The idea was that, although it breaks mimesis somewhat, it's easier on the
>fingers, since you don't have to type "ASK BOB ABOUT whatever" over and over
>again.

I like this idea. For me, there's nothing "realistic" about repeatedly
typing "ASK X about Y" so I don't really see that it "breaks mimesis"
in any case.

>I write in Inform exclusively, but comment from TADS people are welcome too.
>Basically, I'd love to hear any discussion about NPC interaction that doesn't
>involve a tree vs. ask/tell debate.

I think there's a lot more that can be done with the inform system.
If you want to avoid characters repeating important speeches too
often then you could "wrapper" any large chunks of "set text" in a
function like the one above. I think a lot can be done with just one or
two "state variables" for each NPC which affect how they talk and react.
It's also nice if the NPC has some kind of "waiting" behaviour that
they exhibit and which changes depending on the state variable. For
example, the barman above might have the following code

if (anger <3) {
switch random (10):
case (1):
print ("The barman whistles and looks about.");
return;
case (2):
print ("The barman beams happily and polishes a glass or two.");
return;
default:
return;
}
.
.
.
if (anger > 7) {
switch random (10):
case (1):
print ("The barman stares at you and mumbles something. His
ears have turned a curious red colour.");
return;
case (2):
print ("The barman rubs furiously at a dirty glass which
suddenly breaks with a sharp `crack'.");
return;
default:
return;
}

Fiddle with the frequencies of these random messages depending on how
long the player will be with the NPC - if they're going to spend the
game together then the messages will quickly become repetative unless
there's a lot of them or they're only very occasional.

If you do take this route, then you'll find that players will quickly
work out that the character is becoming annoyed and sometimes, actually
try to provoke them further. So you could code for this eventuality:

if (anger > 10) {
print ("`Right, you bugger, you're banned from my pub,' roars
the barman as he muscles you toward the door.");
player.location= TheStreet;
return;
}

If you can predict something that players will try thinking its
"silly but worth trying" then your NPC will seem more convincing.

Well, just my few pennies worth anyway. Not that I ever actually
finished writing an adventure game so I may not be the best person
to ask.

--
Richard G. Clegg Mind is a pattern perceived by a mind
Dept. of Mathematics (Network Control group) Uni. of York.
email: ric...@manor.york.ac.uk
www: http://manor.york.ac.uk/top.html

jdb...@my-dejanews.com

unread,
Aug 3, 1998, 3:00:00 AM8/3/98
to
In article <6q4rng$gn1$1...@nnrp1.dejanews.com>,
michael...@ey.com wrote:
> I've been trying to hammer out a way to make NPC conversation more context
> sensitive -- that is, I would like NPC responses to vary based upon what
> you've already asked and/or shown them.
>
>
> Here's another thing to chew over: I played a game once where ASK and TELL
> were disabled, and all NPC conversation syntax worked thusly:
>
> [snip]

Why not have a question mark ending any statement from which you are seeking a
reply? Anyone in the room (active, hidden, whatever) is free to answer as
he/she/it sees fit. Usually there will be only one person there, so that's
fine. If the area has more than one NPC, whoever is listening in can comment.

(Only one being in the room with the player)
PUB
Bartender is here

> Mabel?

"I sent her home, there have been no customers all night."

(Only one visible being in the room with the player)
PUB
Bartender is here

> Mabel?

A man in a trench coat steps out of a booth from the dark side
of the pub. "I've been looking for anyone who knows Mabel."

(Several beings in the room)
PUB
Bartender is here, and a small group of customers are enjoying
drinks and socializing.

> Mabel?

"Hahahaha, *HIC!* This guy's l-l-looking for "Maybe" Mabel. She
turned me down, pal, so she... so she has to turn YOU down... *HIC!*"
The drunken customer then pukes on your shoes.


This would make "ask bartender about Mabel" a (more) private conversation, but
in real life basic conversations are usually open. In fact, you might draw
attention to yourself by whispering or requesting a private conversation.
Depending on the situation, of course, what level of communication does the
player choose? Bwahahaha. :-)


But putting a simple ? after a statement would be an easy way to query, from
look ("look at bird" now becomes "bird?") to ask. Both would have the subtle
implications discussed, with look? being more of a pondering type of look.
What use this may have to anyone could range from annoying semantics to real
game mechanics.

thoughts? ;-)

Jimbo

Roger Carbol

unread,
Aug 3, 1998, 3:00:00 AM8/3/98
to
michael...@ey.com wrote:

> Actually coding responses would be a matter of capturing instances with
> if/then and switch statements. What I'm really searching for are ideas on how
> to store the information simply & efficiently.

You're essentially looking for some flavour of state machine. One
method might be "emotions", for example, let's say the NPC has a single
emotion called Happiness which starts at 5 and can vary between
1 (not happy at all) to 9 (cloud 9, actually.)

When asked about any given topic, the NPC yields a response based on
the current Happiness level. His Happiness may also change; it
could be a function merely of the topic, or also a function of the
topic and the current Happiness level (providing a bit of a feedback
loop which is often helpful.)

You'll also want some way to let the player know what the NPC's
emotional state is. Or perhaps not.

.. Roger Carbol .. rog.shaw.wave.ca .. i feel free

TenthStone

unread,
Aug 3, 1998, 3:00:00 AM8/3/98
to
ric...@manor.york.ac.uk (Richard G. Clegg) caused this to appear in our collective minds on 3 Aug 1998 18:11:25 GMT:

>In article <6q4rng$gn1$1...@nnrp1.dejanews.com>, michael...@ey.com wrote:
>>I've been trying to hammer out a way to make NPC conversation more context
>>sensitive -- that is, I would like NPC responses to vary based upon what
>>you've already asked and/or shown them.
>>
>>Actually coding responses would be a matter of capturing instances with
>>if/then and switch statements. What I'm really searching for are ideas on
>>how to store the information simply & efficiently.

Hmm... efficiency is something you may have a problem with. The array would
be an idea... you could declare a function which returned the pointer of a certain
conversation topic, and then increment/check the isasked[] array for the NPC.
The difficultry would be that each conversation topic would then need to be
assigned a number (using object pointers might be a way around this, but then
again in terms of array storage that would be VERY inefficient) which would
be tagged by an enormous switch statement in our function. Alternatively, the
function could be highly optimized for each actor:

topicPointer: function( actor, subject ) {
switch( actor ) {
Bob:
switch (subject ) {
greenmask: return 1;
greensuit: return 2;
default: return nil;
}
Jane:
etc.
}

> Well, one nice (but rarely used in my experience) method would be to
>have some sliding scales which modify the characters responses slightly.

The problem with this is interaction and realistically defining psychology
in terms of this. Furthermore, there need be multiple sliding
scales, such as: angerAtPlayer, angerAtBob, angerAtJane, angerAtLife
-- and then anger would be a method combing these. Iki.

> For example, you could have an int from 0-10 representing how
>angry the character is

... [snip]

> This way, you get a little bit of a feeling that your actions are
>affecting people (in a minimal way). If you want some example inform
>code then mail me.

Yes, but then again one might want more than one scale -- anger, happiness,
generosity -- and they would all interact. Trouble, trouble, trouble

>>The idea was that, although it breaks mimesis somewhat, it's easier on the
>>fingers, since you don't have to type "ASK BOB ABOUT whatever" over and over
>>again.
>
> I like this idea. For me, there's nothing "realistic" about repeatedly
>typing "ASK X about Y" so I don't really see that it "breaks mimesis"
>in any case.

I can see how it does. The idea is that a transcript should be understandable
at any point in its reading, independantly (or nearly so) of past paragraphs.
And there is a reason why we "ask Tom about cabin": the fantasy is that the
player is talking to the computer, which carries out the request and reports back
to the player.
But, if you want to program in more realstic conversation, simply write a more
complicated parsing routine. (simply...)

The Main Room of the Amazingly Large House
This is amazing main room of an amazingly large house. In the northern
corner is an amazingly little hole, over which is a sign reading "Mus musculus". To the
southeast is a little stand.
>what is mus musculus?
I'm not sure.
>x stand
No, the stand's to the southeast; you should go there first.
>se
Outside a Maze by Amazing Bob
There is a little stand here, behind which sits Amazing Bob. To the east is a maze.
>Bob, what is mus musculus?
Amazed, Bob replies, "But Mus musculus is only the amazing scientific name for the
Amazonian amazing house mouse!"
>Bob, how are you?
Amazed, Bob replies, "I feel amazingly good!"
>Bob, how do you solve the maze?
Amazed, Bob replies, "I'm not going to tell you that!"

The parsing routine would need to check the question against several templates:
"what is thing" "how is thing" "why does thing verb" "why is thing adjective" "how does one verb (the thing)"
"how do I verb (the thing)" "how do you verb (the thing)" "who is thing" "when is thing" "where is thing"
"when does thing verb" "where does thing verb" "how does thing verb".

And then call the right methods:
whatIs( thing ) (same as whoIs)
whenIs( thing )
whereIs( thing )
howIs( thing )
whyIs(thing, adjective)
whyDoes( thing, verb ) (same as howDoes)
howTo( verb, thing ) (optional thing)
whenDoes( thing, verb )
whereDoes( thing, verb )

-----------

The inperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us

Jonadab the Unsightly One

unread,
Aug 3, 1998, 3:00:00 AM8/3/98
to

michael...@ey.com wrote in article <6q4rng$gn1$1...@nnrp1.dejanews.com>...

> I've been trying to hammer out a way to make NPC conversation more
context
> sensitive -- that is, I would like NPC responses to vary based upon what
> you've already asked and/or shown them.

A good aim, IMO.

> Actually coding responses would be a matter of capturing instances with
> if/then and switch statements. What I'm really searching for are ideas on
how
> to store the information simply & efficiently.

You touch below on something similar to what I am doing.



> I've already come up with one idea. First, make conversation topics
objects
> in their own right.

This seems to me to be the only good way to allow anything very advanced
in terms of conversation.

> Then, assign each NPC and each topic a value, then create
> a 2-dimensional array with a slot for each NPC cross-indexed to each
topic.

Good idea, although I have done it differently -- each NPS has his
own topics, so no array is needed -- but it is the same idea.

> Each position can contain a 1 or a 0 to indicate whether or not you have
> asked the NPC about that particular topic -- or, if you want to get
really
> sneaky, the position can contain an integer indicating *how many times*
> you've asked the NPC about it.

I have this information in two stages -- how many times the NPC has given
a generally-available response to this topic, and how many times he has
given extra information only available under certain circumstances. Since
the conversation topic objects are external to the game otherwise, they
can use many of their common properties in non-standard ways, so I have
chosen one prop for each of these values, one for a routine to print the
next response (using a switch statement), and one for a routine to
determine
whether or not the NPC is willing to do so. This is actually a
simplified explanation of what I have done, but you get the idea.

I am also very strong on the idea (not too big on the practice yet, but
hopefully I will get there, so ideas are appreciated here) of coding up
a lot of grammar to allow more natural sentences than
> NPC, tell me about foo.

One thing I have done is to fix
> Listen to the NPC
to map to <<AskAbout NPC most_recent_topic>>;

There is also the traditional
> NPC, who/what/where/when is/are whatever.

Any more ideas?

How about a context-sensitive
> NPC, why?

> Here's another thing to chew over: I played a game once where ASK and
TELL
> were disabled, and all NPC conversation syntax worked thusly:
>

> > BOB, <x>

Not sure I care for this. Seems just like
>USE EVERYTHING
to me. Too inspecific.

> There's also the clever
> shortcut used in "She's Got a Thing For a Spring," where you typed in ASK
MAN
> ABOUT something, and in subsequent commands you simply typed in the topic
and
> nothing else, like so:
>
> > ASK BOB ABOUT UFOS
> "Oh, I do believe they exist," Bob says earnestly. "There's no question
that
> intelligent life exists apart from this planet."
>
> > ROSWELL
> "Keep your voice down," Bob whispers. "The government doesn't want anyone
to
> know about that."
>
> > GOVERNMENT
> Bob says nothing; he just lays finger alongside his nose and winks at
you.
>
> How well did that work for people?

Okay if it is optional, but I would not want the parser to reject
> ASK BOB ABOUT ROSWELL
just because you already typed ASK BOB ABOUT once.

> Basically, I'd love to hear any discussion about NPC interaction that
doesn't
> involve a tree vs. ask/tell debate.

What about ask/tell vs. more complicated grammar

Instead of

>Bob, tell me about Joe
you would have
>Bob, have you met Joe?

Instead of
>Ask Bob about his aunt
or
>Bob, tell me about your aunt

it would be

>Bob, do you have any relatives
"Oh, sure, but only one aunt that lives nearby."

>Bob, do you visit your aunt often?
"From time to time I do, yes. I went to see her
last tuesday, in fact."

>Bob, where does she live?
"Just across town."

>Bob, did you have a good time?

Of course, this sort of thing would require massive amounts
of work to avoid guess-the-syntax trouble.


Yr. Obd't & Humble Servant,
Jonadab the Unsightly One

----------------

Different expectations. Crash my Windoze laptop and I'll shrug, reboot
and carry on. Crash my Unix desktop and I'll dig out the debugger.
Crash my palmtop and I'll delete every application you've written from
my machines and *hate* you.

-- Bryan Scattergood

----------------

Send replies to username@isp, where username is jonadab
and isp is bright.net

The zerospam.com address works, but you get an ugly confirmation.

George Caswell

unread,
Aug 3, 1998, 3:00:00 AM8/3/98
to
On Mon, 3 Aug 1998 michael...@ey.com wrote:

> I've been trying to hammer out a way to make NPC conversation more context
> sensitive -- that is, I would like NPC responses to vary based upon what
> you've already asked and/or shown them.
>

> Actually coding responses would be a matter of capturing instances with
> if/then and switch statements. What I'm really searching for are ideas on how
> to store the information simply & efficiently.
>

Basically what you're trying to do is create a functional mapping from
a character's current state and some action directed at that character, to
a result and a new state for the character. I think if you make this a
switch statement or something you're going to be hurting. Design the
whole story, figure out all the possible states a character may wind up in
depending on what they're shown, determine the mapping from state and
action to new state and reaction. (A table's a good way to describe this
information, both on paper and in code)

> I've already come up with one idea. First, make conversation topics objects

> in their own right. Then, assign each NPC and each topic a value, then create


> a 2-dimensional array with a slot for each NPC cross-indexed to each topic.

> Each position can contain a 1 or a 0 to indicate whether or not you have
> asked the NPC about that particular topic -- or, if you want to get really
> sneaky, the position can contain an integer indicating *how many times*
> you've asked the NPC about it.
>

Where it gets tricky, of course, is when you want to use this
information. At the particular game state where you need to check the
information, exactly which state variables are relevant, and how... I
think this is a basic problem in any IF game that isn't bounded down to
simplicity- for any n things in the game that the player has control
over, the author should have forseen the n! combinations of who knows how
many actions and combinations...

I also think a single array for all characters is probably a bad idea.
It's probably better to let each NPC's code be responsible for its own
data.

> If anyone can think of a better or easier way to do it, I'd love to hear your
> ideas. Also, if you see potential problems with the method above, please point
> them out.
>

Make various aspects of a character's state be variables and pointers
to objects, as necessary. When a state changes, change the variable or
the object. Anything that changes when a state changes should be called
through one of the pointers. (For example, object Bill, with a pointer to
Happy-Bill. If you look at bill, you see Bill's description, and whatever
Happy-Bill has to say about Bill... that he's happy, for instance. If
you make bill sad, replace the reference to Happy-Bill with one to
Sad-Bill. It's one way that the state transitions could be done without
replacing objects altogether, and without a big, fat, ugly tree of if's.

I'd also suggest that you almost certainly don't want to write this
code before you design it.

---GEC


Joe Mason

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to
Barbara Robson <rob...@octarine.itsc.adfa.edu.aus> insribed:

>That seems a good idea. Something else that I've tried is to keep track of
>what the most recent topic of conversation was: if you ask Bob about the
>same thing twice in a row, he'll be likely to elaborate, and if you ask
>about something new, the previous question might help to define the context,
>if there might be a connection.

That would DEFINITELY make things more interesting! What general mechanism
do you use for this?

Here's my first thought: you need several data points for each actor.
(They can be implemented as properties, arrays, objects, etc. -
suggestions?) Two for each conversation topic: number of times it's been
asked about, how long since it's last been asked. Also several emotion
indexes: level of anger, level of fear, level of suspicion, etc.

Have a daemon or end-of-turn routine which will adjust all the emotions
back towards their starting point. That way if you get somebody mad at
you, it will fade over time. (Make sure it's possible to override this
behaviour in case you want a lasting grudge.) You'll need a routine like
this to increment the length of time since each topic's been asked anyway.

Then, when you ask somebody something, you would have a routine to check
their emotion levels. If, say, anger is high, it gives a snarky response.
If the topic has been asked recently, OR its been asked about a lot, give
a "Stop asking me about that!" response. Otherwise, something generically
irritated.

In general, the system would check emotion first, then recent conversation
topics (those with a low "time since last asked"), then frequent
conversation topics. There would be an algorithm which finds the "best"
response, out of the cases which the programmer has created individual
responses for.

For instance, if the player asks John about his wife, you could have
several responses in mind: "high supsicion level & just asked about the
murder" - assumes the player is trying to accuse his wife; "asked about
his wife many times" - accuses the player of being obsessed. It's
possible in a given situation for both of those to apply, so the main
algorithm would have to look at both and give one a priority.

Hmm... This seems like the perfect application for Rumil's "branch"
statement. What an odd coincidence...

Joe

GLYPH

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to
On Mon, 3 Aug 1998 okbl...@usa.net wrote:

> In article <6q4rng$gn1$1...@nnrp1.dejanews.com>,
> michael...@ey.com wrote:
>

> I see one potential problem:
>
> > ASK BOB ABOUT ALICE
> "Alice? Oh, yeah, didn't we go to high school with her?"
> > ASK BOB ABOUT ALICE
> "I don't recall--well, wait, wasn't she your girlfriend?"
> > ASK BOB ABOUT ALICE
> "Yeah, all right, I slept with her! It was along time ago."
> > ASK BOB ABOUT ALICE
> "Stop nagging me! I confessed already!" Bob hits you with a hoe.

Hee. Have any of you guys played Something About the Bunny? Try to keep
Uncle Ogdajon from making his photocopies.

Anyway, in my NPC libs, there is a simple first-order context in the form
of a "TalkTopic" variable, which I usually set like this:

>Bob, what did you do to that poor puppy dog?

[ Bob.talktopic = 'dog' ]

Bob says (to you), "Uh... nothing. Why?"

>Bob, Right. And monkeys might fly out of my butt.

Bob says (to you), "No, really!"

But if you wanted to have long-lasting topics, you could use my goal
system which is dynamically allocated (up to a limit set by the author).
You could have Goals like talk_about_dog or deny_using_dog_for_scrapple.
Then your NPC's could *actively* deny stuff.

>Bob, how are you?

Bob says (to you), "Oh, fine."

>Take book

Taken.
Bob says (to you), "I'm not on crack."


- GLYPH

E-Mail <y8...@unb.ca>
or <graham...@hotmail.com>

------------------

Shameless plug for my web page:
<http://www.geocities.com/CollegePark/9315>

LucFrench

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to
Glyph said:
>>Bob, how are you?
>
>Bob says (to you), "Oh, fine."
>
>>Take book
>
>Taken.
>Bob says (to you), "I'm not on crack."

I've seen that happen. (I won't say on what end, though.)

Thanks
Luc "Social Stigmata" French

Bob F.O.R. Apples

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to
GLYPH wrote in message ...

>Anyway, in my NPC libs, there is a simple first-order context in the form
>of a "TalkTopic" variable, which I usually set like this:
>


[snip]

Heya, this sounds great! Any idea when those libs might be avail?
thx
Bob

Lucian Paul Smith

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to
michael...@ey.com wrote:

: There's also the clever


: shortcut used in "She's Got a Thing For a Spring," where you typed in ASK MAN
: ABOUT something, and in subsequent commands you simply typed in the topic and

: nothing else.

Yes! I loved that. I'd love to see an Inform module with this in it
(hint, hint, Brent ;-)

If anyone's interested in how I parsed stuff for Stranger in Edifice, I
can send that around, too.

-Lucian

GLYPH

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to
On Tue, 4 Aug 1998, Bob F.O.R. Apples wrote:

> Heya, this sounds great! Any idea when those libs might be avail?
> thx
> Bob

Well, no. Not really. It's in beta right now. One or two bugs left ;)

Beta testers feel free to download it at
http://www.geocities.com/CollegePark/9315/gfinfo3b.zip

It has an INCOMPLETE tutorial with it, so it's not even the official beta
release. You may download and try this out AS LONG AS YOU DON'T USE IT IN
A GAME. This is only for your convenience, because it WILL be changed in
the official version and it will be rendered INCOMPATABLE with the current
beta version by the time it's finished. Well, probably, anyway.

It's for Inform, by the way.

- GLYPH

okbl...@usa.net

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to
In article <Pine.SOL.3.96.98080...@sol.sun.csd.unb.ca>,

GLYPH <y8...@unb.ca> wrote:
>
> Hee. Have any of you guys played Something About the Bunny? Try to keep
> Uncle Ogdajon from making his photocopies.
>

Haven't. Will try.

> Anyway, in my NPC libs, there is a simple first-order context in the form
> of a "TalkTopic" variable, which I usually set like this:
>

You're re-vamping a lot of Inform stuff, I see. I hope you have plenty of
examples of how this stuff works!!

[ok]

IF

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to
There's an idea I've been working with, and this would seem the thread to test
it out. The idea is letting your character interact on his or her own when you've
started a conversation, based on things you've done before. For example:

>ASK BOB ABOUT LAVERNE

"Oh, she's a cute thing, if a little saucy. What do you think of her?" he
asks.

"Saucy's one word for it," you say, remembering her behavior last time you
were around. "Have you seen her recently?"

"Laverne?" Bob asks. "Sure, I caught her in bed with my son not an hour ago.
I strangled her."

You stare at mild-mannered, always-there-when-ya-need-him Bob, your mouth open
in shock.

"Is there something wrong?" he asks patiently.

You faint.


In this manner, you would start a dialogue, but your character would carry it out,
using sensible phrases. It could also be used to clarify meaning, that is to
present and actual question ("Where is the key") as opposed to an abstraction
("Ask Bob about key"). ex:

>ASK BOB ABOUT MURDER

"But why did you do it?" you ask.

"Hey, no prissy little city girl is going to get her claws into my Tommy," he
says gruffly.


I haven't explained the concept very well, since my brother is playing Whitesnake
in the next room and seriously disturbing my synaptic processes, but do you think
this idea would fly?

Ian Finley


michael...@ey.com

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to
In article <35C7AB53...@ix.netcom.com>,

IF <mord...@ix.netcom.com> wrote:
>
> I haven't explained the concept very well, since my brother is playing
Whitesnake
> in the next room and seriously disturbing my synaptic processes, but do you
think
> this idea would fly?
>

I think the main pitfall you'd have to watch out for is doing *too* much for
the player. Remember that discussion awhile back about implicit actions and
the exploding jacket?

Used judiciously, though, I think it would be very effective -- particularly
if you really made it contextual.

And what's wrong with Whitesnake?

--
--M.

Mark J Musante

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to
IF (mord...@ix.netcom.com) wrote:
> I haven't explained the concept very well, since my brother is playing Whitesnake
> in the next room and seriously disturbing my synaptic processes, but do you think
> this idea would fly?


I used this idea throughout my cyoa game. I think it would work well in a
"traditional" IF game too.


-=- Mark -=-

Brent VanFossen

unread,
Aug 5, 1998, 3:00:00 AM8/5/98
to
On 4 Aug 1998 16:48:37 GMT, lps...@rice.edu (Lucian Paul Smith)
wrote:

>: There's also the clever
>: shortcut used in "She's Got a Thing For a Spring," where you typed in ASK MAN
>: ABOUT something, and in subsequent commands you simply typed in the topic and
>: nothing else.
>
>Yes! I loved that. I'd love to see an Inform module with this in it
>(hint, hint, Brent ;-)

Bob looks up from his sweeping and peers over his broom at you. A
smile of recognition crosses his face.

"Hey, stranger," he says with a chuckle. "It's been a few months.
How're you doing?"

>Ask Bob about Brent

"I see him now and then," Bob replies, "but he's buried in Real Life
at the moment. New job and all. And still trying to take those
pictures."

>Inform module

"Last I 'member, he was tidying the code. MY code. Messin' with all
the critters. Fixing up the bugs and the Bugs, if you know what I
mean. Blackberries stay where they're supposed to, now. Flip flops,
too." Bob knocks a few stones off the porch with the broom.

>Inform module

"Oh, yeah. Right. I think he promised a few people last winter that
he would do something like that." Bob looks around uneasily.

>Inform module

"Okay, already. Okay," he says, shaking his head. "So he's been a
little slow with that. Truth be told, he'd like to see some other
folks respond like I do." Bob laughs out loud at the thought.

"I'll mention it to him," he says with a smile.

>Inform module

"That's enough of that. One more time and I'll serve up some
strawberry shortcake MY way." Bob grins. "No. Don't even think about
it.

"Tsa ben ne salum," Bob says proudly, and disappears into his cabin.


Brent VanFossen


Brent VanFossen

unread,
Aug 5, 1998, 3:00:00 AM8/5/98
to
On 4 Aug 1998 16:48:37 GMT, lps...@rice.edu (Lucian Paul Smith)
wrote:

>If anyone's interested in how I parsed stuff for Stranger in Edifice, I


>can send that around, too.

I am. Stranger was a terrific character. I think I liked most the
interplay between Stranger and the player. There was no way to
complete that interaction until you understood most of what he was
saying.

From a coding point of view, I'm particularly interested in the way
you handled the punctuation in the player's input.

Brent VanFossen

OFDown

unread,
Aug 5, 1998, 3:00:00 AM8/5/98
to
I've been working on some NPC interactions with more than one NPC in the room.
The situation is this: If you speak without direction, any or all characters
may reply. If you direct, the directed character replies and for convieniece,
following undirected questions are answered by the same character.

Example:

You are in a room with Joe and Bob.

>how are you

Bob says, "Great!"
Joe says, "Not too good. I've got something in my hair an it iches like
crazy."

You notice now that there appears to be some large mammal on Joe's head.

>Bob, What is in Joe's hair

Bob says, "I don't rightly know. It's been growing there for weeks."

>what is in your hair

Bob says, "Well, I certainly hope there's nothing there, though I suppose it
could be catchy."


My problem is that I can not decide on a good syntax for addressing the entire
room again. Once I've directed to a character, I'm stuck in private
conversations.
For instance, maybe now I want to say:

>find a hoe

Joe digs in his hair and much as he digs for a hoe.
Bob searches the tools for a hoe.

This is the effect I might want although the syntax given would "remember" that
I was talking to Bob and only direct him to search for a hoe.

If possible, I would like to keep the convienience of remembering the last
addressed NPC while still being able to address both if I choose.

For completion:

Bob holds a hoe up in triumph.

>Bob, hit that thing with the hoe

Bob takes a mighty swing with the hoe, knocking the beast from Joe's head and
onto your own.

Your head begins to itch.

Trig
--
"This may look like a slab of liver, but really, it's an external brain pack!"

Den of Iniquity

unread,
Aug 5, 1998, 3:00:00 AM8/5/98
to
On Tue, 4 Aug 1998, IF wrote:

> There's an idea I've been working with...
[inclusion of further PC conversation lines after initial command]

To be honest, I wouldn't dream of doing it any other way.

--
Den


Daryl McCullough

unread,
Aug 5, 1998, 3:00:00 AM8/5/98
to
ofd...@aol.com says...

>
>I've been working on some NPC interactions with more than one NPC in the room.
>The situation is this: If you speak without direction, any or all characters
>may reply. If you direct, the directed character replies and for convieniece,
>following undirected questions are answered by the same character.

[stuff deleted]

>My problem is that I can not decide on a good syntax for addressing the entire
>room again.

If you want to address everyone, do it this way:

>Y'all, find me a hoe.

That's the Southern way.

Daryl McCullough
CoGenTex, Inc.
Ithaca, NY

GLYPH

unread,
Aug 5, 1998, 3:00:00 AM8/5/98
to
On Wed, 5 Aug 1998, Barbara Robson wrote:

> ofd...@aol.com (OFDown) writes:
>
> |I've been working on some NPC interactions with more than one NPC in the room.
> |The situation is this: If you speak without direction, any or all characters
> |may reply. If you direct, the directed character replies and for convieniece,
> |following undirected questions are answered by the same character.
>

> |My problem is that I can not decide on a good syntax for addressing the entire

> |room again. Once I've directed to a character, I'm stuck in private
> |conversations.
>

> How about "ALL, find the hoe" or "HEY, find the hoe" or "EVERYONE, find the
> hoe" to return to a public conversation. If I were doing it, I'd allow
> all of these as synonyms.
>
> Barbara

This is exactly what I did in my NPC lib. I have an invisible NPC named
"everyone all etc." who is always in scope. He redirects anything
addressed to him to all the other NPCs in the room.

michael...@ey.com

unread,
Aug 5, 1998, 3:00:00 AM8/5/98
to
In article <6q9uio$r...@drn.newsguy.com>,
da...@cogentex.com (Daryl McCullough) wrote:

>
> >Y'all, find me a hoe.
>
> That's the Southern way.
>

There are places in the South where you'd have some problems with
disambiguation...

TenthStone

unread,
Aug 5, 1998, 3:00:00 AM8/5/98
to
IF <mord...@ix.netcom.com> caused this to appear in our collective minds on Tue, 04 Aug 1998 18:46:12 -0600:

> There's an idea I've been working with, and this would seem the thread to test
>it out. The idea is letting your character interact on his or her own when you've
>started a conversation, based on things you've done before. For example:
>

>In this manner, you would start a dialogue, but your character would carry it out,
>using sensible phrases. It could also be used to clarify meaning, that is to
>present and actual question ("Where is the key") as opposed to an abstraction
>("Ask Bob about key"). ex:

I think it's always a good idea to include a phrasing of the question being asked; for
example:

> Ask Michelle about the dark side of the moon.
"Michelle, have you ever heard that Pink Floyd album, Dark Side of the Moon?"

Michelle looks at you is disbelief. "Of course! Who hasn't? I actually have it in vinyl."

> Congratulate Michelle.
You look enviously at Michelle. "Wow. I have a bad copy of it on tape, but I've always
wanted the album."

Michelle looks at you in thought, as if debating whether she should permit your company
for being a Pink Floyd fan, or dislike you forever for not being enough of one.

> Ask Michelle about unlit part of moon.
"Michelle, what do you think abou the other side of the moon?"

Michelle glances around, nearly non-chalantly, and whispers, "There's nothing there. It's
all just a giant wooden prop, being held up by mysterious, alien forces. All there is behind
the board is very large amounts of scaffolding."

You look in wonder at Michelle, amazed that this woman agrees with you on so many things.

>I haven't explained the concept very well, since my brother is playing Whitesnake
>in the next room and seriously disturbing my synaptic processes, but do you think
>this idea would fly?

I think it's an excellent idea.

Matt Ackeret

unread,
Aug 8, 1998, 3:00:00 AM8/8/98
to
In article <6q9uio$r...@drn.newsguy.com>,

Daryl McCullough <da...@cogentex.com> wrote:
>>Y'all, find me a hoe.
>
>That's the Southern way.

Wouldn't going to the red light district be easier?

(ba dum psh!)
--
mat...@area.com

Doeadeer3

unread,
Aug 11, 1998, 3:00:00 AM8/11/98
to
For over a month I have been working on a two-ended tieable object (i.e., a
"rope") that when debugged I will upload to contributions. I had just finished
it when my hard disk crashed and garbled 3/4th of my file. <SIGH> I have
finally finished the rewrite.

There are two files: 2endtie.h and demo2end.inf, a sample game to test it in.
Yes, the rope can be in several locations (using a property similar to
found_in) after it has been tied to something stationary and carried elsewhere.

I would like some Inform beta testers who could play (and maybe add to and
change) the sample game (or use it in another game) to make sure all the bugs
are out. It will be ready to be beta tested in about a week.

Due to problems (long, long story, I am now using my old C drive, 125 mg for
aol <BIGGER SIGH>), I can't access a newsreader so I am doing everything by
email. So please email me if you would be interested in beta testing.

Doe :-) doea...@aol.com


Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain

Kevin Forchione

unread,
Aug 12, 1998, 3:00:00 AM8/12/98
to

Barbara Robson wrote in message ...
> <snip> Something else that I've tried is to keep track of

>what the most recent topic of conversation was: if you ask Bob about the
>same thing twice in a row, he'll be likely to elaborate, and if you ask
>about something new, the previous question might help to define the
context,
>if there might be a connection.
>
This sounds great. It could lead to all kinds of interconnections between
topics and progress the plot along too. Would be very useful for
mystery-oriented games. But then you would probably need some kind of matrix
(almost a database) of topics and who says what, when, and why.

For instance. I can imagine the following scenario: You interact with NPC
Bob, and as a result NPC Mary responds differently to your queries based on:

a. what she may or may not have overheard
b. what Bob may have "told her in private" as a result of your conversation
etc.

The mind just boggles...

Kevin

Harrison Farlane

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to
hmmm, i've never agreed with the line of thinking that argues that if
you ask NPCs the same question twice, they're likely to elaborate (why
some designers use this, i'll never know). now, to _clarify_ the
original answer might be fine, but revealing new information is
something MPCs should (imho) NEVER do, such:

>ask bob about photograph

"Hey Bob," you say, "take a look at this."
You hand Bob the photograph. He looks at it and says, "This face looks
familiar..."

>ask bob about photograph

"I knew I'd seen this face before," Bob exclaims. "It's Harrison
Farlane, the man most likely to inherit the entire Wilthrop fortune...
yadda yadda."

if the player discovers they may have to ask a question more than once
to get more information, they're going to ask every question three or
four times - a waste of time/turns. remember, good game design is about
the player unfolding the story, not grappling with the mechanics of the
parser/interpreter/whatever.

now, having a conversation with a NPC has always been one of the Great
Grey Areas of IF. i've seen many parsers that *claim* they can handle
natural language conversation, but none that do so very well. in my
opinion, the parser/game should take the issue of conversing with NPCs
out of the player's hands, and should manage the conversation itself,
thus:

>ask bob about photograph

"Hey Bob," you say, "take a look at this."
You hand Bob the photograph. He looks at it and says, "This face looks
familiar..."

You wait while Bob tries to recognise the face in the photograph...

"I knew I'd seen this face before," Bob exclaims. "It's Harrison
Farlane. I hear he's heir to a pretty large fortune."

"Yeah," you ask, "whos fortune?"

"I can't recall," Bob says, "but I think the money was tied up in oil."

Susan enters.

>ask susan about photograph

"Hey Susan, do you recognise this guy?"

"Sure. Harrison Farlane is heir to the Wilthrop fortune. yadda yadda"

this saves a whole lot of >ask bob about fortune, >ask bob about oil,
etc. in the worst-case scenario, you get things like >ask NPC about
*everything in inventory*

so, let the game steer the conversation and don't force the player to
have to figure out how to phrase the right question to get the
characters talking.

you're suggestions with cross-linking conversations throughout the game,
such that if you speak with one character, another may react
differently, is excellent and there are a couple of good ways to
implement this idea. however, remember that conversation is a time/turn
consuming task and should only be used where _absolutely_necessary_ in
the story. keep the chatter to a minimum, make it easy on yourself.
keep on truckin'
-harry

Kevin Forchione

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to

Harrison Farlane wrote in message <35D25592...@Mformtrap.com>...
>. . .now, having a conversation with a NPC has always been one of the Great

>Grey Areas of IF. i've seen many parsers that *claim* they can handle
>natural language conversation, but none that do so very well. in my
>opinion, the parser/game should take the issue of conversing with NPCs
>out of the player's hands, and should manage the conversation itself . . .


I have to agree with Harry. The type of game produced this way is much more
elegant and entertaining. There must be a balance, I believe, between
"interactive" and "fiction".

At times I think it would be wonderful to have more IA brought into the
gaming arena, and it's easy to become awestruck by thoughts of objects
shooting messages at each other in complex interactions. But the games I've
enjoyed the most haven't relied heavily on NPC interaction, they were
well-crafted and considerate of the player.

That's why I look at Inform and I still see a lot of mileage left in the
system yet, most of my favourite games were written in z-machine format, and
the thing that stands out is the quality of the "fiction", not the special
effects of the "interaction".

One of these days someone's going to come out with another gaming system,
and one of the first things they're going to do is port Advent ("Colossal
Cave") over to it. But I don't suppose it will be any MORE enjoyable to
play...

Kevin

Doeadeer3

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to
In article <robbj95.902191636@octarine>, Barbara Robson
<rob...@octarine.itsc.adfa.edu.aus> writes:

>From: Barbara Robson <rob...@octarine.itsc.adfa.edu.aus>
>Date: Tue, 04 Aug 1998 00:57:26 GMT


>
>michael...@ey.com writes:
>
>>I've already come up with one idea. First, make conversation topics objects
>>in their own right. Then, assign each NPC and each topic a value, then
>create
>>a 2-dimensional array with a slot for each NPC cross-indexed to each topic.

>[snip] if you ask Bob about the


>same thing twice in a row, he'll be likely to elaborate, and if you ask
>about something new, the previous question might help to define the context,
>if there might be a connection.

A really simple way to do that in Inform is, make the conversation topics
objects (like Gareth Ree's did in Christminister) and then give a topic (since
it is now an object like any other object) a flag when you have already asked
it of a character. (This is greatly condensed from a system I have in a game I
am working on.)

Object Topics;
Object -> Susant with name "Susan" "your" "girlfriend.";
Object -> Suesdogt with name "Susan's" "your" "girlfriend's" "dog";

Object Bob, etc.
[; Ask : If (topic has Bob_Asked) "Bob looks at you strangely., "You already
asked me that.";
give topic Bob_asked;
Susant : "Well, you know... blah, blah.";
Suesdogt: "He ran away.";

I also use this method to reveal more information when the topic is asked again
after some other condition has been met (Bob is shown something, you have asked
about something else, etc.). I use a lot of flags, however an array could work.

I also use more than one collection of topics depending on the character or new
developments in the game.

I also like Gareth's use of BestMatch() and Refers() (note you have to use the
older version of Refers for it to work correctly), because it means you can
have similar topics that may differ only by a word or two (see above) and the
player will not have to deal with disambiguation, which could be VERY awkward
in conversation.

But I am eagerly waiting to see glyph's debugged conversation library.

Doe :-)

Aryko

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to
I was all set to agree with Harrison here, if not for just one point.
It's simply that a great way to break the flow of a game is if the
player types 'Ask Bob about photograph' twice in a row. You'll get the
same two pages of dialogue, instead of a character saying "I've already
told you that!"

So in this case, you want to have multiple responses for an 'ask'
command simply to allow for the NPC to tell the player that they should
have been paying attention the first time. As well, you can tie in
later events - say the character asks someone else about the photograph,
and they learn more about it, the PC could return to Bob and try ask bob
about photograph again, and this time get more information.

A bit clumsy, sure. The only way I'd use the system is to cut down on
players asking every NPC about everything - eventually, they rub the NPC
the wrong way with their conversational flailing about. Simply put, you
have to be able to ask the right questions at the right time.

Aryko

Harrison Farlane wrote:
>
> hmmm, i've never agreed with the line of thinking that argues that if
> you ask NPCs the same question twice, they're likely to elaborate (why
> some designers use this, i'll never know). now, to _clarify_ the
> original answer might be fine, but revealing new information is
> something MPCs should (imho) NEVER do, such:

[snip]

Andrew Plotkin

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to
Aryko (ar...@hotmail.com) wrote:
> I was all set to agree with Harrison here, if not for just one point.
> It's simply that a great way to break the flow of a game is if the
> player types 'Ask Bob about photograph' twice in a row. You'll get the
> same two pages of dialogue, instead of a character saying "I've already
> told you that!"
>
> So in this case, you want to have multiple responses for an 'ask'
> command simply to allow for the NPC to tell the player that they should
> have been paying attention the first time.

But this can be a problem, because they may *not* have been paying
attention the first time. Or may just have slipped a detail. It's really
annoying to have to go back and restore a game because you can't get the
same information out of an NPC more than once.

--Z

--

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

Joe Mason

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to
In article <erkyrathE...@netcom.com>,

Andrew Plotkin <erky...@netcom.com> wrote:
>
>But this can be a problem, because they may *not* have been paying
>attention the first time. Or may just have slipped a detail. It's really
>annoying to have to go back and restore a game because you can't get the
>same information out of an NPC more than once.

The problem with this is it breaks (ack!) mimesis. Sure, if you don't want
NPC's dumping the same information on you verbatim more then once you can just
not talk to them more then once, but it's ugly. People just don't do that,
unless maybe they're automated.

I would handle this in one of two ways. First, you could have information
repeated from many sources. So if the player doesn't pay attention to one NPC,
they can still pick it up later. The problem with this is that if you pick up
a clue from the first person you talk to, it gets annoying to find it repeated
over and over again.

So what I would do is implement a "tape recorder" or "notebook" - like in
Gabriel Knight or Return to Zork. The difference is that I wouldn't even try
to pretend that it's part of the story: it'd be a game mechanic, like typing
"verbose" or "save". Since you have to store all the text that happens during
conversations somewhere anyway, it shouldn't be too hard to have a menu that
will reference any conversation you've already heard, and print it back to you.
The NPC would then be free to react differently the second time around, since
the player can still refresh their memory with having the PC sit through the
whole spiel again.

This runs into the same technical problems as the popular "camera which records
room descriptions": if you generate part of your conversation based on what the
PC is carrying, wearing, accomplished, etc., you can't simply regenerate the
text when the player tries to recall it, in case any of that has changed. Not
insurmountable, though, and since you would presumably define a small number
of ways the text could change (as opposed to an infinite number of items you
can leave in a room) it wouldn't be as hard to keep track of as the camera.

Joe

Laurel Halbany

unread,
Aug 13, 1998, 3:00:00 AM8/13/98
to
On Thu, 13 Aug 1998 18:39:11 GMT, erky...@netcom.com (Andrew Plotkin)
wrote:

>But this can be a problem, because they may *not* have been paying
>attention the first time. Or may just have slipped a detail. It's really
>annoying to have to go back and restore a game because you can't get the
>same information out of an NPC more than once.

It is, but it's also weird to have Bob repeat exactly what he said
before. Bob might give you a funny look and say "Weren't you
listening?" <followed by a briefer recap>, or you might have some kind
of note-taking utility, as in Babel, that lets you go back and
remember the salient points of what the NPC said, e.g.:

>ask Bob about truncheon

"I just explained that," Bob tells you with some annoyance.

>look up truncheon in reporter's notes

Looking at your notes, you see that you scribbled down
some of what Bob told you; namely, that the truncheon had
no fingerprints on it, it had some odd chew marks at one
end, and it originally been dyed purple, rather than its current
dark brown color.

Doeadeer3

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
In article <erkyrathE...@netcom.com>, erky...@netcom.com (Andrew
Plotkin) writes:

>But this can be a problem, because they may *not* have been paying
>attention the first time. Or may just have slipped a detail. It's really
>annoying to have to go back and restore a game because you can't get the
>same information out of an NPC more than once.
>

>--Z

Agreed. But if Bob is asked a second time about the same thing (because the
player missed something the first time around), maybe Bob could say, "I've
already told you, but do you want to hear it again?" (Y or N) > Hmmm. OR
the player could be warned in the help screens that NPC's respond differently
when being asked about something additional times and they that they should pay
attention the first time because that may be the ONLY time they will hear a
particular answer.

Also been thinking about an earlier discussion. The topics THEMSELVES could
have arrays (or numbers). (This is just a "sketch" and is not workable and
having it repeated should be for something more important than this.):

Object Topics
Object-> Susant with Bob_Talk 0, Susan_Talk 0, etc.
name "Susan" "your" "girlfriend";

Object Bob "Bob" etc.
with save_talk,
Life [;
Ask : topic.Bob_talk = topic.Bob_talk + 1;
if (topic.Bob_talk > 1)
{ print "I've told you already, but do you want to hear it again? (Y
or N) >";
if (YesorNo())
{ save_talk = topic.Bob_talk;
topic.Bob_talk = 1;
}
}
switch(topic)
Susant : switch(topic.Bob_talk)
1 : "Well, we broke up, you know.";
2 : "I have no idea where she is now.";
default: "I really don't want to talk about her
anymore.";
etc., etc.
topic.Bob_talk = save_talk;

Well, it is just an idea. I think maybe I will work on developing it (later).

Doeadeer3

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
P.S. My sketch code sample would work even better if Bob himself doesn't ask if
you want a repeat, but if the "game" asks if you want a repeat. "You already
heard Bob's first reponse to that question. Would you like to hear it again or
hear his next repsonse?" (Y - Hear Again, N - Next Response) The game talks to
the player all the time anyway ("That isn't portable. That isn't open. That is
not something you need to refer to...", etc.) And it would be best if repeats
are only available for crucial responses.

This is an interesting discussion. It has sparked all kinds of ideas.

Harrison Farlane

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
Laurel Halbany wrote:
[snip]

> >look up truncheon in reporter's notes
>
> Looking at your notes, you see that you scribbled down
> some of what Bob told you; namely, that the truncheon had
> no fingerprints on it, it had some odd chew marks at one
> end, and it originally been dyed purple, rather than its current
> dark brown color.

this is an excellent example of the parser _managing_ the conversation -
by detailing the salient points and producing a list of them for you. i
mean, where the hell would we be if the game didn't manage our inventory
for us?

who doesn't play i.f. without taking notes in some form or another? its
expected by the game designer that you'll be noting down the important
clues they're feeding you so you can put them together to complete the
game. by having the game recall conversations, as demonstrated above,
you can be sure that all the necessary information is there and you can
iron out the *many* ambiguities involved with transferring information
through language. remember - the game can preserve not only important
clues from conversations with NPCs, but also red herrings (as would only
be fair).

further, the beauty of handling it this way is that this system also
allows you to cross reference information in an interesting way. after
all, it is worthwhile remembering that an i.f. game is merely a database
which you query for information. databases live for cross-referencing
information thus:

>look up truncheon in reporter's notes

Looking at your notes, you see that you scribbled down
some of what Bob told you; namely, that the truncheon had
no fingerprints on it, it had some odd chew marks at one
end, and it originally been dyed purple, rather than its current
dark brown color.

>look up bob in reporter's notes

Looking at your notes, you see that you scribbled down

some of what Bob told you; namely, that he was depressed
at unexpectedly losing his job, he suspected his wife was
having an affair with Brad Caulfield, his dog was heavily
beaten by someone trying to break into his house when he
was out one afternoon, he doesn't know who sent his wife
the death threats...

in this way you can link the odd chew marks on the truncheon with bob's
dog begin beaten, etc. it would be tempting to use the reporter's notes
to supplant further information into the story, such as the
hitch-hiker's guide in the game, but the reporter's notes should only
record what has already been learned by you. in this way you shouldn't
have to retrace your steps, wait at some location as Time passes... for
a NPC to appear again because you forgot what they said about the jewels
(you were only paying attention to information about the truncheon at
the time only to find out half way through the game you were heading
down the wrong track and now you either restore a game or wander back
through the map).

to reiterate my sentiment: i.f. games should always be pushing the
character forward, helping them use their wits to get through a complex
story, not forcing the player to grapple with the mechanics of the
program to try and trick the game into revealing information it doesn't
want to reveal. to this end, complicated grey areas such as conversing
with NPCs should be managed by the game - not to introduce more
complexity, but help the player draw associations from disparate bits of
information to piece together the solution to the puzzle and ultimately,
the game. sure, they're going to be taking notes anyway, but a player
should never be feeling that if they don't write down _everything_,
they're going to have to restore/restart the game and go and talk to all
those NPCs again. agreed...?

---
for mail, replace domain name with formtrap DOT com

Nicholas Daley

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to Doeadeer3
Doeadeer3 wrote:
[snip]

> I would like some Inform beta testers who could play (and maybe add to and
> change) the sample game (or use it in another game) to make sure all the bugs
> are out. It will be ready to be beta tested in about a week.
May I suggest looking for programmers in the IF Collaborator's List
(maintained by me) at 'http://homepages.ihug.co.nz/~daleys/'.
--
Nicholas Daley
<link_...@geocities.com>

Lucian Paul Smith

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
Doeadeer3 (doea...@aol.com) wrote:
: P.S. My sketch code sample would work even better if Bob himself doesn't ask if

: you want a repeat, but if the "game" asks if you want a repeat.

This would be my ideal solution, I think. In games where most characters
only had one thing to say about any given item, the following might work:

>ASK BOB ABOUT GRAPEFRUIT

"I'll tell you this, at least--it's no Graham Nelson!"

>ASK BOB ABOUT GRAPEFRUIT

[Repeating Bob's previous answer--to change this behavior, use the 'NPC'
verb.]

"I'll tell you this, at least--it's no Graham Nelson!"

>NPC

[The NPC verb can be used to modify the way the NPCs in this game behave.
To change conversations to menu-based, type 'NPC MENU'. To change them
back to the more traditional ask...about style, type 'NPC ASKABOUT' (the
default). To change NPC responses so they only answer questions once,
type 'NPC ONCE' (In menu-based mode, this will remove items from the list
once selected). To change NPC responses so they say the same thing every
time you ask them the same question, type 'NPC AGAIN' (the default)]

>ASK BOB ABOUT GRAPEFRUIT

"I'll tell you this, at least--it's no Graham Nelson!"

-------

So, the first time the player encounters the default behavior, they are
informed about the 'NPC' meta-verb (which would also be documented in
'about', presumably), and after that they could mess with the default
behavior all they wanted.

-Lucian

Michael Straight

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
On Thu, 13 Aug 1998, Joe Mason wrote:

> In article <erkyrathE...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> >

> >But this can be a problem, because they may *not* have been paying
> >attention the first time. Or may just have slipped a detail. It's really
> >annoying to have to go back and restore a game because you can't get the
> >same information out of an NPC more than once.
>

> The problem with this is it breaks (ack!) mimesis. Sure, if you don't want
> NPC's dumping the same information on you verbatim more then once you can just
> not talk to them more then once, but it's ugly. People just don't do that,
> unless maybe they're automated.
>
> I would handle this in one of two ways. First, you could have information
> repeated from many sources. So if the player doesn't pay attention to one NPC,
> they can still pick it up later. The problem with this is that if you pick up
> a clue from the first person you talk to, it gets annoying to find it repeated
> over and over again.

I think an easier way to preserve mimesis would be something like this...

>ask Harry about camera

"I just told you everything I know about the camera! Do I have to repeat
myself?"

>Harry, yes

Ok...[repeat text]

SMTIRCAHIAGEHLT


Doeadeer3

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
In article <35D413FF.3E1F9FE7@-.->, Nicholas Daley <-@-.-> writes:

>May I suggest looking for programmers in the IF Collaborator's List
>(maintained by me) at 'http://homepages.ihug.co.nz/~daleys/'.

Thanks anyway, but I already have four beta-testers lined up.

okbl...@usa.net

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to
In article <ExnD0...@undergrad.math.uwaterloo.ca>,

jcm...@undergrad.math.uwaterloo.ca (Joe Mason) wrote:
>
> So what I would do is implement a "tape recorder" or "notebook" - like in
>

How 'bout implementing "memory". :-)

> REMEMBER GRAPEFRUIT

...you've always hated grapefruit since one squirted you in the eye when you
were just 3 years old. ...The policeman said that the man had been murdered
by a blow to the head with a large, blunt citrus fruit. ...somebody compared
Graham Nelson to a grapefruit once, didn't they?

[ok]

Jonadab the Unsightly One

unread,
Aug 14, 1998, 3:00:00 AM8/14/98
to

Joe Mason wrote:
> In article <erkyrathE...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> >
> >But this can be a problem, because they may *not* have been paying
> >attention the first time. Or may just have slipped a detail. It's really

> >annoying to have to go back and restore a game because you can't get the

> >same information out of an NPC more than once.

It depends somewhat on the nature of the information your NPCs give.
If it provides necessary information in such a way that individual
words are significant then you need to be able to get it again
somehow, of course. OTOH, if the information the NPCs provide is
mostly atmospheric in nature and follows themes, this may not be
necessary. So it depends on your game.

> The problem with this is it breaks (ack!) mimesis. Sure, if you don't
want
> NPC's dumping the same information on you verbatim more then once you can
just
> not talk to them more then once, but it's ugly. People just don't do
that,
> unless maybe they're automated.

Another option might be to build enough random-based variety into each
response to make it sound like a paraphrase the second or third or
even fourth time around. If you keep on asking and asking, though,
even this will break down. Plus, it could be a lot of work.

> I would handle this in one of two ways. First, you could have
information
> repeated from many sources. So if the player doesn't pay attention to
one NPC,
> they can still pick it up later. The problem with this is that if you
pick up
> a clue from the first person you talk to, it gets annoying to find it
repeated
> over and over again.

This might work for an occasional game, but in most cases I doubt
whether it is a good idea.

> So what I would do is implement a "tape recorder"

I have done this.

Well, sort of. The tape recorder in Diary of a Text Adventurer
does not handle conversation yet, but it will. (Currently it
handles all the other "sounds" in the game, but I will be
adapting my conversation system to pipe through my "sound"
(text-based sound, that is) routines so that the tape
recorder will pick up conversations, too.

I wouldn't do this just for NPC conversation, though.
The tape recorder in my game serves a real, concrete purpose
to the game, besides being quite fun to implement. But the
"sound" system in my game uses two general properties, and
the recorder itself (no, the tape, actually) uses a sizeable
array (to store the object number of each sound from an object
that only produces one sound, or the object number and sound
number from any object that produces more than one possible
sound), so the whole deal is somewhat involved if you
only wanted it to provide a second chance at missed information.

Plus, the size of the tape is limited by the amount of RAM you
want to let it consume. If the only things it were recording
were conversations this might not be so bad, as it could be
reduced to two integers (possibly even one with some twiddling)
per turn. But I ran a test of it in my game, and it recorded
about 3-10 sounds per turn, depending on where in the game I was.
(Many of these are not "loud" enough that you notice them normally,
but if you Listen you get them, and when the tape records it
records everything (regardless of whether you "hear" it at the time),
and when you play the tape you get it all -- one turn's worth
per turn, in fact. So you could only record for maybe 30 or 50
turns with the current size of my tape (and I only hope continued
development does not push me into RAM limits).

> or "notebook" - like in

> Gabriel Knight or Return to Zork. The difference is that I wouldn't even
try
> to pretend that it's part of the story: it'd be a game mechanic, like
typing
> "verbose" or "save". Since you have to store all the text that happens
during
> conversations somewhere anyway, it shouldn't be too hard to have a menu
that
> will reference any conversation you've already heard, and print it back
to you.

This would definitely be less resource-consuming to implement, both
in terms of the game and in terms of programmer time.

> The NPC would then be free to react differently the second time around,
since
> the player can still refresh their memory with having the PC sit through
the
> whole spiel again.

Another benefit.

> This runs into the same technical problems as the popular "camera which
records
> room descriptions": if you generate part of your conversation based on
what the
> PC is carrying, wearing, accomplished, etc., you can't simply regenerate
the
> text when the player tries to recall it, in case any of that has changed.
Not
> insurmountable, though, and since you would presumably define a small
number
> of ways the text could change (as opposed to an infinite number of items
you
> can leave in a room) it wouldn't be as hard to keep track of as the
camera.

The way I am handling this is to make all "sounds" in my game
(conversations
have yet to be adapted to this system, but they will be) occur in two
stages.

One routine (property) spits out a number. The other routine (property)
turns it into text. Thus, if there are eleven different things Bob can
say about the garden, Bob's garden conversation topic object has one
property containing a routine that spits out a number from 1 to 11, based
on whatever circumstances, and another that takes that number and
translates
it into text.

If you want to have each thing that is said be affected by other factors
then you may have several numbers map to the same basic section of
code, which can include or exclude subsections of text based on
re-examining the number.

--
At Your Service,
Jonadab the Unsightly One.

remove spaces: j o n a d a b @ b r i g h t . n e t


Kevin Forchione

unread,
Aug 15, 1998, 3:00:00 AM8/15/98
to

Andrew Plotkin wrote in message ...

>But this can be a problem, because they may *not* have been paying
>attention the first time. Or may just have slipped a detail. It's really
>annoying to have to go back and restore a game because you can't get the
>same information out of an NPC more than once.

I think Andrew's comment has been quoted the most in this thread! I wonder
if we aren't looking at it the wrong way? Surely you'll find a game where
the author has constructed it so that the player needs to ask NPCs the same
question several times in order to gain further information. I can invision
the following scenario myself:

> ask woman about the Falcon
Woman: "Have you spoken to the fat man yet?"

(after seeing the fat man) > ask woman about the Falcon
Woman: "We were hired to steal it from the Russian."

But this is easily handled by the fact that she responds to your query with
an instruction that is intended to produce a follow-up. In this case if you
went back to her time after time before you saw the fat man she would
respond with a statement (whether varied or not) that would convey a certain
information. Afterward she would convey another type of information (again
the variance seems irrelevant here, unless the absolute wording is
critical).

The point is that people don't go about asking each other the same question
over and over, not even in novels. Not unless there is a specific purpose in
doing so. At the highest level what we're attempting to do in "Interactive
Fiction" is tell a Story. These stories are special in that we can effect
the nature of our personal involvement in the tale by the choices that we
make (the "interactive" bit), but our labours are still subordinate to the
task of story-telling.

Why give the player the ability to do something that serves no purpose in
the game? If I build a system that allows a person to ask an NPC the same
question over and over and get different responses (or not, as the case may
be) I will expect the player to be doing that with each NPC (or at least
most of them, to justify the labour involved in coding such an ability) and
this may not be an integral part of the plot. (I can hardly imagine it being
a necessary element of the story milieu that people go about putting the
same question over and over to each other, hoping for elaboration. I can
imagine the above cited example, though surely not with every NPC. Not
unless you're making a Kafka-esque game.)

There's a lot of talk about 'breaking mimesis' but if we aren't careful
we'll be in danger of losing the plot!

Kevin

Bryan Dunphy

unread,
Aug 15, 1998, 3:00:00 AM8/15/98
to
On Fri, 14 Aug 1998 18:46:38 GMT, okbl...@usa.net wrote:

>How 'bout implementing "memory". :-)
>
>> REMEMBER GRAPEFRUIT
>
>...you've always hated grapefruit since one squirted you in the eye when you
>were just 3 years old. ...The policeman said that the man had been murdered
>by a blow to the head with a large, blunt citrus fruit. ...somebody compared
>Graham Nelson to a grapefruit once, didn't they?

I have a similar problem in the game I'm trying to write - and a very
similar proposed solution.

In my game, the character has a specific persona that has actually
been based on me. After all, who would I know better?

The two related problems are first, I am physically challenged; and
second, parts of the game occur in places the character should know
well - such as his home, the town he's lived in for the past five
years, etc.

My currently proposed solution is to add a command allowing the player
to "think about" things in the game. This would allow the player to
discover the things he/she should already know without me having to
begin the game with several screen full of exposition and a warning to
take notes.

Any comments, or constructive criticism, regarding my idea would be
appreciated.

TenthStone

unread,
Aug 16, 1998, 3:00:00 AM8/16/98
to
doea...@aol.com (Doeadeer3) caused this to appear in our collective minds on 14 Aug 1998 00:35:27 GMT:

[snip]
...


>But if Bob is asked a second time about the same thing (because the
>player missed something the first time around), maybe Bob could say, "I've
>already told you, but do you want to hear it again?" (Y or N) > Hmmm. OR
>the player could be warned in the help screens that NPC's respond differently
>when being asked about something additional times and they that they should pay
>attention the first time because that may be the ONLY time they will hear a
>particular answer.

It just so happens that obvious departures from the familiar prompt tend to be
big ol' bites out of the mimesis leaves, if you know what I mean (nod, wink).

And it's hard to get a player to read help screens unless he/she is having trouble
with the game (unless one includes a menu system at game-start...?). The trouble is
that they cut through the beautiful roots of the mimesis with a butcher's knife. You can't
keep the atmosphere of the introduction with a page of text about "X BOOK" "GET BOOK"
"PUT RED BOOK IN BLENDER" (it's really qute strange how often books are used in
'How to Play Text Adventures' messages). I, personally, freeze whenever I see those
coming, especially when included in readme files.

>Also been thinking about an earlier discussion. The topics THEMSELVES could
>have arrays (or numbers).

Speaking on this same topic:

It seems to be that it would be very nice for objects to have special arrays-that-are-not-arrays.
Or properties-etc. As follows:

DirtyKnife: item
talkedabout( Me ) = 0
talkedabout( George ) = 0
talkedabout( Marianne ) = 0
ioAskAbout( actor, answerer ) = { // i.e. "ASK answerer ABOUT dirty knife"
self.talkedabout( answerer )++;
self.talkabout( answerer );
}
talkabout( Me ) = {
switch (self.talkedabout( Me )) {
case 1:
"You think you once saw this very knife down at the pawn shop.
But it was much cleaner then... this whole town was. Ever since the
MacDonald murder, the air has seemed tighter at your throat.";
break;
default:
"You think you remember seeing this knife once at the pawn shop.";
break;
}
}
talkabout( George ) = {
switch (self.talkedabout( George )) {
case 1:
"George looks at you with his old guilty stare and says, \"I reckon that's
the knife that was in my pawn shop awhile back yonder. Yep, seems to
me it's the one.\"";
break;
default:
"George looks at you with his pitifully stupid expression and reminds you,
\"I already told you once, I reckon it's the one from my shop.\"";
break;
}
}
// et cetera ad nauseum
;

The idea is for an object-addressed array system of limited scope, such that the three attributes
above would be considered seperate properties. A keyword could be included, such as
"default", where a value would be passed as the variable default indicating the value passed. Scope
could be indicated by forcing all possible specific references for a certain property on a certain
object to be expressly included in the object declaration (that is, an entry for .talkabout( Marianne )
would need to be added in order for that to avoid being passed to .talkabout( default )). This special
property type would be detected by its use of object tokens for passed values.

This wouldn't really be practical for methods (.talkabout); it would be very convenient, however, for
variable properties (.talkedabout) which could thusly be more easily stored.

I'd place a "Just my Thoughts" here, but really, doesn't that go without saying? I mean, shouldn't we
be more concerned with knowing when they are NOT just your thoughts?

Adam J. Thornton

unread,
Aug 16, 1998, 3:00:00 AM8/16/98
to
In article <35d63cf...@news.erols.com>,

TenthStone <mcc...@erols.com> wrote:
>It just so happens that obvious departures from the familiar prompt tend to be
>big ol' bites out of the mimesis leaves, if you know what I mean (nod, wink).

Tastes nasty.

>You can't keep the atmosphere of the introduction with a page of text
>about "X BOOK" "GET BOOK" "PUT RED BOOK IN BLENDER"

Red book cries!

No, I don't have any constructive suggestions this time around; sorry. I
tend to handle NPC interaction by not having any significant NPCs. The
Devil is the one exception, and he just had a big ol' list of topics and no
state. And it wasn't necessary to talk to him anyway.

Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman

okbl...@usa.net

unread,
Aug 17, 1998, 3:00:00 AM8/17/98
to
In article <35d616ca....@news.supernews.com>,

bdu...@bigfoot.com (Bryan Dunphy) wrote:
>
> Any comments, or constructive criticism, regarding my idea would be
> appreciated.
>

I think it's a good idea, obviously, since it's so similar to mine. :-)

> The two related problems are first, I am physically challenged; and
> second, parts of the game occur in places the character should know
> well - such as his home, the town he's lived in for the past five
> years, etc.
>

Depending on the nature of your difference, it might also be important to
provide clues as to things you would or wouldn't do. For example, a person
in a wheelchair might take route A because that's where all the ramps are,
where route B, though more direct, might have no ramps, broken road or
sidewalk, or other obstacles.

It could be very good and very interesting all by itself! But I suspect you
have more in mind?

As for saving the exposition and notes factor I am 100% all for that. I
=hate= taking notes when playing IF. It becomes more work and less fun. I
remember playing "Tapestry" three times, just to see what the three
variations on it were, and I frequently wasn't able to find my way into the
bathroom of the house I had lived in for years and years. <sigh>

I seldom have this problem in real life. ;-)

It's probably the #1 barrier to me playing more IF.

J. Robinson Wheeler

unread,
Aug 17, 1998, 3:00:00 AM8/17/98
to
I have a general purpose sort of question for both TADS and Inform in
the way they set up "ask NPC about X" processing. In this game I'm
working on, I wrote it first in TADS and subverted the normal doAskAbout
routine in favor of something simpler, a generic routine that denied all
knowledge of whatever topic. When I tried to port it to Inform, I realized
that I could not, because it left you with a set of dictionary addresses
to the words asked about, so that you could handle them only by comparing
strings ( topic == 'xyzzy' ).

I was very annoyed at that, because my TADS version had allowed the NPC
to use the topic object's properties to print a different disavowal for
other NPCs ("I don't know him/her") or objects ("I don't know much about
<<plural_of_item>>").

Today I decided to replace this generic routine with something that used
the original doAskAbout for Actors in ADV.T, and when my compiler crashed,
I realized that TADS did the same thing -- gave you a list of strings with
which to make comparisons, instead of objects that had properties that
one could distinguish.

My question is, why do it this way? My judgment that it was strange
and silly for Inform to do that was humbled when I found out that TADS
was set up the same way. Doesn't this entail checking every noun and
adjective in the game to match topics? Now I see why the question
routines in Christminster were set up as they are.

In any event, it rules out allowing NPCs to distinguish between items
and actors in order to make tailored disavowals (which is probably why
they default to "I don't know much about that." or "There is no reply.").


--
J. Robinson Wheeler
whe...@jump.net http://www.jump.net/~wheeler/jrw/home.html

Stephen Granade

unread,
Aug 17, 1998, 3:00:00 AM8/17/98
to
On Mon, 17 Aug 1998, J. Robinson Wheeler wrote:

> Today I decided to replace this generic routine with something that used
> the original doAskAbout for Actors in ADV.T, and when my compiler crashed,
> I realized that TADS did the same thing -- gave you a list of strings with
> which to make comparisons, instead of objects that had properties that
> one could distinguish.

Er? It sounds like you're working with askWord, which does receive a list
of strings, rather than doAskAbout. The relevant code in adv.t is:

doAskAbout(actor, iobj) =
{
local lst, i, tot;

lst := objwords(2); // get actual words asked about
tot := length(lst);
[snip]
// try to find a response for each word
for (i := 1 ; i <= tot ; ++i)
{
if (self.askWord(lst[i], lst))
return;
}

// didn't find anything to talk about
self.disavow;
}

doAskAbout gets handed the object being talked about via the iobj
parameter. In the adv.t default version, doAskAbout then gets all the
vocabulary words associated with that object and passes them to askWord.

I made a somewhat baroque implementation of what you seem to be wanting
for my Actor.t module.

doAskAbout(actor, io) = {
if (datatype(self.askme) == 13)
switch (proptype(io, self.askme)) {
case 3: // askme is a 'string'
"\^<<self.thedesc>> says, \"<<io.(self.askme)>>\" ";
return;
case 6: // askme is a "string" or
case 9: // a function
io.(self.askme);
return;
default:
self.disavow; // askme is defined, but I
return; // don't know how to deal
} // with it
pass doAskAbout;
}

In the actor object, define a property called 'askme', as follows:

tomActor: Actor
askme = &tomdesc
;

(Notice that askme is a pointer to a property.) Then, in every object you
want the actor to have something to say, define a 'tomdesc' property.
'tomdesc' can be a string, a double-quoted string, or a function. The code
above evaluates double-quoted strings and functions, and wraps a simple
sentence around single-quoted strings. For example,

squash: item
tomdesc = 'Yuck. I hate squash.'
;

tomato: item
tomdesc = "\"Aren't tomatoes poisonous?\" asks Tom."
;

kumquat: item
tomdesc = {
"\"Get that away from me!\" Tom says, grabbing the kumquat and
throwing it away. ";
self.moveInto(nil);
}
;

If you ask Tom about each of these items, you'll get the following
responses:

>ASK TOM ABOUT SQUASH
Tom says, "Yuck. I hate squash."

>ASK TOM ABOUT TOMATO
"Aren't tomatoes poisonous?" asks Tom.

>ASK TOM ABOUT KUMQUAT
"Get that away from me!" Tom says, grabbing the kumquat and throwing it
away.
[The kumquat is moved into nil]

Stephen

--
Stephen Granade | Interested in adventure games?
sgra...@phy.duke.edu | Check out
Duke University, Physics Dept | http://interactfiction.miningco.com


Mike Roberts

unread,
Aug 17, 1998, 3:00:00 AM8/17/98
to
J. Robinson Wheeler wrote in message <35D81B8B...@jump.net>...

>I have a general purpose sort of question for both TADS and Inform in
>the way they set up "ask NPC about X" processing.
>
>[In essence, they just look at the actual words you're asking about,
>rather than trying to resolve the words to game objects.]
>
>My question is, why do it this way? Doesn't this entail checking every

>noun and adjective in the game to match topics?
The original TADS approach was, in fact, to resolve the words to objects,
and then base the response on the objects. You can still do this with the
current adv.t by overriding doAskAbout in your actors.

The problem with the object approach, and the reason most people prefer the
word-based approach instead, is that disambiguation is so difficult when
asking about something. The adv.t approach to disambiguation for the
indirect object of "ask" and "tell" is simply to pick an object at random
that matches all of the words that the player uses. This works fine for
words that only exist in the game as topics to ask about, but the rest of
the time it's pretty bad, since there are often wildly different objects in
a game that happen to have a noun or two in common.

To make the object-based system work, you'd have to come up with a way to
resolve the indirect object noun phrase to an object. I haven't been able
to find a good way to do this in general for "ask" and "telL"; it seems
easier to just let each actor do the resolution individally, which is really
what the string-matching approach boils down to.

I agree with you, though, that this isn't a wonderful solution -- I'd like
to find a better way.

--Mike Roberts
Note: to reply by email, please remove the "-SEENOTE" suffix (including the
hyphen) from my username, and replace it with a single underscore.


Mary K. Kuhner

unread,
Aug 17, 1998, 3:00:00 AM8/17/98
to
In article <35D32E...@hotmail.com>, Aryko <ar...@hotmail.com> wrote:
>I was all set to agree with Harrison here, if not for just one point.
>It's simply that a great way to break the flow of a game is if the
>player types 'Ask Bob about photograph' twice in a row. You'll get the
>same two pages of dialogue, instead of a character saying "I've already
>told you that!"

>So in this case, you want to have multiple responses for an 'ask'
>command simply to allow for the NPC to tell the player that they should

>have been paying attention the first time. As well, you can tie in
>later events - say the character asks someone else about the photograph,
>and they learn more about it, the PC could return to Bob and try ask bob
>about photograph again, and this time get more information.

On the other hand, sometimes the player desperately needs to see
the two pages of dialog again, and will resent being made to restart
the game to get them. In the Comp97 "Madame L'Estrange" I failed to
write down someone's name when it was mentioned by an NPC, and
then could not get the same dialog to occur a second time (since the
game knew I'd seen it once already). In real life, while you might
not get the same dialog again, neither is it completely impossible
to recapture a detail you missed. "I'm sorry, could you tell me
the Police Chief's address again? I didn't quite catch it the first
time."

So you need a balance between the boring and mimesis-breaking
repetition of everything, and the frustrating and game-breaking
repetition of nothing.

Mary Kuhner mkku...@genetics.washington.edu

Magnus Olsson

unread,
Aug 17, 1998, 3:00:00 AM8/17/98
to
In article <6r9rvj$hkm$1...@inet16.us.oracle.com>,

Mike Roberts <mjr-S...@hotmail.com> wrote:
>The original TADS approach was, in fact, to resolve the words to objects,
>and then base the response on the objects. You can still do this with the
>current adv.t by overriding doAskAbout in your actors.
>
>The problem with the object approach, and the reason most people prefer the
>word-based approach instead, is that disambiguation is so difficult when
>asking about something. The adv.t approach to disambiguation for the
>indirect object of "ask" and "tell" is simply to pick an object at random
>that matches all of the words that the player uses. This works fine for
>words that only exist in the game as topics to ask about, but the rest of
>the time it's pretty bad, since there are often wildly different objects in
>a game that happen to have a noun or two in common.

We had a rather long discussion about this on this newsgroup some time
ago. One quite powerful solution, which was suggested by several
people, is to have a special set of objects representing each topic
that can be talked about, even when this means duplication. For
example, even if there's a black pearl in the game, one should have a
special object representing the conversational topic called "black
pearl". One would of course have to program disambiguation so that
"black pearl" in "take black pearl" would refer to the pearl itself,
and in "ask troll about black pearl" it would refer to the topic. I'm
not quite sure on how difficult this is in TADS - would it suffice to
add the appropriate verIoAskAbout methods?

--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------

TenthStone

unread,
Aug 17, 1998, 3:00:00 AM8/17/98
to
bdu...@bigfoot.com (Bryan Dunphy) caused this to appear in our collective minds on Sat, 15 Aug 1998 23:54:19 GMT:

>My currently proposed solution is to add a command allowing the player
>to "think about" things in the game. This would allow the player to
>discover the things he/she should already know without me having to
>begin the game with several screen full of exposition and a warning to
>take notes.

Well, I'm writing a very complicated parsing routine for TADS which enables the
use of rather complex natural questions. It's a week or so (I hope) from completion.

It would undoubtedly be much easier to implement a simple verb, such as:

>what is an apple
If you don't know, there's not more I can do.

>who is John Galt

Why, John Galt is the man who stopped the motor of the world!

>Emily, who is John Galt

Emily looks at you blankly. "Who?"

>how am I

Oh, you're fine.

>who am I

Or perhaps you're not.

Suzanne Skinner

unread,
Aug 17, 1998, 3:00:00 AM8/17/98
to
Hello,

I can only help with TADS, as I don't use Inform...but perhaps the same
general principles apply here, in both languages.

J. Robinson Wheeler <whe...@jump.net> wrote:

> Today I decided to replace this generic routine with something that used
> the original doAskAbout for Actors in ADV.T, and when my compiler crashed,
> I realized that TADS did the same thing -- gave you a list of strings with
> which to make comparisons, instead of objects that had properties that
> one could distinguish.

The default doAskAbout for Actors in TADS is set up to use objwords to
extract the vocabulary words you used to refer to an object, then passes
information on those to a function you write on the actor called
askWord(word, lst) (see recent askWord thread for more of this). You
can eliminate this behavior by, as you did before, overriding
doAskAbout.

> My question is, why do it this way?

The basic problem is that, if you type "ask john about the tree", and
there are a bunch of tree objects in the game, you have no way of knowing
which object will get selected by the parser. The default implementation
of the ask verb chooses the first matching object it finds and ignores the
others. By using words instead of objects, you avoid this problem: just
compare the word to 'tree', and output the appropriate text if it matches.

This method is clunky in some ways, and a year or so ago I attempted to
create a better ask system. This involved eliminating the code in askVerb
that chooses only the first matching object, so that normal disambiguation
will be performed. Now, ask can refer to any object anywhere in the game,
not just in the current location, so this can lead to tricky disambiguation
problems. I thought I could fix this by allowing only objects of type "topic"
to be asked about--others failed when verIoAskAbout was called on them.
This can be enhanced by putting a "known" flag on each topic, and having
its verIoAskAbout fail also if the player does not know about that topic
yet. As I recall you need to switch the order of io/dobj verification so
that verIoAskAbout can call the actor's disavow method.

So, in the disambiguation question (if any), only the objects that pass
verification will be included. All that remains is to make sure all
topic objects can be successfully disambiguated.

All fine and good, except for one catch: If EVERY matching object fails on
verification, the parser proceeds to ask a disambiguation question for all of
them, so it knows which failure message to print. In a complex game, this can
lead to such mimesis-shattering ugliness as "Which tree do you mean, the tree,
the tree, the other tree, the oak tree, the hickory tree, the trees, the birch
tree, or the tree?" I haven't figured out a way to change this behavior. What
I would like it to do in that case is to just output Actor.disavow.

Also, I'm not sure I want a player to be able to find out all the objects of a
particular type X they can ask about, by typing "ask actor about X". I'd
rather they have to ask about the particular object, otherwise get a disavow
response. This can be done via the askWord method.

So in the end, handling ask by examining words works better. If you want
the best of both worlds, modify relevant functions, such as doAskAbout,
so that disavow (the function called if the actor has no response to
a particular topic) is called with an "object" argument. This way you can
have object-tailored disavows like you want. Just keep in mind that what that
object is may vary if one or more objects match the io phrase.

-Suzanne

--
http://dominion.cba.csuohio.edu/~tril/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d- s--:- a-- C++$ ULHOIS+++$>++++ P+++ L+>++ E W+++$ N++(+) !o K++ w---()
!O M-- V-- PS+@ PE@ Y+() PGP- t+ 5+ X+ R !tv(+) b++@ DI++ D--- G++ e++* h---
r++>+++ x*?
------END GEEK CODE BLOCK------

Suzanne Skinner

unread,
Aug 17, 1998, 3:00:00 AM8/17/98
to
Magnus Olsson <m...@bartlet.df.lth.se> wrote:

> We had a rather long discussion about this on this newsgroup some time
> ago. One quite powerful solution, which was suggested by several
> people, is to have a special set of objects representing each topic
> that can be talked about, even when this means duplication. For
> example, even if there's a black pearl in the game, one should have a
> special object representing the conversational topic called "black
> pearl". One would of course have to program disambiguation so that
> "black pearl" in "take black pearl" would refer to the pearl itself,
> and in "ask troll about black pearl" it would refer to the topic. I'm
> not quite sure on how difficult this is in TADS - would it suffice to
> add the appropriate verIoAskAbout methods?

Hmmmm....now THIS is an idea that's never struck me (I've missed long
stretches of newsgroup talk as I've lurked in and out over the years). I
assume you mean for topic objects to be floating items that are always in
the player's location (since you speak of a need to disambiguate between
topics and regular items)? This would solve the problem I mentioned in my
last post about this, where when all verification methods fail, a
disambiguation question covering all matching items would be printed. In
this case the question would only include items in the current
location.....You'd modify the ask verb so that it works like regular verbs
in that respect.

Actually, now that I think about it, it doesn't fully solve the problem. At
least, not if you want topics that fail verification if you don't know about
them yet (and I think you do, otherwise a disambiguation question might give
away more than is desired). This could lead to a question like "which black
pearl do you mean, the black pearl or the black pearl?", if both the topic
and the item failed. But then, if you are in the location with the other
black pearl, chances are you DO know about the topic.....

But then again, having all these extra floating items in the room with you
could cause problems with other verbs, related to the "all verifications fail"
condition.

Anyway, I'm rambling. This seems like it could be made to work. For myself,
I wouldn't mess with it, because there are so many gobs of ASK/TELL topics
in my game at this point that it is more efficient not to have individual
topic objects for all of them.

Dan Shiovitz

unread,
Aug 17, 1998, 3:00:00 AM8/17/98