NPC Conversation Analysis

5 views
Skip to first unread message

Joao Mendes

unread,
Jul 18, 2002, 11:41:42 PM7/18/02
to
Hi, :)

This may seem a moot point, but...

Does anyone output what the PC actually says to an NPC through the use of
'ask/tell about'? Something like this:

>ask clerk about bananas
"Not until you pay for them," the clerk says.

This may leave the player confused, whereas this:

>ask clerk about bananas
"Can I eat these bananas right now?", you ask.
"Not until you pay for them," the clerk says.

It's at least a bit clearer. Ok, grantedly, this isolated example may not
make a bit of sense, but if you use the flow of conversation to derive the
probable meaning of the conversation, for instance, it might.

Am I making any sense?

Cheers,

J.

L. Ross Raszewski

unread,
Jul 19, 2002, 12:08:07 AM7/19/02
to

Perfect sense. Nonetheless...

In general 'ASK NPC ABOUT THING' implies what the player is saying:
it's usually taken as 'Tell me everything you know about THING'.

It might make more sense to explore alternative conversation methods
if you want the kind of specificity you describe.

Also, note, that many of the proponents of ASK/TELL claim that 'it's
not kosher to stick words in the PC's mouth', and this method
certainly does put words in the PC's mouth (Note, though: I am not a
proponent of ask/tell).

Joao Mendes

unread,
Jul 19, 2002, 12:45:49 AM7/19/02
to
Hi, :)

lrasz...@loyola.edu (L. Ross Raszewski) wrote in
news:HgMZ8.7605$kP6....@nwrddc04.gnilink.net:

> On Fri, 19 Jul 2002 03:41:42 +0000 (UTC), Joao Mendes
> <public...@anywhere.invalid> wrote:

>>Does anyone output what the PC actually says to an NPC through the use
>>of 'ask/tell about'? Something like this:

> Also, note, that many of the proponents of ASK/TELL claim that 'it's


> not kosher to stick words in the PC's mouth', and this method

Can any said proponent jump in and tell me why this is so? I rather like
ASK/TELL for its 'not an immediately obvious clue' characteristic.

> certainly does put words in the PC's mouth (Note, though: I am not a
> proponent of ask/tell).

I'll byte this one as well: what alternatives would you propose?

Cheers,

J.

Jim Fisher

unread,
Jul 19, 2002, 2:18:40 AM7/19/02
to

"Joao Mendes" <public...@anywhere.invalid> wrote "

> Does anyone output what the PC actually says to an NPC through the use of
> 'ask/tell about'?

[snip]

> >ask clerk about bananas
> "Can I eat these bananas right now?", you ask.
> "Not until you pay for them," the clerk says.
>
> It's at least a bit clearer. Ok, grantedly, this isolated example may not
> make a bit of sense, but if you use the flow of conversation to derive the
> probable meaning of the conversation, for instance, it might.

Actually there are a few games that do this, in particular Emily Short's
"Galatea" and "Best of Three".

Also, my conversation example "Medusa" does this too. Emily's games can be
found at the IFArchive and my example (which actually is accompanied by an
article) can be found here:

http://www.onyxring.com/downloads/ORLib%20Examples/medusa.z5

And the article it was written for can be found here:

http://www.onyxring.com/InformGuide.aspx?article=74


Hope this helps,

- Jim

--
Jim (AT) OnyxRing (DOT) com
Visit "An Inform Developer's Guide" or browse the
"ORLibrary" extensions to the standard library at
www.OnyxRing.com
----------------------
Some days you eat the code; some days the code eats you.

L. Ross Raszewski

unread,
Jul 19, 2002, 3:07:19 AM7/19/02
to
On Fri, 19 Jul 2002 04:45:49 +0000 (UTC), Joao Mendes
<public...@anywhere.invalid> wrote:
>
>Can any said proponent jump in and tell me why this is so? I rather like
>ASK/TELL for its 'not an immediately obvious clue' characteristic.
>

I can't speak to the reasons behind not wanting to put words in the
PC's mouth, it not being a view I hold, though I gather that it has to
do with the idea that the player 'is' the PC, and should have
exclusive control over the PC's actions.

I will speak to the second sentence: I can understand why you'd like
ASK/TELL's 'not an obvious clue' characteristic, but, on the other
hand, I find that his sort of thinking can be troublesome; it leads to
'Guess the word' puzzles, and to treating an NPC as a sort of verbal
dartboard; you just pitch every word you can think of at them and see
what sticks.

>> certainly does put words in the PC's mouth (Note, though: I am not a
>> proponent of ask/tell).
>
>I'll byte this one as well: what alternatives would you propose?
>

I'm a big fan of menu-driven conversations, on several grounds:
1. Topic-based menu conversations (That is, a menu of topics to talk
about) obviates the 'guess-the-word' characteristic of ask/tell, and
gets rid of the mimesis-shattering effect of having an NPC give a
bogus answer to an unregongnized term.
2. Phrase-based menu conversations (That is, a menu of specific
phrases to speak) reflect a richer speech model than the common view
of ASK/TELL which I mentioned in my previous post (that is, in an
ASK/TELL game, conventionally, all you can do is request that an NPC
tell you everythign he knows about X), and are even better suited to
what will become my third point.
3. Menu based conversations better reflect reality. Hear me out,
because I know this is an extraordinary claim. You suppose that you
can at any time ask anyone you meet about anything at all. This is
true in a vague physical sense; yes, you are capable of saying any
particular phrase in such a way as to address it to any given person
in the form of a question. However, you are bound by the fact that you
are a human being with a certain knowledge base and certain
understandign of social protocols. In practice, I can no more ask my
middle-aged next-door neighbor about his sex life than I can take a
stroll across the Chesapeake Bay, and I can no more ask an attractive
woman I meet on the street to show me her breasts than I could pull
out a gun and fire into a playground -- certainly, I'm physically
capable of the physical action, supposing I had a gun and was near a
playground, but that doesn't change the fact that I'm incapable of
doing it. If we really could say anything we liked to anyone we
liked, we'd find far fewer awkward silences on first dates.
4. Menu based conversations tend to reflect a better characterization
of the player character -- and I have a better time with a
characterized player character. A menu is almost like a dialogue
between the player and the player character: the PC tells you 'okay,
here's the things that I can reasonably say to this person in this
situation'. -- this relates nicelty to the previosu point.


I'm not really sure about other conversation systems; as far as I know
of, beyond ASK/TELL and menus, there are really only two other kinds
of conversations I can even think of (though I'd be interested if
there were other paradigms): natural language (which is intractable,
and loses points to menus in terms of PC characterization; I shouldn't
be able to make an eighteenth century courtier say "What up,
biotch?"), and keyword-based (Which most things emulating natural
language really use. Frankly, keyword-based systems are really just
ASK/TELL with a slight syntactic difference.

COme to think of it, though, there's a couple of other models which I,
perhaps wrongly, lump under the umbrella of menus. One of the more
interesting ones is the 'mood based' system used by um... a company
whose name I can't remember in the X files game, Quantum Gate, and The
Vortex. Here, you had no direct control over the conversation; what
you directly controlled was rather tha character of the PC's speech.
That is, you would have a choice to become beligerant, distraught, or
'balanced', but what the PC actually said was out of your control.

Emily Short

unread,
Jul 19, 2002, 3:28:50 AM7/19/02
to
In article <Xns92502F2AEA77Dj...@194.65.14.158>, Joao
Mendes <public...@anywhere.invalid> wrote:

I talk about this (and some related issues) a bit here:

http://www.mindspring.com/~emshort/NPC3.htm#interface

--
Emily Short
http://emshort.home.mindspring.com/index.htm

Joao Mendes

unread,
Jul 19, 2002, 5:05:16 AM7/19/02
to
Hi, :)

ems...@mindspring.com (Emily Short) wrote in
news:emshort-1907...@1cust23.tnt3.redmond.wa.da.uu.net:


> I talk about this (and some related issues) a bit here:
>
> http://www.mindspring.com/~emshort/NPC3.htm#interface

Duh. I had read this before, too. Thanks for the reminder. :)

BTW, it's good stuff.

Cheers,

J.

Joao Mendes

unread,
Jul 19, 2002, 5:26:48 AM7/19/02
to
Hi, :)

lrasz...@loyola.edu (L. Ross Raszewski) wrote in

news:HUOZ8.47232$IW4....@nwrddc02.gnilink.net:

> I will speak to the second sentence: I can understand why you'd like
> ASK/TELL's 'not an obvious clue' characteristic, but, on the other
> hand, I find that his sort of thinking can be troublesome; it leads to
> 'Guess the word' puzzles, and to treating an NPC as a sort of verbal
> dartboard; you just pitch every word you can think of at them and see
> what sticks.

Hmm... I always thought that the difference between a good puzzle and
'guess-the-verb' was judicious use of clues.

> 1. Topic-based menu conversations (That is, a menu of topics to talk
> about) obviates the 'guess-the-word' characteristic of ask/tell, and
> gets rid of the mimesis-shattering effect of having an NPC give a
> bogus answer to an unregongnized term.

Uncontested. The drawback is that it is limiting in choices.

> 2. Phrase-based menu conversations (That is, a menu of specific
> phrases to speak) reflect a richer speech model than the common view
> of ASK/TELL which I mentioned in my previous post (that is, in an
> ASK/TELL game, conventionally, all you can do is request that an NPC
> tell you everythign he knows about X), and are even better suited to
> what will become my third point.

Very true. In fact, the speech model thing is what drove me to want to spit
out the PC's words. The drawback... well, yo ualready mentioned it... ;)

> 3. Menu based conversations better reflect reality. Hear me out,
> because I know this is an extraordinary claim. You suppose that you

No need, because I know exactly what you mean. And I do see the points in
your analysis (which I snipped for brevity). However, in this particular
case, reflecting reality, IMHO, is more a function of how heavily you want
to define the PC. For strict characterization, this is true, but for
player-driven characterization, it is not.

> 4. Menu based conversations tend to reflect a better characterization
> of the player character -- and I have a better time with a
> characterized player character. A menu is almost like a dialogue
> between the player and the player character: the PC tells you 'okay,
> here's the things that I can reasonably say to this person in this

Indeed. The drawback is that the player/PC distance might increase...

> situation'. -- this relates nicelty to the previosu point.

Precisely, yes. Hmm... I think we basically share an understanding of
what's involved, although our preferences tend to diverge.

> COme to think of it, though, there's a couple of other models which I,

Emily's page has a bunch of cool stuff. I especially liked the ask/menu
hybrid. However, writing TADS3 code for this looks like more work than I
can handle at this point.

In conclusion, since I am working on my very first piece of IF, and since
no angry clammoring voices arose against my putting words in the PC's
mouth, I'll stick with my original idea. For later works, I think I will
probably go the ask/hybrid way.

Thanks for pointers. Cheers,

J.

Sean T Barrett

unread,
Jul 19, 2002, 7:39:40 AM7/19/02
to
LRR wrote:
>3. Menu based conversations better reflect reality. [] You suppose that you

>can at any time ask anyone you meet about anything at all. This is true
>in a vague physical sense; [] However, you are bound by the fact that you

>are a human being with a certain knowledge base and certain
>understandign of social protocols. In practice, I can no more ask my
>middle-aged next-door neighbor about his sex life than I can take a
>stroll across the Chesapeake Bay, and I can no more ask an attractive
>woman I meet on the street to show me her breasts than I could pull
>out a gun and fire into a playground []

I'm sorry to hear that all your future games are going to
be pure CYOAs with no command prompt, since you obviously
wouldn't want the player to type things like
>WALK ACROSS BAY
or
>SHOOT AT PLAYGROUND

any more than you would want her typing
>ASK NEIGHBOR ABOUT SEX LIFE
or
>WOMAN, DOFF TOP

Or, to be non-snarky, I'd argue that except for the
topic-based menu stuff, menu systems simply don't
provide enough choices for the player to feel in control;
it's very obvious that the author is steering the game
to one or three or four specific places. If it's "more
realistic", it's more realistic in the way that a book
is more realistic than a transcript of an IF playthrough,
and it's less immersive in my book since it's less
(meaningfully) interactive. And realism isn't the goal.

SeanB

Timothy Groves

unread,
Jul 19, 2002, 10:31:51 AM7/19/02
to
"L. Ross Raszewski" wrote:

> In general 'ASK NPC ABOUT THING' implies what the player is saying:
> it's usually taken as 'Tell me everything you know about THING'.

So an appropriate Avatar response might be "What do you know about ",
(the) noun, "?"

--
ICQ#66022322

"It's a terrifying thing, isn't it? To live in fear.
That's what it's like to be a slave."
--Rutger Hauer, Bladerunner

A.P. Hill

unread,
Jul 19, 2002, 11:29:28 AM7/19/02
to
I disagree. The pc is the player, you are just hanging on for the
ride. If I don't code east, you can't go east. If I code east, it's
because, I'm directing you east. If I code north, south, east, west,
it's becuase I'm directing you those ways, I don't care which one you
use first.

ask teller about bananas

The teller takes a long drag from here Marlboro, then gives you a
sarcastic look, "Look bud, I ain't got time for chitter chatter. See
that man over there?"

"Yes. ", you say, glancing over your shoulder.

"That's Ted Nugent, and if he sees me not workin', then I'm outtof a
job. You understand?", asks the cashier.

"I believe I understand now", you say as you push your oxygen tank
over a bit so an old lady can get by.


A.P. Hill
25 x 40 Focus Lens

L. Ross Raszewski

unread,
Jul 19, 2002, 12:18:00 PM7/19/02
to
On Fri, 19 Jul 2002 10:31:51 -0400, Timothy Groves
<grov...@yahoo.co.uk> wrote:
>"L. Ross Raszewski" wrote:
>
>> In general 'ASK NPC ABOUT THING' implies what the player is saying:
>> it's usually taken as 'Tell me everything you know about THING'.
>
>So an appropriate Avatar response might be "What do you know about ",
>(the) noun, "?"
>

Certainly. Though it does seem needless to insert this piece of
dialogue, if it is indeed 'obvious'

Mike Roberts

unread,
Jul 19, 2002, 2:21:43 PM7/19/02
to
"L. Ross Raszewski" <lrasz...@loyola.edu> wrote:
> I'm a big fan of menu-driven conversations, on several
> grounds:
> 3. Menu based conversations better reflect reality. [...]

> However, you are bound by the fact that you are a human
> being with a certain knowledge base and certain
> understandign of social protocols.

This is a big part of the appeal of menu-based systems for me, but I've also
had this idea on the back burner for a while of trying to build a stateful
ASK/TELL system that would take care of the basic protocol stuff
automatically. For example, one of the things that really bugs me about
ASK/TELL "conversations" is that they consist entirely of the PC walking up
to an NPC and peppering her with random questions and trying to give her
things. There's no simulation of attacting the NPC's attention, of
maintaining that attention once you have it (by staying engaged in the
conversation, rather than doing other random stuff, walking out of the room,
etc), or of disengaging once you no longer desire it. Some of the goals
I've had in mind:

- when you first start a conversation, go through some kind of greeting
protocol, however minimal
- while in a conversation, an NPC suspends any "background" activity
- once you're in a conversation, if the PC starts going about other
business, the NPC should actually notice, either giving up and returning to
its background activity or actively objecting ("hey! where are you going?")
- once in a conversation, either the NPC or PC can explicitly exit the
conversation

It would also be nice to have a sense of a thread or topic: a way to say
"tell me more," ask side questions, answer questions from the NPC; but these
are probably much more ambitious goals.

--Mike
mjr underscore at hotmail dot com

Kevin Forchione

unread,
Jul 19, 2002, 8:49:16 PM7/19/02
to
"Mike Roberts" <mjr-S...@hotmail.com> wrote in message
news:hLYZ8.14$z61...@news.oracle.com...
<snip>

This sounds like an interesting scheme to me. Also, using the event system
of TADS 3 you could have other NPCs in the area respond to the SoundEvent of
the conversation. In fact, the SoundEvent could be used to attract the NPC's
attention to engage in the conversation to begin with.

I've been interesting in maximizing the use of passive and active event
generation since you added that feature to TADS 3. It creates a layer of
abstraction between actors and actions such that they react to the event,
rather than having their methods accessed directly. But my goals lean toward
a more automaton-style NPC, which would be more complex to code for than a
story may warrant, but very interesting nonetheless.

--Kevin


Joao Mendes

unread,
Jul 20, 2002, 6:16:25 AM7/20/02
to
Yoh, :)

"Jim Fisher" <jimATonyx...@nospam.com> wrote in
news:4bOZ8.7429$qB5....@news1.central.cox.net:

> "Joao Mendes" <public...@anywhere.invalid> wrote "

>> Does anyone output what the PC actually says to an NPC through the
>> use of 'ask/tell about'?

> [snip]

[resnip]

> And the article it was written for can be found here:
>
> http://www.onyxring.com/InformGuide.aspx?article=74
>
> Hope this helps,

It does. This complements Emily's article rather nicely, and has the added
advantage of fitting my perceptions of NPCs. One advice I might have given
at the time of writing is that, even though the article was not about
implementation, you might have added relative comparisons of ease, as that
tends to be a heavy factor in NPC design, IMHO.

Cheers,

J.

Joao Mendes

unread,
Jul 20, 2002, 6:17:52 AM7/20/02
to
Hi, :)

"Kevin Forchione" <ke...@lysseus.com> wrote in
news:gs2_8.3156$UW6.12...@newssvr21.news.prodigy.com:

> This sounds like an interesting scheme to me. Also, using the event
> system of TADS 3 you could have other NPCs in the area respond to the
> SoundEvent of the conversation. In fact, the SoundEvent could be used
> to attract the NPC's attention to engage in the conversation to begin
> with.

Ok, I have to ask. _Does_ ASK/TELL generate a soundEvent when used? Or does
the author you have to code that into the verb?

Cheers,

J.

Marnie Parker

unread,
Jul 20, 2002, 11:46:54 AM7/20/02
to
>Subject: Re: NPC Conversation Analysis
>From: "Mike Roberts" mjr-S...@hotmail.com
>Date: 7/19/2002 11:21 AM Pacific Daylight Time

>This is a big part of the appeal of menu-based systems for me, but I've also
>had this idea on the back burner for a while of trying to build a stateful
>ASK/TELL system that would take care of the basic protocol stuff
>automatically. For example, one of the things that really bugs me about
>ASK/TELL "conversations" is that they consist entirely of the PC walking up
>to an NPC and peppering her with random questions and trying to give her
>things. There's no simulation of attacting the NPC's attention, of
>maintaining that attention once you have it (by staying engaged in the
>conversation, rather than doing other random stuff, walking out of the room,
>etc), or of disengaging once you no longer desire it. Some of the goals
>I've had in mind:
>
>- when you first start a conversation, go through some kind of greeting
>protocol, however minimal
>- while in a conversation, an NPC suspends any "background" activity
>- once you're in a conversation, if the PC starts going about other
>business, the NPC should actually notice, either giving up and returning to
>its background activity or actively objecting ("hey! where are you going?")
>- once in a conversation, either the NPC or PC can explicitly exit the
>conversation

I "hardcoded" some of this (not the PC exiting conversation, though) into a
game I was working on (working on years ago) in Inform. Lots of trouble -- some
sort of event/state system would be best, maybe a state system for the NPC or
an overall game event system. Wish you luck.

>
>It would also be nice to have a sense of a thread or topic: a way to say
>"tell me more," ask side questions, answer questions from the NPC; but these
>are probably much more ambitious goals.

I feel that somehow one needs a thread system -- like the one used in
newsgroups. Where there could be topic "threads" (not just simple topics), and
flags for the state of each of those threads: this has been discussed, this has
not been broached yet, this is the response the NPC has already made to this
thread, this thread could be discussed more. Because Inform does not support
multi-dimensional arrays it is almost impossible to do it well in Inform (it
can be done, but very cumbersomely). Wish you luck with that too.

>--Mike

Doe :-) I'll be interested to see what might emerge someday in TADS.


doea...@aol.com
IF http://members.aol.com/doepage/intfict.htm
(An Iffy Theory | Glulx/Glk for Duncies | unglklib | Inform Primer)
IF Art Gallery http://members.aol.com/iffyart/
IF Review Conspiracy http://zork.plover.net/~textfire/conspiracy/

OKB (not okblacke)

unread,
Jul 20, 2002, 1:03:15 PM7/20/02
to
Jonathan Sauer wrote:

> You would define a class "Topic" with properties like "npc_answer"
> (the answert the NPC gives when asked about the topic) as well as
> several "pointers" to other Topic-objects. Additionally, every
> topic would have a question leading to that topic, so if you have
> topic A with subtopics B, C and D, depending on the question the
> player asks after the NPC has answered to A, you would branch to B,
> C or D.
>
> In the class "Topic" you could provide attributes for memorizing if
> the topic has already been discussed (or how many times, if an NPC
> is willing to repeat an answer twice, but not more times) etc.
>
> Because of the linking of topic-objects, you wouldn't be restricted
> to a tree, tough. I.e:
>
> topic A has subtopics B, C and D
> topic E has subtopics F, G and H
>
> it would be possible to make F a subtopic of C, or C a subtopic of
> G, thus creating a conversation network and avoiding the inclusion
> of the same discussion in several places in the tree.

In fact, this is almost exactly the approach I took in my GxScript
library, although that was a menu conversation library, not ASK/TELL.

One problem with adapting this mechanism to ASK/TELL is lurking in
what you say here: "depending on the question the player asks after the
NPC has answered to A, you would branch to B, C or D." The problem is
that, with an ASK/TELL system, there is no way to reduce the
possibilities to just B, C, and D -- the player could conceivably ask
about anything. Now, it may be that in your conversation model you want
most questions to be ineffective at this juncture, but you still have to
code SOMETHING for each case, and you can't recycle your responses too
much, or the conversation will lose its flavor.

I do think, though, that it's natural and effective to use this
structure for a menu-based conversation (and I happen to prefer menu
conversation anyway).

--
--OKB (not okblacke)
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

Nikos Chantziaras

unread,
Jul 20, 2002, 4:22:49 PM7/20/02
to
"Joao Mendes" <public...@anywhere.invalid> wrote in message
news:Xns92502F2AEA77Dj...@194.65.14.158...

> >ask clerk about bananas
> "Can I eat these bananas right now?", you ask.
> "Not until you pay for them," the clerk says.
>
> It's at least a bit clearer. Ok, grantedly, this isolated example
> may not make a bit of sense, but if you use the flow of
> conversation to derive the probable meaning of the
> conversation, for instance, it might.
>
> Am I making any sense?

Sounds interesting. This way, the player can actually "see" how the PC
performs the requested action, not just get the result of it without knowing
the exact question of the PC.

On the other hand, this:

>clerk, tell me about the bananas

should be treated as something different, since the syntax itself makes the
question obvious.

The only real problem I see, are the questions that result in a "I don't
know much about this". What should the question be in this case?

Oh, your example should actually be:

>ask clerk for bananas

"for" not "about".

-- Niko

Kevin Forchione

unread,
Jul 20, 2002, 4:39:19 PM7/20/02
to
"Nikos Chantziaras" <rea...@hotmail.com> wrote in message
news:ahcgrh$rf8m3$1...@ID-151409.news.dfncis.de...

> The only real problem I see, are the questions that result in a "I don't
> know much about this". What should the question be in this case?

That's something the author must code for in any case. Anytime a default
response is undesirable, it should be overriden.

> Oh, your example should actually be:
>
> >ask clerk for bananas
>
> "for" not "about".

Depends on who's doing the asking, and what their intentions are. Might be
the boss asking for information, rather than requesting some.

--Kevin


Nikos Chantziaras

unread,
Jul 20, 2002, 5:05:59 PM7/20/02
to
"Kevin Forchione" <ke...@lysseus.com> wrote

> "Nikos Chantziaras" <rea...@hotmail.com> wrote in message
> news:ahcgrh$rf8m3$1...@ID-151409.news.dfncis.de...
> > Oh, your example should actually be:
> >
> > >ask clerk for bananas
> >
> > "for" not "about".
>
> Depends on who's doing the asking, and what their intentions are.
> Might be the boss asking for information, rather than requesting
> some.
When what I want is information, I use "about". When I'm requesting an
object, I use "for". IMHO, this should be one of the "unwritten laws" of
IF, since in most games you don't know for sure what a command does until
you try it (on the other hand, this could be a desired behavior).

-- Niko

L. Ross Raszewski

unread,
Jul 20, 2002, 5:42:40 PM7/20/02
to
On Sun, 21 Jul 2002 00:05:59 +0300, Nikos Chantziaras
<rea...@hotmail.com> wrote:

>When what I want is information, I use "about". When I'm requesting an
>object, I use "for". IMHO, this should be one of the "unwritten laws" of
>IF, since in most games you don't know for sure what a command does until
>you try it (on the other hand, this could be a desired behavior).
>
>-- Niko
>

On the other hand, though, in the example given, the player *isn't*
asking *for* the bananas; he's asking *about* them. I'd have assumed
from the setup that the bananas were actually something the player was
holding.

Jayzee

unread,
Jul 21, 2002, 6:28:48 PM7/21/02
to
On Fri, 19 Jul 2002 07:07:19 GMT, lrasz...@loyola.edu (L. Ross
Raszewski) wrote:

>On Fri, 19 Jul 2002 04:45:49 +0000 (UTC), Joao Mendes
><public...@anywhere.invalid> wrote:
>>
>>Can any said proponent jump in and tell me why this is so? I rather like
>>ASK/TELL for its 'not an immediately obvious clue' characteristic.
>>
>
>I can't speak to the reasons behind not wanting to put words in the
>PC's mouth, it not being a view I hold, though I gather that it has to
>do with the idea that the player 'is' the PC, and should have
>exclusive control over the PC's actions.
>

I wondered if this is perhaps a transference from IFMudding?
A f'rinstance:

Joe and Fred are characters, each being run by a human player, the
human players taking turns to describe what happens in the story.
Imagine they're in a bar-fight. As the player running Joe, it's
perfectly okay to say "Joe takes a swing at Fred."
It's *not* okay to say "Joe punches Fred on the nose" because in doing
so you're illegally taking control of the Fred character - it's up to
the player running Fred to decide if he gets punched on the nose or
dodges, or what.
The in-group shorthand for illegally taking control of someone else's
character is called "Godding" (I think, been a while since I read
about IFMuds), anyway it's a major breach of etiquette.

I wondered if that's perhaps what some people felt when they object to
an author who puts words in the player character's mouth - that the
author is Godding.

(My take is that the player character is nevertheless a character, so
it's perfectly legit for the author to exercise some control over that
character too.)

Jayzee
(wondering if he shouldn't just Stop Rambling and Save Bandwidth.)


L. Ross Raszewski

unread,
Jul 21, 2002, 10:31:30 PM7/21/02
to
On Sun, 21 Jul 2002 22:28:48 +0000 (UTC), Jayzee <hal...@hotmail.com> wrote:
>On Fri, 19 Jul 2002 07:07:19 GMT, lrasz...@loyola.edu (L. Ross
>Raszewski) wrote:
>
>>On Fri, 19 Jul 2002 04:45:49 +0000 (UTC), Joao Mendes
>><public...@anywhere.invalid> wrote:
>>>
>>>Can any said proponent jump in and tell me why this is so? I rather like
>>>ASK/TELL for its 'not an immediately obvious clue' characteristic.
>>>
>>
>>I can't speak to the reasons behind not wanting to put words in the
>>PC's mouth, it not being a view I hold, though I gather that it has to
>>do with the idea that the player 'is' the PC, and should have
>>exclusive control over the PC's actions.
>>
>
>I wondered if this is perhaps a transference from IFMudding?
>A f'rinstance:
>
>Joe and Fred are characters, each being run by a human player, the
>human players taking turns to describe what happens in the story.
>Imagine they're in a bar-fight. As the player running Joe, it's
>perfectly okay to say "Joe takes a swing at Fred."
>It's *not* okay to say "Joe punches Fred on the nose" because in doing
>so you're illegally taking control of the Fred character - it's up to
>the player running Fred to decide if he gets punched on the nose or
>dodges, or what.

Well, I imagine this is a possibility, but I think it's more likely
that it comes from IF itself; all the oldest games had a totally blank
player character, the intention being that you would project your own
identity onto them.

Infocom's manuals go as far as to say 'Interactive Fiction is a story
in which you *are* the main character'

(In fact, even the infocom manuals to games with a well-defined PC say this.)

Emily Short

unread,
Jul 24, 2002, 1:29:59 AM7/24/02
to
In article <Xns9251733BA182Aj...@194.65.14.158>, Joao
Mendes <public...@anywhere.invalid> wrote:

>
> > And the article it was written for can be found here:
> >
> > http://www.onyxring.com/InformGuide.aspx?article=74
> >
> > Hope this helps,
>
> It does. This complements Emily's article rather nicely, and has the added
> advantage of fitting my perceptions of NPCs. One advice I might have given
> at the time of writing is that, even though the article was not about
> implementation, you might have added relative comparisons of ease, as that
> tends to be a heavy factor in NPC design, IMHO.

I hadn't run into this article before this thread, but I found it quite
intriguing -- not least because Jim seems to have independently come to
some conclusions that took me several years to work around to, in the
sense that I had to keep adding functionality to my conversation system to
take care of different narrative/gameplay possibilities. Doing a
Lecturing Professor who will just dump timed info on the player is not
that hard; but making an NPC who can shift between Lecturing Professor and
Conversationalist is a bit harder, especially if you want the player to be
able to interrupt with questions yet still ultimately get all the relevant
facts that the NPC wants to convey.

A lot of the bugs in early versions of Pytho's Mask (and, probably, one in
the latest version, sigh) have to do with imperfect implementations of
this functionality: if the player asks a question or does something that
throws off the chain of the lecture too much, the NPC loses the thread and
never manages to get back to it, sometimes throwing the game into a
permanently unwinnable state -- because the NPC knows that the relevant
goal (having told the PC facts x, y, and z) is not yet accomplished, yet
the process of achieving the goal has been stalled out.

Reply all
Reply to author
Forward
0 new messages