Being more specific than ask/tell

Jerome West wrote:
> > normally, the player doesn't mind if his command is reinterpreted,
>  > especially if the reinterpretation means good writing and interesting
>  > narrative -- which requires strong narrative control.
>
> I strongly disagree. As a player, when I enter a command I know exactly
> what I mean by it. If the system interprets it as something entirely
> different, I feel cheated. The game is simply making excuses for not
> understanding my intentions.

There's definitely times when that reinterpretation is a problem. If,
for example, the narrative has raised a question which the NPC actors
can't seem to address intelligently, then there's a problem in the
design. If the game is successful -- entertaining rather than
frustrating -- then the player is going to be forgiving when the
command is reinterpreted in a way which is perhaps off-intention but
drives the narrative forward.

> The possibilities seem to be:
>
> * Ask/tell
> * Menus
> * A hybrid of these two
> * More complex parsing

Also, *less* complex parsing (a handful of modern games I've poked
into seem to fuse "Ask Joe about [topic]" and "Tell Joe about [topic"
into a single "Talk to Joe about [topic]" and a number of other games
drop topics entirely and deliver scripted stuff in response to "Talk
to joe," and given the right game these can be plenty.

And again, verb-based (Console Jane, Joke With Jane, Flirt With Jane,
Seduce Jane, Insult Jane, Dismiss Jane)* can be very nifty in the
right genre, I think.

> Yes, that is a possible implementation of a hybrid system; but note that
> it _is_ a hybrid between ask/tell and menus. (It is of little importance
> whether the menus are numbered, as in my games, or not, as in this
> example. In both cases you choose one of several explicitly given
> options. Using a numbered menu just saves the player some typing.

I don't really agree. Structurally, yes, you're right, except there
may be some nice cross-referencing possibilities depending on how the
keyword->options process works, throwing up different options
depending on what the player typed. But the fact that it's all within
the command-line interface makes it *feel* much smoother to play, IMO.
An IF player learns quickly to blank-out the typing/parser and feel
like they have the possibility of doing anything - that's what so nice
about IF. As soon as you enumerate a list it defines a boundary on
that space. Yes, the list of topic suggestions does that too, but it
doesn't quite feel that way.

Bizarrely, I think if that list were hyperlinks you could click to
choose the option, that would be okay. I guess it's really just the
"prose into bullet-point list" transition I don't like.

jon

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Tarbert wrote:
> Victor Gijsbers wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> David Fisher wrote:
>>>
>>> So have there been any real situations where you wanted to say
>>> something to an NPC but couldn't?
>>
>> Always. This is exactly why I have used menu-based conversation systems
>> exclusively, and cannot see myself moving to a pure ask/tell system in
>> the future. (Though I might adopt a hybrid system.)
>>
>
> I'm don't see how menu-based systems help in this area -- unless the
> player happens to be the author of the game as well.

Take the OP's example:

"ask Fred about boat" could mean "Whose boat is that?", "When did the
boat arrive?" or "Is that boat for hire?".

You cannot disambiguate that with an ask/tell system, but you can surely
do it with a menu-based system. Manu-based systems allow for a far wider
range of expressions than do ask/tell systems, which _only_ allow you to
choose a topic, and nothing else.

Regards,
Victor

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklGmPwACgkQoiOrMwvIZLyU1ACghgAJKqEYy02ff5VDLMqH8PUs
RdwAoJPYRcl/8whQI9c0kGCfJTEeCwO8
=1/Po
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

mikegentry wrote:
> On Dec 15, 12:50 pm, Victor Gijsbers <vic....RemoveThis@lilith.gotdns.org> wrote:
>> Take the OP's example:
>>
>> "ask Fred about boat" could mean "Whose boat is that?", "When did the
>> boat arrive?" or "Is that boat for hire?".
>>
>> You cannot disambiguate that with an ask/tell system, but you can surely
>> do it with a menu-based system. Manu-based systems allow for a far wider
>> range of expressions than do ask/tell systems, which _only_ allow you to
>> choose a topic, and nothing else.
>
> You can disambiguate it if you've rigged your ask-tell system to treat
> conversation topics as objects that can be parsed instead of text
> snippets. With some thoughtful application of name-printing and
> disambiguation rules, you can have gameplay like this:
>
>> ASK FRED ABOUT BOAT
> What are you asking about specifically: whose boat it is, when the
> boat arrived, or whether the boat is for hire?
>
>> WHOSE BOAT
> "That boat there?" says Fred. "Why, that's Jim's boat."
>
>> ASK FRED ABOUT WHEN BOAT ARRIVED
> "Oh, it put in about 11:30 last night," says Fred.

Yes, that is a possible implementation of a hybrid system; but note that
it _is_ a hybrid between ask/tell and menus. (It is of little importance
whether the menus are numbered, as in my games, or not, as in this
example. In both cases you choose one of several explicitly given
options. Using a numbered menu just saves the player some typing.)

Regards,
Victor
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklG0WIACgkQoiOrMwvIZLxeMgCeMyQy/gepPYYzkJqmn43yWY/t
sY4AnRSv3Ajed2P8uwrgbU3uckXMtmie
=XTEp
-----END PGP SIGNATURE-----

Victor Gijsbers wrote:
> You cannot disambiguate that with an ask/tell system, but you can surely
> do it with a menu-based system. Manu-based systems allow for a far wider
> range of expressions than do ask/tell systems, which _only_ allow you to
> choose a topic, and nothing else.

On the other hand, menu-based systems present the user with an
in-their-face list of choices, and preclude any other conversational
option. Ask/tell might be very limited, but at least it allows the
player some agency in deciding what to talk about, and when to do it.

In a murder-mystery game, the possibility is there for the player to
think "aha, I believe Steve is the murderer, I shall Ask Steve About
Dagger". A menu-driven conversation system would have to present the
player with an explicit option, thus giving away the plot if it hasn't
occurred to the player prior to that point.

This is why I view ask/tell as the lesser of the two evils.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jerome West wrote:
> Victor Gijsbers wrote:
>> You cannot disambiguate that with an ask/tell system, but you can surely
>> do it with a menu-based system. Manu-based systems allow for a far wider
>> range of expressions than do ask/tell systems, which _only_ allow you to
>> choose a topic, and nothing else.
>
> On the other hand, menu-based systems present the user with an
> in-their-face list of choices, and preclude any other conversational
> option. Ask/tell might be very limited, but at least it allows the
> player some agency in deciding what to talk about, and when to do it.
>
> In a murder-mystery game, the possibility is there for the player to
> think "aha, I believe Steve is the murderer, I shall Ask Steve About
> Dagger". A menu-driven conversation system would have to present the
> player with an explicit option, thus giving away the plot if it hasn't
> occurred to the player prior to that point.
>
> This is why I view ask/tell as the lesser of the two evils.

I don't think you can adequately judge amounts of evil if you don't have
a specific game (or type of game) in mind. Ask/tell certainly has an
edge over menus in a typical murder-mystery game, as you say; on the
other hand, it would have been a terrible choice for "The Baron".

Again, I do think you can get the best of both worlds by adopting a
hybrid system; but it will take a lot more work to implement.

Kind regards,
Victor
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklG0kIACgkQoiOrMwvIZLzRhgCgg+vL7+++IHimXZi20Cf3w/hK
8oUAnjMfqNxTaNPbQvEUSNxqhekzyepz
=R8X6
-----END PGP SIGNATURE-----

On Dec 15, 4:51 pm, Victor Gijsbers <vic....TakeThisOut@lilith.gotdns.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
>
>
> mikegentry wrote:
> > On Dec 15, 12:50 pm, Victor Gijsbers <vic....TakeThisOut@lilith.gotdns.org> wrote:
> >> Take the OP's example:
>
> >> "ask Fred about boat" could mean "Whose boat is that?", "When did the
> >> boat arrive?" or "Is that boat for hire?".
>
> >> You cannot disambiguate that with an ask/tell system, but you can surely
> >> do it with a menu-based system. Manu-based systems allow for a far wider
> >> range of expressions than do ask/tell systems, which _only_ allow you to
> >> choose a topic, and nothing else.
>
> > You can disambiguate it if you've rigged your ask-tell system to treat
> > conversation topics as objects that can be parsed instead of text
> > snippets. With some thoughtful application of name-printing and
> > disambiguation rules, you can have gameplay like this:
>
> >> ASK FRED ABOUT BOAT
> > What are you asking about specifically: whose boat it is, when the
> > boat arrived, or whether the boat is for hire?
>
> >> WHOSE BOAT
> > "That boat there?" says Fred. "Why, that's Jim's boat."
>
> >> ASK FRED ABOUT WHEN BOAT ARRIVED
> > "Oh, it put in about 11:30 last night," says Fred.
>
> Yes, that is a possible implementation of a hybrid system; but note that
> it _is_ a hybrid between ask/tell and menus. (It is of little importance
> whether the menus are numbered, as in my games, or not, as in this
> example. In both cases you choose one of several explicitly given
> options. Using a numbered menu just saves the player some typing.)
>

There's a bit more difference than that, I think. The "which do you
mean" question is not a menu, per se -- it's a real disambiguation
message thrown out by the parser, because there are three conversation
"objects" in scope for this NPC that have "boat" as a synonym (cf.
"Which do you mean, the red apple, the green apple, or the apple
pie?").

The player must still come up with the idea of asking about the boat
on her own, and after being presented with the choices, she could
choose to ignore them and ask Fred about the lake, or the weather, or
anything else that hasn't been specifically cued yet. It may be a
lawn, but it's a lawn that you don't know the borders of, which means
you can explore it instead of just mowing it.

There are people here who have thought this long and hard, much more
so than I have, so I'll just throw in a couple of cents and then
withdraw -

The ask/tell system, even if limited by keywords, has a possibility
that has rarely been explored - a conversation is comprised of
"asking" and "telling", and "asking" someone about something is
different from "telling" someone about something. In effect, if you
keep alternately asking and telling someone something, you have a
conversation.

It is still limited, of course, in the sense that it's still keyword
based - but it's an avenue rarely explored conversationally. From what
I have seen, "tell" as a conversation action is rarely used. And of
course, this would require a more extensive implementation - the
characters would have to recognize a wide variety of both *ask* and
*tell* keywords, otherwise there would be no point in diferentianting
at all.

Anyway, I'm currently experimenting with this sort of thing. I suppose
in time I'll find out whether actually giving *ask* and *tell*
meaningful distinctions works at all.

Jerome West wrote:
> Nikos Chantziaras wrote:
>> Consider these:
>>
>> > ask david why he's angry
>> > try to reason with him
>> > tell him it's ok
>> > agree with him
>
> A system flexible enough to accept inputs like these would be amazing!
>
>> David goes on a long rant about conversation systems in IF.
>> He seems quite upset.
>>
>> (You could ask him why he's so angry, try to reason with him,
>> tell him it's all fine or agree with him.)
>
> Oh, hold on... so this system is just as limiting as having a numbered
> menu, except I have to type the whole sentence instead of just entering
> a number?

No, you can just enter "reason" instead of the whole sentence or any
other synonymous words or sentences the author thought of. The point is
that you don't have to enter a number and don't get a menu presented.
The big deal here is that you can enter the response whenever you want
instead only when there's a menu presented to you and that the "flow" of
the game isn't disturbed by a menu. Not leaving the regular parser is
pretty nice IMO.

I wonder if we're getting hung up on different concepts of what is
meant by a "menu."

If there's a green apple and a red apple, and you type TAKE APPLE, and
the parser asks you which apple you mean, do you consider that a
"menu"? Because if you do, then any sort of disambiguation is a menu,
and in most IF games you're choosing from menus all the time. I don't
usually think of it that way, but okay, whatever.

I did not actually set out to claim that one conversation approach is
better than another. I was responding to your assertion that an ask/
tell approach cannot disambiguate between finer shades of meaning of a
topic. I think it's clear that it can -- if you treat conversation
topics as objects in the world model, instead of simply scanning the
player's input for snippets of text.

Do you disagree with this?

"Victor Gijsbers" <victor DeleteThis @lilith.gotdns.org> wrote in message
news:4946d163$0$182$e4fe514c@news.xs4all.nl...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> mikegentry wrote:
>> You can disambiguate it if you've rigged your ask-tell system to
>> treat
>> conversation topics as objects that can be parsed instead of text
>> snippets. With some thoughtful application of name-printing and
>> disambiguation rules, you can have gameplay like this:
>>
>>> ASK FRED ABOUT BOAT
>> What are you asking about specifically: whose boat it is, when
>> the
>> boat arrived, or whether the boat is for hire?
>>
>>> WHOSE BOAT
>> "That boat there?" says Fred. "Why, that's Jim's boat."
>>
>>> ASK FRED ABOUT WHEN BOAT ARRIVED
>> "Oh, it put in about 11:30 last night," says Fred.
>
> Yes, that is a possible implementation of a hybrid system; but
> note that
> it _is_ a hybrid between ask/tell and menus. (It is of little
> importance
> whether the menus are numbered, as in my games, or not, as in this
> example. In both cases you choose one of several explicitly given
> options. Using a numbered menu just saves the player some typing.)

Logically, your last statement should be correct: it shouldn't make
any difference whether or not the options are numbered, beyond the
fact that numbered options save a bit of typing. Psychologically I'm
not so sure: saving typing with numbered options can be a mixed
blessing. I think some players, myself included, find that having to
type some words forces us to process the conversational options a
bit more deeply, making the conversation a bit more immersive,
whereas it can become all too easy to type in numbers on autopilot.
Again, typing a number to choose an option is a bit less like
actually conversing than typing a word or two (even though these are
in effect two different mechanisms for selecting one of a limited
number of options); typing actual words forces you to think about
what you want to say. It may also be that once one has become
accustomed to entering commands as words at the command prompt,
entering numbers calls attention to the fact that it's an artificial
game interface (of course entering words at the command prompt is as
well, it's just that if it's used consistently it doesn't call quite
so much attention to itself).

So, though while you're right that a numbered menu saves typing, I
think it can make for less good gameplay. If you like, you can test
this out in my game Blighted Isle, in which the commands ENUM ON and
ENUM OFF turn the numbering of conversational options on and off
(sorry to suggest my own game here, but it's the only one I know
that does this).

That said, I agree with you that the type of conversational
interface that works best depends on the kind of game it's to be
used in; there's no "one size fits all" solution here.

-- Eric

Eric Eve says...
>
>"Victor Gijsbers" <victor DeleteThis @lilith.gotdns.org> wrote

>> Yes, that is a possible implementation of a hybrid system; but
>> note that
>> it _is_ a hybrid between ask/tell and menus. (It is of little
>> importance
>> whether the menus are numbered, as in my games, or not, as in this
>> example. In both cases you choose one of several explicitly given
>> options. Using a numbered menu just saves the player some typing.)
>
>Logically, your last statement should be correct: it shouldn't make
>any difference whether or not the options are numbered, beyond the
>fact that numbered options save a bit of typing. Psychologically I'm
>not so sure: saving typing with numbered options can be a mixed
>blessing. I think some players, myself included, find that having to
>type some words forces us to process the conversational options a
>bit more deeply, making the conversation a bit more immersive,
>whereas it can become all too easy to type in numbers on autopilot.

I agree with that. In menu systems that I've used (for example, in
the graphic game "Monkey Island"), I tend to try all possibilities
to see whether they produce something interesting. It doesn't end
up feeling much like a conversation at all.

I think that the psychological trick that makes interactive
fiction work is the illusion of open-endedness. At any point,
there may be only a small set of actions a user could do that
would advance the plot, but if you don't know exactly what that
set is, then it can feel limitless. Using ask/tell
maintains that illusion better than a menu system, in my opinion.

I'd also like to make another point: The hybrid system described
by mike gentry is *not* exactly the same as a menu system in
the choices are given explicitly. mike's list of options is
only for disambiguating the command "ask about boat". It hasn't
enumerated all possible things you could ask, only all possible
things you could ask about the *boat*. The broad topic boat is
from an unspecified list.

--
Daryl McCullough
Ithaca, NY