NPC Conversation ideas
michael...@ey.com
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
>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
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.
>
>
> were disabled, and all NPC conversation syntax worked thusly:
>
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
> 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
>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
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
> 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
>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
> 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
>>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
>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
: 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
> 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
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
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
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
> 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
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
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
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
> 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
>
>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
> 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
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
> 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
Wouldn't going to the red light district be easier?
(ba dum psh!)
--
mat...@area.com
Doeadeer3
"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
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.
>
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
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
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
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
<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
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
> 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
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
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
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
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
[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
[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.
(maintained by me) at 'http://homepages.ihug.co.nz/~daleys/'.
--
Nicholas Daley
<link_...@geocities.com>
Lucian Paul Smith
: 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
> 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
>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
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
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
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
>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
[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
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
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
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
> 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
>I have a general purpose sort of question for both TADS and Inform in
>the way they set up "ask NPC about X" processing.
>
>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?
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
>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
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
>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
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
> 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
Suzanne Skinner <tr...@dominion.cba.csuohio.edu> wrote:
>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
>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
There's some nice scoping tricks you can play with in TADS to get it so
you only ask about known "topic" items. I've written up some sample code to do
it. It's not quite complete: you'd really want to tweak error message #9
("I don't see any foo here") to something more appropriate, and maybe use
Stephen Granade's disambiguation hack ('Bob asks, "which foo do you mean, the
blue foo or the red foo?'). But it's got the scoping stuff right, I think.
#include <adv.t>
#include <std.t>
startroom: room
sdesc = "bob's room"
ldesc = "yay"
;
fred: Actor
sdesc = "Fred"
thedesc = "Fred"
adesc = "Fred"
ldesc = "Fred is made out of twine and pudding."
noun = 'fred'
location = startroom
;
replace preinit: function
{
local o;
global.lamplist := [];
o := firstobj();
while( o <> nil )
{
if ( o.islamp ) global.lamplist := global.lamplist + o;
if ( isclass(o, hasPreinit) ) o.preinitCode;
o := nextobj( o );
}
initSearch();
}
class hasPreinit: thing;
class topic: hasPreinit
preinitCode =
{
global.topiclist += self;
}
known = nil // known to player?
;
modify global
topiclist = []
;
modify askVerb
validIo(actor, obj, seqno) =
{
return(isclass(obj, topic) and obj.known);
}
validIoList(actor, obj, seqno) =
{
return global.topiclist;
}
;
lemming: topic
sdesc = "lemming"
noun = 'lemming'
adjective = 'yellow'
known = true
;
lemon: topic, item
sdesc = "lemon"
noun = 'lemon'
adjective = 'yellow'
location = startroom
;
lemonDrop: item
sdesc = "lemon drop"
noun = 'drop'
adjective = 'lemon'
location = startroom
;
>-Suzanne
--
Dan Shiovitz || d...@cs.wisc.edu || http://www.cs.wisc.edu/~dbs
"...Incensed by some crack he had made about modern enlightened
thought, modern enlightened thought being practically a personal buddy
of hers, Florence gave him the swift heave-ho and--much against my
will, but she seemed to wish it--became betrothed to me." - PGW, J.a.t.F.S.
Adam J. Thornton
TenthStone <mcc...@erols.com> wrote:
>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.
Mark this, folks. This sounds like GKW in late 1993 about Avalon....
J. Robinson Wheeler
> 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.
Perhaps if there were some way to subvert the handling of the word
"again" as a meta-command and allow you to do something like this:
>ASK BOB ABOUT ADDRESS
Bob says, "1164 Morning Glory Circle."
[later]
>ASK BOB ABOUT ADDRESS
Bob says, "But I told you already."
>G
Bob says, "But I told you already."
>ASK BOB ABOUT ADDRESS AGAIN
You say, "Tell me again."
Bob says, "1164 Morning Glory Circle."
>G
You say, "Tell me again."
Bob says, "You really should get a notepad!"
Bob says, "1164 Morning Glory Circle."
Trevor Barrie
wrote:
>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)?
Why is this necessary? Does ADV.T's disambiguation only look at objects
in the same room as the player, for _all_ verbs? If so, is that really a
good idea?
I'm not entirely clear what the problem is here, but I think Worldclass
solves it... under Worldclass, if you try to ask or tell about "tree",
say, and the Player knows about more than one tree(*), you get a
disambiguation question, same as if you type "get book" when multiple
books are at hand. Seems pretty straightforward.
* - more than one tree with the appropriate parameter set to true, that
is. I think the parameter is "isatopic".
Suzanne Skinner
> Why is this necessary? Does ADV.T's disambiguation only look at objects
> in the same room as the player, for _all_ verbs? If so, is that really a
> good idea?
For most verbs, yes. For most verbs, it's a good idea. But this can be
overridden (as it is for ask/tell in the standard adv.t).
I was considering the possibility of treating ask as a normal verb and
then having all askable topics follow the player around, to avoid
scoping problems. There are probably better ways to do this though--
with validIo and validIoList? I know that back when I was trying to
reimplement askVerb, I didn't know much about how those functions worked,
so tried (and failed) to use mainly verIoAskAbout tricks to get it to
work.
> I'm not entirely clear what the problem is here, but I think Worldclass
> solves it... under Worldclass, if you try to ask or tell about "tree",
> say, and the Player knows about more than one tree(*), you get a
> disambiguation question, same as if you type "get book" when multiple
> books are at hand. Seems pretty straightforward.
That does sound like the best way for most games. I haven't done much with
WorldClass myself, but am curious as to how it makes this work.
Magnus Olsson
Suzanne Skinner <tr...@dominion.cba.csuohio.edu> wrote:
>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
>> 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?
>
>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
>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.
>
>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
>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.
Sorry for quoting so much, but if I didn't I would have to
recapitulate all the important points :-).
This isn't quite what I meant. To explain what I meant, I'll talk
about Inform, since I've only thought about this in an Inform context
(and, frankly, my TADS is a bit rusty right now).
Anyway, what you do is this: Program your verbs so that the only
objects that can be in scope for "ask about" are the special topic
objects, and that these objects are never in scope for any other
verb. I'm not sure that you can control scoping in this way for TADS,
in which case you may have to use disambiguation instead.
For the topic objects, make sure that those that the player knows
about are in his/her scope. This could be done by moving them to the
player's location and making them floaters so they move along with
him/her.
>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.
You'll have to weight the added complexity of duplicating all the
objects that are both tangible things and topics against the reduced
complexity of your "ask about" code.
You may want to look up the following thread on DejaNews: the first
post is dated October 26, 1997, and the subject line is "Encyclopedias
and Omniscient Trolls: About scope, disambiguation and NPC
Conversation".
Suzanne Skinner
> You may want to look up the following thread on DejaNews: the first
> post is dated October 26, 1997, and the subject line is "Encyclopedias
> and Omniscient Trolls: About scope, disambiguation and NPC
> Conversation".
Thanks :-)
You can control scoping to a large extent in TADS, but it's probably not as
straightforward as in Inform. And I don't know as much about it as I should
:-)
TenthStone
>In article <35d8870...@news.erols.com>,
>TenthStone <mcc...@erols.com> wrote:
>>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.
>
>Mark this, folks. This sounds like GKW in late 1993 about Avalon....
It's a good thing you're not insinuating that I'll never complete this routine,
because I've just... uh, done... i...
Just you wait.
And wait.
And wait.
Jonadab the Unsightly One
<6rc9dg$5r4$1...@bartlet.df.lth.se>...
>
> Anyway, what you do is this: Program your verbs so that the only
> objects that can be in scope for "ask about" are the special topic
> objects, and that these objects are never in scope for any other
> verb.
Of course.
No, actually, I have mine set up so that the topics are on an earlier
grammar line for ask about, so that they get precidence (if any of
them match, the other grammar line allowing any object in the game
never is reached). But same idea.
> For the topic objects, make sure that those that the player knows
> about are in his/her scope. This could be done by moving them to the
> player's location and making them floaters so they move along with
> him/her.
Or your scope routine could PlaceInScope only those topic
objects that have KnownAbout (or whatever attribute you use -- you
could even alias a library attribute in this case if you do so with care.)
> You'll have to weight the added complexity of duplicating all the
> objects that are both tangible things and topics against the reduced
> complexity of your "ask about" code.
This is where my extra grammar line comes in. If none of the
special topics fits, any object in the game can be picked up by
the next grammar line. Of course, the standard objects do not
have all the special conversational hoopla of the conversation
topic objects, so each NPC only has (at most) one thing to say
about each regular object, or possibly a random selection,
but no special train of conversation or anything complex like
that -- that is what the special topics are for.
Phil Goetz
Harrison Farlane <ha...@zerospam.com> wrote:
>Laurel Halbany wrote:
>[snip]
>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.
I don't. Unless I'm playing a detective. If I'm doing something that
wouldn't call for taking notes in real life, why should it call for taking
notes in a game? That spoils my suspension of disbelief. Generally, I like
to just sit down and play.
Of course, this may be why I have never finished anything larger than
John's Fire Witch. But I'd usually rather quit the game than have to switch
to note-taking. When a game starts handing me lots of data, and I see they
want me to play the "write all this stuff down and match it up" game,
I quit.
Phil
Bryan Dunphy
okbl...@usa.net wrote:
> In article <35d616ca....@news.supernews.com>,
> bdu...@bigfoot.com (Bryan Dunphy) wrote:
> > 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.
[Making note to self.] Thanks for mentioning that, it's what you'd
call "so obvious I overlooked it".
>
> It could be very good and very interesting all by itself! But I
> suspect you have more in mind?
Yes, but as it's still a work (and plot)-in-progress, I rather not
post it to Usenet.
>
> 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.
>
> It's probably the #1 barrier to me playing more IF.
Same here. That's why I'm trying to design my game so that the need
for the player to take notes by hand is minimized.
Chris Nebel
>Perhaps if there were some way to subvert the handling of the word
>"again" as a meta-command and allow you to do something like this:
>
> (example with "ASK BOB ABOUT ADDRESS" vs. "ASK BOB ABOUT ADDRESS AGAIN")
I messed with a technique to warn about, yet still allow, dangerous
actions (fatal, actually!); seems like it might work here. It goes a
little like this:
>ASK BOB ABOUT PHOTOGRAPH
"I already told you about that," Bob says patiently.
[At this point, the game sets a flag in Bob (or wherever) indicating that
you asked him. In my implementation, the flag expires when you leave the
room -- it could simply be on, say, a 4-turn timer.]
>G
[The game checks the flag and sees that you tried this action "recently",
whatever that's defined as, so now you get a longer response.]
"Oh, if you insist. That's Fred Thwimblebottom, heir to his family's
massive alpaca-herding fortune."
Essentially, if you try a command, the game blocks you for whatever
reason, and then you try the same command again, it means "look, I don't
care what you think about it, just _do_ it!" My original use involved
diving into shark-infested waters (which you would later de-fest, making
them safe), so I wanted a "warn them first, but if they're determined to
be stupid, give 'em a good death scene" kind of effect.
This does sort of require some explanation to the player beforehand,
otherwise folks might easily assume that the first response ("I already
told you") is all they're going to get. On the other hand, it completely
avoids any problems with trying to use "again" as an adverb.
The thing is, if you're going to have a distinct response on the second
time ("Oh, if you insist"), you might as well skip all this "I already
told you" business and go straight to the modified response.
Here's an idea: the very first time, you get the full deal ("Oh, gee, let
me think about that..."). After that, you could have two or three
progressively more testy responses cooked up -- each time you ask the
question, Bob goes to the next response, but then a timer will knock him
back _down_ one response every few turns. That way, if you pester him,
he'll get annoyed and stop answering you, but if you go away for a little
while, he'll calm down and be willing to talk again.
-Chris Nebel
TenthStone
dismabiguation routine in TADS, so I will do so, following the lead of
countless (well, maybe only if you're not that smart) others.
The way this works is that every item has an isseen property (I think this
is a good idea anyway, but that may be just me). To make an object
alludable to at start, merely initialise its isseen property to true.
To declare that Object A is "similar" (that is, effectively interchangeable
as regards asking about them) to Object B, have Object A's .isSimilarTo
property return Object B. So, if you have twenty locations with multiple trees
each, and you define a separate object for each tree, and every tree is really
just decoration except one great oak in the center (there's a wonderful game for
you: just climb every tree in the forest until you find the one with the
jewel-encrusted egg up it), then all your similar trees (Object As) should have
.isSimilarTo set to whichever object you feel like putting the handlers on (Object B),
and the great oak should have .isSimilarTo = nil (or to itself, whatever works. Heck,
the way I've set up the architecture up, all Object As could just point to takeVerb
and it wouldn't make a whole lot of difference.)
Note that Object B should have catch-all vocabulary: that is, it should always have
all of the vocabulary used in objects which point to it. Say the player types in
>ask Andre about willow tree
and all of the willow tree objects are defined (briefly):
willowTreeX: treeobj
noun = 'willow' 'tree'
adjective = 'willow'
plural = 'willows' 'trees'
isSimilarTo = pineTreeInOurMidst
;
Whereas Object B, pineTreeInOurMidst, is defined:
pineTreeInOurMidst: treeobj
noun = 'pine' 'tree'
adjective = 'pine'
plural = 'pines' 'trees'
isSimilarTo = nil
;
Then Object B, without the adjective "willow", will not be in the list of objects passed
to validIo and will thus not be part of the object.
As per disambiguation methods: the problem, of course, is when nothing matches:
that is, when no objects on the valid list are known to the actor (genuine
disambiguations, such as "Which king's quest do you mean: King's Quest IV or King's
Quest V?", are not as serious. My solution is limited by the fact that parseDisambig
receives neither the actor nor the direct object nor the verb, and although we can indirectly
pass it the actor (and the verb, for that matter) no methods are called with the direct object
until later.
Note that in init(), you must use Me.travelTo( startroom ) instead of Me.moveInto( startroom ),
else the objects there were NOT have .isseen until startroom is re-entered.
preparseCmd: function( lst ) { // As a cheap cop-out to further modifications or
if ( global.curverb ) { // daemons. Initialises these values before
global.curverb.hasValid := nil; // command-processing time. Any custom
global.curverb := nil; // preparseCmd code can easily follow.
} // Returning true means "leave command alone."
return true;
}
parseDisambig: function( str, lst ) { // Part i is my addition; the rest is the default.
if (global.curverb <> nil and not global.curverb.hasValid)
"You need to be more specific about which << str >> you mean. ";
else {
local i, tot, len;
"Which << str >> do you mean, ";
for ( i := 1, len := length( lst ); i <= len; i++ ) {
lst[i].thedesc;
if (i < cnt) ", ";
if (i + 1 = cnt) "or ";
}
"?";
}
}
replace askVerb: deepverb
verb = 'ask'
sdesc = "ask"
hasValid = nil
prepDefault = aboutPrep
ioAction( aboutPrep ) = 'AskAbout'
validIo( actor, obj, seqno ) = {
if (seqno = 1) global.curverb := self; // Okay, this is the verb
if (obj.isseen) { // If the object has been seen
local simobj := obj.isSimilarTo;
if (simobj) { // if Object B exists
if (simobj = obj) { // and is same as obj
self.hasValid := true; // obj is okay
return true;
}
else return nil; // If Object B is not obj, obj is not okay
}
else return true; // If Object B does not exist, obj is okay
}
else return nil; // If obj has not been seen, obj is not okay as topic
}
validIoList(actor, prep, dobj) = (nil) // All objects, theoretically, are possible
;
replace tellVerb: deepverb
verb = 'tell'
sdesc = "tell"
prepDefault = aboutPrep
ioAction( aboutPrep ) = 'TellAbout'
validIo( actor, obj, seqno ) = {
if (seqno = 1) global.curverb := self;
if (obj.isseen) {
local simobj := obj.isSimilarTo;
if (simobj) {
if (simobj = obj) {
self.hasValid := true;
return true;
}
else return nil;
}
else return true;
}
else return nil;
}
validIoList(actor, prep, dobj) = (nil)
ioDefault( actor, prep ) = {
if (prep = aboutPrep) return([]);
else return(actor.contents + actor.location.contents);
}
;
modify room
enterRoom( actor ) = {
self.lookAround(( not self.isseen ) or global.verbose );
if ( self.islit ) {
if (not self.isseen) self.firstseen;
setseen( self ); // Set all visible objects here to
} // .isseen
}
;
setseen: function( obj ) {
obj.isseen := true; // Set this obj to isseen
if (obj.issurface or obj.contentsVisible) {
// If object is a surface or its contents are visible:
// (contentsVisible returns true for most objects,
// for openable it returns .isopen)
local lst, len, i;
lst := obj.contents; // Take all contained objects and
len := length( lst ); // set all visible objects within THEM
for ( i := 1; i <= len; ++i ) { // to .isseen
setseen( lst[i] );
}
}
}
modify openable // When an object's contents are exposed, set all visible contents
doOpen( actor ) = { // to .isseen
if (itemcnt( self.contents )) {
"Opening "; self.thedesc; " reveals "; listcont( self ); ". ";
}
else "Opened. ";
self.isopen := true;
setseen( self );
}
;
Thank you and good night.
The Alienist
If the game is going to be complicated, maybe you could implement a kind
of 'notebook' function, so that when significant (and insignificant)
events take place, a brief version of it is written to it, containing
all the important (or seemingly important) info.
Of course, this advise is written from deep within the safe, plush realm
of Ignorance, as I have no idea as to how difficult such a function
would actually be to implement. I'm pretty damn new to coding, and as we
all know, everything's easy until you know something about it...
The Alienist
Daryl McCullough
(maybe solve-the-crime types) it might make sense to assume
that the playing character is taking notes about what people
say. In that case, to find out what somebody said earlier,
you could just consult your notes, rather than ask them again.
In Return to Zork, an idea like this was implemented. Instead
of notes, you had (1) a tape recorder, and (2) a camera. But
a notebook is the text-based way to do it.
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
John Francis
I hope the modified respose is just a presentation difference, and
not a new response containing additional useful information.
I'm opposed to all that kind of thing. Viewed locally it might make
for a more 'realistic' interaction, but from a global standpoint it
reduces the game to a boring sequence of "go back to everyone you
have ever met and keep asking them questions in case something new
turns up in their answers". That doesn't make for interesting play.
I can accept the need to EXAMINE items to see all the details, but
I don't like games where SEARCH is sometimes needed to reveal stuff
that EXAMINE doesn't. It doesn't make the game harder on an
intellectual level - it just adds more boring mechanical repetition
to the technique of playing the game. All this tiresome dribbling
information in a piecewise fashion is another way of putting the
game mechanics in the way of progress. It's a maze in disguise.
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Hello. My name is Darth Vader. I am your father. Prepare to die.
Chris Nebel
(John Francis) wrote:
>>The thing is, if you're going to have a distinct response on the second
>>time ("Oh, if you insist"), you might as well skip all this "I already
>>told you" business and go straight to the modified response...
>
>I hope the modified respose is just a presentation difference, and
>not a new response containing additional useful information.
Sure, at least in the case where you're just repeating yourself. It's
simply a way to have Bob not be totally repetitive (and possibly to
simulate him being annoyed by your pestering him.)
>I'm opposed to all that kind of thing. Viewed locally it might make
>for a more 'realistic' interaction, but from a global standpoint it
>reduces the game to a boring sequence of "go back to everyone you
>have ever met and keep asking them questions in case something new
>turns up in their answers". That doesn't make for interesting play.
I agree with you if the mechanics are indeed as you describe -- simply
brute force asking everyone about everything repeatedly until something
new turns up. Now, repeating the same question and getting an entirely
new response might be acceptable if something has happened to suggest that
you _should_ get a new response. Consider the following exchange:
>ASK JOE ABOUT BOB
"Ask him about alpacas."
>N. E. S.
Bob is here.
>ASK BOB ABOUT ALPACAS
"I have no idea what you're talking about," Bob says guardedly.
>ASK BOB ABOUT ALPACAS
"I said, I have no idea what you're talking about," Bob snarls.
>ASK BOB ABOUT ALPACAS
Bob ignores you.
[Bob's response changes slightly, but doesn't supply any new information.]
>W
A Closet
There is a photograph here.
>GET PHOTO THEN EXAMINE IT
Taken. It's a photo of Bob and an alpaca in a rather compromising position.
>E. ASK BOB ABOUT ALPACAS
[Now we have incriminating evidence, so...]
"I have no idea what you're talking about," Bob says guardedly.
"I think you might," you say, showing him the photograph.
"All right! All right! I confess!" Bob cries. "I was young! I was
foolish! I didn't inhale!"
In the above scenario, "SHOW PHOTO TO BOB" might have worked just as well
as asking him about alpacas again, but you can imagine other situations
where you're working based on knowledge that other NPCs have related to
you. Console RPGs use roughly this technique all the time, though they're
usually working with a far simpler conversation model (either a
conversation tree or the equivalent of "TALK TO BOB"), so it's more
obvious to the player that they have choices they didn't have before.
-Chris Nebel
sdan...@bcharrispub.com
an NPC?
Thanks,
Sarah
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
okbl...@usa.net
go...@cs.buffalo.edu (Phil Goetz) wrote:
>
> Of course, this may be why I have never finished anything larger than
> John's Fire Witch. But I'd usually rather quit the game than have to switch
> to note-taking. When a game starts handing me lots of data, and I see they
> want me to play the "write all this stuff down and match it up" game,
> I quit.
>
Hear, hear!
[ok]
okbl...@usa.net
bdu...@bigfoot.com (Bryan Dunphy) wrote:
>
> [Making note to self.] Thanks for mentioning that, it's what you'd
> call "so obvious I overlooked it".
>
Reality is a funny thing, isn't it? Things that are obvious to one person
go completely unconsidered by another. (And with that, my pseudo-profound
comment of the day, I retreat to study further in the swamps of Foofaral.)
okbl...@usa.net
sdan...@bcharrispub.com wrote:
> I know this is a stupid question, so please nobody make fun of me....What is
> an NPC?
>
Not stupid, just ignorant. And we're all ignorant about most things, so....
:-)
NPC is an acronym for "Non-Player Character". A simple example: You play a
game about you and your dog, and the computer makes the dog behave in
dog-like ways. (If you pet it, it wags its tail; if you give it food, it
eats; etc.) The dog is an NPC.
It's a modelling of some sort of intelligence, most basically. Because of
the nature of computers and the current state of AI, all things about
interactive fiction are mechanical--but some do a very good job of making you
think they are not.
But at that point we get into value judgements. :-) An NPC is an attempt by
an author to give you the feeling that a character other than yourself exists
in the game.
Michael Gentry
The Alienist wrote in message <35DA79...@mysurf.com>...
>If the game is going to be complicated, maybe you could implement a kind
>of 'notebook' function, so that when significant (and insignificant)
>events take place, a brief version of it is written to it, containing
>all the important (or seemingly important) info.
>
>Of course, this advise is written from deep within the safe, plush realm
>of Ignorance, as I have no idea as to how difficult such a function
>would actually be to implement. I'm pretty damn new to coding, and as we
>all know, everything's easy until you know something about it...
>
>The Alienist
I LOVE it when games provide this function (in fact, it was one of the only
good points in the otherwise excreble "Black Dahlia").
Maybe there's some way to use the Z-machine to write text to a text file,
and then display the contents in response to a player command? I'm pretty
ignorant of the whole interpreter side of things myself. Anyone have any
ideas?
--M
"If you don't eat your meat, you can't have any pudding.
How can you have any pudding if you don't eat your meat?"
Daryl McCullough
>
>I know this is a stupid question, so please nobody make fun of me....What is
>an NPC?
This is a courteous newsgroup. We never make fun of anyone.
NPC stands for "nonplayer character". Typically, in a game, one
(or maybe more) characters (people in the game) are controlled
by the player. Everyone else appearing in the game is an NPC.
Michael Gentry
Chris Nebel wrote in message ...
>
>Now, repeating the same question and getting an entirely
>new response might be acceptable if something has happened to suggest that
>you _should_ get a new response. Consider the following exchange:
>
If you'd like a concrete example, this is pretty much the idea behind the
bum puzzle in "Anchorhead".
Michael Gentry
Daryl McCullough wrote in message >
>This is a courteous newsgroup. We never make fun of anyone.
>
Not true. We often make fun of that guy who's been writing "Avalon" since
about 1962.
Michael Gentry
John Francis wrote in message <6rf0ot$71...@fido.engr.sgi.com>...
>In article <c.nebel-1808...@nebelch.apple.com>,
>I can accept the need to EXAMINE items to see all the details, but
>I don't like games where SEARCH is sometimes needed to reveal stuff
>that EXAMINE doesn't. It doesn't make the game harder on an
>intellectual level - it just adds more boring mechanical repetition
>to the technique of playing the game. All this tiresome dribbling
>information in a piecewise fashion is another way of putting the
>game mechanics in the way of progress. It's a maze in disguise.
>
I agree with you insofar as *needless* dribbling of information is
unnecessary and undesirable -- but I do think that in general it's both
handy and realistic to make EXAMINE and SEARCH two different verbs with
different possible results.
In the case of, say, a coffee mug, it would probably be reasonable to assume
that looking AT it and looking IN it are one and the same action, and SEARCH
and EXAMINE should be made accordingly synonymous. But that's not
necessarily the case for, say, a big trenchcoat with lots and lots of
pockets. And I would argue that EXAMINING a dumpster full of stinking refuse
is very, very different from SEARCHING it.
Certainly, it can lead to some needless partitioning. (TADS in particular
seems to have this strange discrepancy where SEARCH and LOOK IN and
sometimes LOOK THROUGH are all *separate* verbs, which drives an Inform
player like myself absolutely bugfuck.) But if the author handles it well
(and that's always the trick, innit?), it's simply a handy way to uphold
mimesis.
John Francis
I'm still not convinced. All this means is that the simple routine of
"EXAMINE every object in the room description" needs to be replaced by
"EXAMINE every object; SEARCH every object".
No more challenging, intellectually - just a little more tiresome.
And most of the time you don't get any additional information.
And generally there's no way for you to know whether SEARCH will reveal
any additional information unless you try it.
I'd much rather see EXAMINE and SEARCH be synonyms, and have additional
detail be revealed by either.
> SEARCH DUMPSTER
Poking around in the dumpster reveals a small wickerwork hamper
partially hidden beneath a roll of carpet.
At this point you could:
EXAMINE the hamper
EXAMINE the carpet
MOVE the carpet
All of these actions (and several others, no doubt) are now reasonable,
because of the additional information you got by your earlier actions.
But none of these actions would work until you had looked in the dumpster.
(See the other discussion about whether to use 'concealed' or to simply
instantiate the objects into the room at the appropriate time).
Daryl McCullough
>
>
>Daryl McCullough wrote
>
>>This is a courteous newsgroup. We never make fun of anyone.
>>
>
>Not true. We often make fun of that guy who's been writing "Avalon" since
>about 1962.
I know. I was lying. I always lie.
Michael Gentry
John Francis wrote in message <6rfn05$78...@fido.engr.sgi.com>...
>I'm still not convinced. All this means is that the simple routine of
>"EXAMINE every object in the room description" needs to be replaced by
>"EXAMINE every object; SEARCH every object".
>No more challenging, intellectually - just a little more tiresome.
>And most of the time you don't get any additional information.
>And generally there's no way for you to know whether SEARCH will reveal
>any additional information unless you try it.
There isn't? I have always taken SEARCH to mean "look in" or "look
through" -- partly because I know that's how the Inform library code defines
it, but mostly because that's essentially what the word means in the English
language. Therefore, as a player, I know I'm only going to have to SEARCH
something that a) is a container or b) is a pile of stuff such as laundry or
dirt that can be dug through.
Conversely, as an author, I try to consistently make SEARCH only applicable
to such objects.
If you find yourself having to search every object in a game -- SEARCH
CHAIR, SEARCH CLOCK, SEARCH CUCUMBER -- then what you have is a rather
warped set of expectations about the game world, which may well have been
caused by a poorly designed game.
In other words, this:
> EXAMINE CUCUMBER
The cucumber is long and green.
> SEARCH CUCUMBER
You find a small wart on one end of the cucumber.
-- is a poor way to write a game. Which, I think, is what you were saying.
Which is where I agree with you.
Where I DON'T agree with you is here:
> SEARCH DUMPSTER
>Poking around in the dumpster reveals a small wickerwork hamper
>partially hidden beneath a roll of carpet.
>
>At this point you could:
> EXAMINE the hamper
> EXAMINE the carpet
> MOVE the carpet
>
>All of these actions (and several others, no doubt) are now reasonable,
>because of the additional information you got by your earlier actions.
>But none of these actions would work until you had looked in the dumpster.
Yes, but EXAMINE shouldn't necessarily give you the same thing (in regards
to the dumpster).
A big, smelly dumpster is something that I might want to check out from a
relative distance before I go poking my head into it. (Your dumpster seems
to have a rather clean, harmless assortment of furniture in it; my original
example, if you'll remember, was "full of stinking refuse" -- something you
might find behind a Cantonese restaurant in the depths of Chinatown after a
heavy rain.) I might, in this example, appreciate something like this:
>EXAMINE DUMPSTER
The rusted, hulking dumpster is filled to the brim with eye-watering
refuse -- soggy newspaper wrapped around revolting bits of rotting meat
by-products and other such pleasantries. And that's just what you can see
from where you're standing.
>SEARCH DUMPSTER
Holding your breath, you climb up the dumpster's metal side and plunge your
arm into the damp, fly-blown filth. After rooting around for a few minutes,
you discover a rolled-up carpet, partially buried beneath what appears to be
a half-eaten dog carcass.
>AGAIN
You can't bring yourself to go digging in there again. The very thought
makes you gag.
Usually, if EXAMINING something could easily involve looking inside it as
well in a single glance -- for example, in the case of a coffee mug or a
kitchen sink -- I will go ahead and make the verbs synonymous *for that
object.* Something that can't be intuitively searched gets the default "You
see nothing special" message.
But if looking at an object and looking inside (or pawing through) that
object seem like they would involve different physical actions in the real
world, I'll make the verbs separate.
David Brain
> When a game starts handing me lots of data, and I see they
> want me to play the "write all this stuff down and match it up" game,
> I quit.
Do you not have e.g. a diary with appointments and telephone numbers in
it? Do you not say "Hang on a second, I'll write that down" when you are
on the phone? Do you never refer to printed reference material?
It's exactly the same as making notes in a game.
--
David Brain
London, UK
> Light creates shadow; light destroys shadow. <
> Such is the transience of darkness. <
Adam J. Thornton
>Not true. We often make fun of that guy who's been writing "Avalon" since
>about 1962.
Actually, since November 23, 1963.
And Matt Barringer. We make fun of him a lot.
Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
Frank Filz
them, I would expect the following to happen:
> EXAMINE POLICE CAR
The police car is a North Carolina State Highway Patrol Car. An officer
is sitting in the front seat eating a dougnut and reading the paper.
> SEARCH POLICE CAR
The officer says "Excuse me mister, but just what do you think you're
doing?"
Now if you really needed to find something in the police car, the dialog
might go something like:
> EXAMINE POLICE CAR
The police car is a North Carolina State Highway Patrol Car. An officer
is sitting in the front seat eating a dougnut and reading the paper.
> Z
The officer gets out of the police car and goes into the building.
> SEARCH POLICE CAR
Under the newspaper you find a folded note.
> READ NOTE
(Taken)
"Meet me under the bridge at 5:00. Signed Mr. X"
--
Frank Filz
-----------------------------
Work: mailto:ff...@us.ibm.com
Home: mailto:ff...@mindspring.com
Phil Goetz
David Brain <da...@atlan.cix.co.uk> wrote:
>In article <6rcsv5$p2q$1...@prometheus.acsu.buffalo.edu>,
>go...@cs.buffalo.edu (Phil Goetz) wrote:
>
>> When a game starts handing me lots of data, and I see they
>> want me to play the "write all this stuff down and match it up" game,
>> I quit.
>
>Do you not have e.g. a diary with appointments and telephone numbers in
>it? Do you not say "Hang on a second, I'll write that down" when you are
>on the phone? Do you never refer to printed reference material?
>It's exactly the same as making notes in a game.
>
>London, UK
I don't understand why what I do in my ordinary, boring, everyday life
should be taken as justification for game design flaws.
Some people like gathering and sorting lots of unrelated data.
I don't. (Searching for patterns in the data might be interesting --
"Science: The Game".) I got sick of jotting notes pretty early
on, back in the days of Odyssey, Ultima I, and Wizardry.
I don't know what I do or don't have to write down.
If I have to write down one combination or phone number, I don't mind,
but some games, like Fahrenheit 451, give you whole phone books of stuff
that you feel compelled to write down in case they are useful sometime later.
Blade Runner is an example of a good way to handle such clues.
Every clue you encounter, the computer keeps track of, in a large,
sophisticated, easily-managed clue database.
If you give clues that demand exact recall (like numbers,
or statements that as of yet seem meaningless), I will enjoy your game
more if I am able to easily replay that clue once I realize it is
significant.
Phil
Jonadab the Unsightly One
<u7MXxL8y9GA.185@upnetnews05>...
>
> Daryl McCullough wrote in message >
> >This is a courteous newsgroup. We never make fun of anyone.
> >
>
> Not true. We often make fun of that guy who's been writing "Avalon" since
> about 1962.
We also sometimes make fun of Luc French for not
getting along with Mr. Van Avery.
> "If you don't eat your meat, you can't have any pudding.
> How can you have any pudding if you don't eat your meat?"
I am curious about the origin of this quotation.
-Jonadab
Jonadab the Unsightly One
> I'm still not convinced. All this means is that the simple routine of
> "EXAMINE every object in the room description" needs to be replaced by
> "EXAMINE every object; SEARCH every object".
No. Examine every object. Open and look inside every closed
(openable) container, which very well might include a dumpster.
> No more challenging, intellectually - just a little more tiresome.
> And most of the time you don't get any additional information.
Most objects should not require you to search them, no.
The word "search" should not even be necessary.
But if I type "LOOK IN DUFFEL" I do not want a description of
the outside of the duffel and the monogram which indicates it
belonged to my Aunt Dorkelnoitz.
> And generally there's no way for you to know whether SEARCH will reveal
> any additional information unless you try it.
It should be obvious. The "examine" message should clue you in.
>EXAMINE DUMPSTER
The dumpster is that horrid green colour, with large rust spots and stains.
The lid is bent so that it is not quite closed completely, and a perverse
aroma emmanates therefrom, inducing a nausea you can barely ignore.
>SEARCH IT
(First opening the dumpster)
(First taking a deep breath)
You throw back the lid, revealing a wretched mess of vile rancor.
Something gleaming catches your eye in one corner.
You feel as if you are going to vommit if you spend too long near
this open dumpster.
>EXAMINE SOMETHING GLEAMING
You reach your hand down and stir about a bit in the
garbage until you find the thing that caught your eye.
It is a very filthy diamond ring. Unfortunately, your
action stirs up the air even more, and the smell
intensifies.
You urgently need to get away from this dumpster
before you bring up last night's pizza.
David J Wildstrom
Jonadab the Unsightly One <jon...@zerospam.com> wrote:
>> "If you don't eat your meat, you can't have any pudding.
>> How can you have any pudding if you don't eat your meat?"
>
>I am curious about the origin of this quotation.
It's from the tag of Pink Floyd's "Another Brick in the Wall, Part II".
It also occurs in the movie _The Wall_, but that's hardly a coincidence.
+--First Church of Briantology--Order of the Holy Quaternion--+
| Brian Wilson's new album is out NOW! What are you waiting |
| for? Support your local genius and buy "Imagination"! |
+-------------------------------------------------------------+
| David Wildstrom |
+-------------------------------------------------------------+
Joe Mason
Jonadab the Unsightly One <jon...@zerospam.com> wrote:
>
>> "If you don't eat your meat, you can't have any pudding.
>> How can you have any pudding if you don't eat your meat?"
>
>I am curious about the origin of this quotation.
It's the voiceover at the end of Pink Floyd's "Another Brick in the Wall,
Part 3".
Do I have to start another Songs in I-F thread?
Joe
Julian Fleetwood
>>>This is a courteous newsgroup. We never make fun of anyone.
>>Not true. We often make fun of that guy who's been writing "Avalon" since
>>about 1962.
>
>
>And Matt Barringer. We make fun of him a lot.
And Brandon Van Every.
And Graham Nelson (just kidding :)
--
Julian Fleetwood (http://surf.to/free4all) | G!>GCS d-- s+:- a16 C+(++) p? L
E-W++ N++
IF: http://www.tip.net.au/~mfleetwo/if/index.htm | o K- w++ O M+ !V PS PE Y+
G e h! PGP-
CBG: http://www.tip.net.au/~mfleetwo/cbg/index.htm | t+ X+++ R(+) tv b+(++)
DI+ D++ r y?
bdu...@my-dejanews.com
yet.
In article <6ra4aj$h1m$1...@nnrp1.dejanews.com>,
okbl...@usa.net wrote:
> In article <35d616ca....@news.supernews.com>,
> bdu...@bigfoot.com (Bryan Dunphy) wrote:
> > 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.
[Making note to self.] Thanks for mentioning that, it's what you'd call "so
obvious I overlooked it".
>
> It could be very good and very interesting all by itself! But I suspect you
> have more in mind?
Yes, but as it's still a work (and plot)-in-progress, I rather not post it to
Usenet.
>
> 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
>
> It's probably the #1 barrier to me playing more IF.
Same here. That's why I'm trying to design my game so that the need for the
player to take notes by hand is minimized.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
bdu...@my-dejanews.com
The Alienist <ddb...@mysurf.com> wrote:
> If the game is going to be complicated, maybe you could implement a kind
> of 'notebook' function, so that when significant (and insignificant)
> events take place, a brief version of it is written to it, containing
> all the important (or seemingly important) info.
>
> Of course, this advise is written from deep within the safe, plush realm
> of Ignorance, as I have no idea as to how difficult such a function
> would actually be to implement. I'm pretty damn new to coding, and as we
> all know, everything's easy until you know something about it...
>
> The Alienist
>
As the game and plot are both still in development, I have no idea how
complicated the game will become. As this is my first real attempt to write
IF it will probably be somewhat simpiler due to my limited ability to
implement my ideas.
However, I do know that a note book is *not* what I am talking about. The
"think about" command I proposed was a solution to the problem of giving the
player important knowledge the character allready knows when the game begins.
It was not intended to handle knowledge gained while playing the game.
bdu...@bigfoot.com
okbl...@usa.net wrote:
> In article <35da09c7...@news.supernews.com>,
> bdu...@bigfoot.com (Bryan Dunphy) wrote:
Just a quick note, I tried to send you an e-mail discussing some of the stuff
I had described as not wanting to mention it on Usenet. Did you ever get
that email? If not, e-mail me at the reply address for this message and I'll
resend it to the address you mail me from.
Kevin Forchione
in Inform that appear to have been created for just this reason. Dumpsters,
police cars, closets, clothes hampers and other objects that might contain
hidden objects ought to allow for the general EXAMINE and the more specific
SEARCH, allowing for the two differing approaches of investigation.
The EXAMINE verb first checks that the object has a description and will
print this if the object does. If the object doesn't have a description then
it is checked for being a container, if it is then it is searched.
The SEARCH verb is concerned with doing an object loop through the tree
listing what is within the container/supporter, and does not reference the
objects description.
Note that if the object is a supporter without a description then with
EXAMINE you will get the "You see nothing special about the [object]" while
a SEARCH results in listing what is on the object, if anything. If the
object is a container without a description then with EXAMINE a SEARCH is
generated.
Kevin
----------------------------------------------------------------------------
--------------------------------------------
Frank Filz wrote in message <35DC49...@mindspring.com>...
>I have to agree with Michael on this one. Another reason to separate
>them, I would expect the following to happen:
>
<snip>
> EXAMINE POLICE CAR
>The police car is a North Carolina State Highway Patrol Car. An officer
>is sitting in the front seat eating a dougnut and reading the paper.
<snip>
R. Alan Monroe
> Now if you really needed to find something in the police car, the dialog
> might go something like:
>
>> EXAMINE POLICE CAR
>
> The police car is a North Carolina State Highway Patrol Car. An officer
> is sitting in the front seat eating a dougnut and reading the paper.
>
>> Z
>
> The officer gets out of the police car and goes into the building.
>
>> SEARCH POLICE CAR
>
> Under the newspaper you find a folded note.
>
>> READ NOTE
> (Taken)
> "Meet me under the bridge at 5:00. Signed Mr. X"
I'd HATE to actually play a game that ran like this.
How could the player possibly have any clue to wait for the officer
to leave the car?
I guess this was just a quicky example, but it
can't hurt to warn future IF authors :^)
Have fun
Alan