[INFORM] Menu-driven conversation, take 2
Magnus Olsson
I've looked at the games you mentioned, and here are some reflections:
* Most games with menu-based conversations uses the same interface as
Photopia, i.e. you get a list of choices in the main game text. I
think the main problem with this is that it interferes with the game
text - if you scroll back and read what you did, it's hard to see
which of all the choices you actually used. It can also be confusing
if the menu choices aren't identical to the actual lines spoken by the
PC (e.g. if the menu choice is "Insult the dwarf's ancestry" but, when
you choose this alternative, the PC actually produces a long tirade about
the dwarf's mother, her occupation, appearance and habits).
* It's more unobtrusive to put the menues in the status line, as
"Pytho's Mask". The main disadvantage to "Pytho", as I see it, is that
it's easy to miss that the menu has changed, or even that there is
a conversation menu. Perhaps the prompt should change or something.
* Then there's the question if the conversation should break out of
the normal turn system. "Once" has a menu system simlar to "Pytho's",
but the entire conversation is in essence one move. This has the
disadvantage that you can undo the entire conversation, but not just
the last thing you said. Some people may find this a feature rather
than a bug, but I don't think I agree - what's the use of undo if you
can't use it?
What I think I'd like the most is a system rather similar to that in
"Pytho's Mask", where the menu of choices appears in the status line,
and converstaion choices are treated as ordinary commands (so you can
undo), but where the system still has two different modes,
conversation and command. So when you're in a conversation, you can
only enter conversation menu choices, and you have to finish the
conversation before doing other things.
Then there's of course the entire question of implementation... :-)
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Neil Cerutti
>Thanks to the people who responded to my earlier post on this
>topic. I've looked at the games you mentioned, and here are some
>reflections:
>
>* Most games with menu-based conversations uses the same
>interface as Photopia, i.e. you get a list of choices in the
>main game text. I think the main problem with this is that it
>interferes with the game text - if you scroll back and read what
>you did, it's hard to see which of all the choices you actually
>used. It can also be confusing if the menu choices aren't
>identical to the actual lines spoken by the PC (e.g. if the menu
>choice is "Insult the dwarf's ancestry" but, when you choose
>this alternative, the PC actually produces a long tirade about
>the dwarf's mother, her occupation, appearance and habits).
>
>* It's more unobtrusive to put the menues in the status line, as
>"Pytho's Mask". The main disadvantage to "Pytho", as I see it,
>is that it's easy to miss that the menu has changed, or even
>that there is a conversation menu. Perhaps the prompt should
>change or something.
Hi Magnus.
I think those first two bullett points are mutually exclusive.
Doesn't putting the menu in the status line make it impossible to
read the transcript and see what your choice was?
>* Then there's the question if the conversation should break out
>of the normal turn system. "Once" has a menu system simlar to
>"Pytho's", but the entire conversation is in essence one move.
>This has the disadvantage that you can undo the entire
>conversation, but not just the last thing you said. Some people
>may find this a feature rather than a bug, but I don't think I
>agree - what's the use of undo if you can't use it?
The Big Mama's contest version was like that and I didn't like
it. A conversation tree system *begs* for undo to allow easy
exaustion of the alternatives. If a game allows undo at all, it
should allow undoing one conversation choice at a time.
>What I think I'd like the most is a system rather similar to
>that in "Pytho's Mask", where the menu of choices appears in the
>status line, and converstaion choices are treated as ordinary
>commands (so you can undo), but where the system still has two
>different modes, conversation and command. So when you're in a
>conversation, you can only enter conversation menu choices, and
>you have to finish the conversation before doing other things.
I disagree with that last idea. I dislike being forced to reply
to a conversation menu if what I really want to do is, for
example, take inventory. Photopia includes the clever device of
allowing you to "say nothing," but I didn't like to select it
because it could end a conversation I didn't want to end just
yet. It would be nicer, I think, to allow other commands to take
place.
>Then there's of course the entire question of
>implementation... :-)
Here's a simple CYOA system I wrote for Inform (as an exercise in
recursive Inform routines) that is extremely flexible,
though it does not use the status line. The commands that are
allowed when a multiple-choice prompt is active are configurable.
It seems to me that it would be possible to use it for
conversation trees, though it isn't as object oriented as it
might be for conversation (you can't Options in Options).
Included is a very skeletal implementation of the solo adventure
from the revised D&D basic set, Into the Caves, as an example of
how it works. There's no combat or actual D&D rules implemented.
URL:http://homepages.together.net/~cerutti/cyoa.zip
--
Neil Cerutti <cer...@together.net>
*** Your mining mules have deteriorated from heavy use and cost
$200 each to repair. The total cost is $600. ***
Magnus Olsson
Neil Cerutti <cer...@together.net> wrote:
>Magnus Olsson posted:
>>* Most games with menu-based conversations uses the same
>>interface as Photopia, i.e. you get a list of choices in the
>>main game text.
>>* It's more unobtrusive to put the menues in the status line, as
>>"Pytho's Mask".
>I think those first two bullett points are mutually exclusive.
>Doesn't putting the menu in the status line make it impossible to
>read the transcript and see what your choice was?
No, not if the game text repeats the PC's line.
Sample transcript:
| Audience Chamber
|
| This opulent room is dominated by a huge golen throne, which
| totally dwarfs the diminutive figure of His Supreme Imperial
| Highness, Megalomaximus the Greatest, Ruler of All Creation,
| etc, etc, so that!
|
| >talk to megalomaximus
|
| [ At this point, a menu appears on the status line, and the player
| chooses an alternative ]
|
| "Aren't you rather small for an emperor?", you say.
|
| His Majesty is livid with rage.
| "You shall show me the respect I deserve! Down in the dust and grovel,
| worm!"
So the transcript shows everything that was actually said, but not
the potential lines that weren't.
>I disagree with that last idea. I dislike being forced to reply
>to a conversation menu if what I really want to do is, for
>example, take inventory. Photopia includes the clever device of
>allowing you to "say nothing," but I didn't like to select it
>because it could end a conversation I didn't want to end just
>yet. It would be nicer, I think, to allow other commands to take
>place.
It would be nice, yes, but potentially confusing. I think I might
prefer having to break out of the conversation and restarting
it again. But on the other hand, I mightn't.
Neil Cerutti
OK. I thought that seeing the potential lines that weren't said
was part of what you wanted. Depending on how the status line is
handled, it might also make it impossible to scroll back in the
transcript before responding to the conversation prompt.
>>I disagree with that last idea. I dislike being forced to reply
>>to a conversation menu if what I really want to do is, for
>>example, take inventory. Photopia includes the clever device of
>>allowing you to "say nothing," but I didn't like to select it
>>because it could end a conversation I didn't want to end just
>>yet. It would be nicer, I think, to allow other commands to
>>take place.
>
>It would be nice, yes, but potentially confusing. I think I might
>prefer having to break out of the conversation and restarting
>it again. But on the other hand, I mightn't.
Right. What if you can't, for some reason, expect to restart the
conversation? I think it's similar to the criticism Zarf made of
games that prompts for Yes/No questions but don't allow players
to ignore the question and do something else (in particular,
meta-commands). If you have a sudden urge to save the game before
responding to Megalomaximus's ultimatum, you might be screwed.
Changeing the prompt is a compromise. And if the prompt is moved
to the status line a player certainly won't expect to be able to
save, restore, undo, etc...
--
Neil Cerutti <cer...@together.net>
*** One of your mules lost a bolt. Repairs cost you $300. ***
Magnus Olsson
Neil Cerutti <cer...@together.net> wrote:
>Magnus Olsson posted:
>>In article <slrn9d60r7...@fiad06.norwich.edu>,
>>Neil Cerutti <cer...@together.net> wrote:
>>>I disagree with that last idea. I dislike being forced to reply
>>>to a conversation menu if what I really want to do is, for
>>>example, take inventory. Photopia includes the clever device of
>>>allowing you to "say nothing," but I didn't like to select it
>>>because it could end a conversation I didn't want to end just
>>>yet. It would be nicer, I think, to allow other commands to
>>>take place.
>>
>>It would be nice, yes, but potentially confusing. I think I might
>>prefer having to break out of the conversation and restarting
>>it again. But on the other hand, I mightn't.
>
>Right. What if you can't, for some reason, expect to restart the
>conversation?
One way of doing this would be to make the "end conversation" option a
meta command, one that takes up no game time. And "talk to NPC" would
also be a metacommand, while each conversation option that actually
says something would be a real, time-consuming command.
That is, the commands to switch between "command mode" and
"conversation mode" would be metacommands that didn't affect the game
state (in the sense of "state of the actual game", not the program
state, because that would of course change).
>If you have a sudden urge to save the game before
>responding to Megalomaximus's ultimatum, you might be screwed.
With the above scheme, you choose "end conversation", "save", which is
a metacommand, and "talk to emperor" which is also a metacommand.
As far as Megalomaximus is concerned, no time has passed; you're
in exactly the same game state as if you hadn't saved.
The only disadvantage I can think of with this is that if you *really*
want to say nothing, but just wait, you have to first choose "end
conversation", and then wait for a turn.
Taking inventory instead of speaking, and then saying something, would
still take only one game turn; you'd only have to enter three commands
instead of one.
Sean T Barrett
>That is, the commands to switch between "command mode" and
>"conversation mode" would be metacommands that didn't affect the game
>state (in the sense of "state of the actual game", not the program
>state, because that would of course change).
>Taking inventory instead of speaking, and then saying something, would
>still take only one game turn; you'd only have to enter three commands
>instead of one.
It seems to me what you really want is for terps to support displaying
the status line at the bottom of the screen, then use the status line
for command input always, like in My Angel, because I think it would
be a lot more useable with the prompt at the same end as what you're
reading. This is the same as what you describe but there's no need
to switch modes to enter commands. The terps would have to do more work
to support the resizing input window, though. So in terms of what you
can actually do right now, ugh.
SeanB
Magnus Olsson
Well, what I really *want* is for the terp to be able to write a menu
in the main screen, right below the last output text, allow the player
to click on a menu item (or simulate clicking with the cursor keys),
and then erase the menu after the selection. Which is obviously not
going to happen with the Z machine.
Robb Sherwin
>What I think I'd like the most is a system rather similar to that in
>"Pytho's Mask", where the menu of choices appears in the status line,
>and converstaion choices are treated as ordinary commands (so you can
>undo), but where the system still has two different modes,
>conversation and command. So when you're in a conversation, you can
>only enter conversation menu choices, and you have to finish the
>conversation before doing other things.
Hmm... that would seem to eliminate one of my pet peeves that
menu-based conversations generate: not having an exclusive
conversation mode makes your NPCs really come off as mindless
robotoids when the player starts a conversation with them, does a
couple different, non-talking things, and then comes back to the
conversation with the NPCs acting like the dialogue hasn't missed a
beat.
The only thing is... I don't like "locking" the player into a
conversation since it reallly doesn't give them an 'out.' I don't want
things to become like the first ten minutes of Shenmue, where the
player is like, "yes, that's very nice, and that guy with the spiked
hair really did a number on your pop, but when can I actually
INFLUENCE things again? Where's the escape key on the Dreamcast?"
What I'm trying to do for the thing I'm currently working on is to
have some daemons update the conversation menu choices based on
whether or not the player immediately continued a natural conversation
or not. Mostly it's just a matter of adding something like "Hey, back
to what we were talking about -- blah blah blah" or "I meant to say,
before -- blahblahblah" and then the same response quip can be used.
Robb
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robb Sherwin, Fort Collins CO
Reviews From Trotting Krips: http://ifiction.tsx.org
Knight Orc Home Page: www.geocities.com/~knightorc
Joe Mason
>Sample transcript:
>
>| Audience Chamber
>|
>| This opulent room is dominated by a huge golen throne, which
>| totally dwarfs the diminutive figure of His Supreme Imperial
>| Highness, Megalomaximus the Greatest, Ruler of All Creation,
>| etc, etc, so that!
>|
>| >talk to megalomaximus
>|
>| [ At this point, a menu appears on the status line, and the player
>| chooses an alternative ]
>|
>| "Aren't you rather small for an emperor?", you say.
>|
>| His Majesty is livid with rage.
>| "You shall show me the respect I deserve! Down in the dust and grovel,
>| worm!"
I would do this by echoing the choice to the command line (probably with a
different prompt). Or maybe just do that for the transcript and not bother
on screen.
>talk to megalomaximus
[ Menu appears, player chooses alternative ]
>>comment on his size
"Aren't you rather small for an emperor?" you say.
That way you can easily match up the choice with what's in the menu the next
time through, and it's obvious that a choice was made. In the first version
it might look from the transcript like "talk to ..." just plays a prerecorded
conversation.
Joe
Joe Mason
>
>One way of doing this would be to make the "end conversation" option a
>meta command, one that takes up no game time. And "talk to NPC" would
>also be a metacommand, while each conversation option that actually
>says something would be a real, time-consuming command.
>
>That is, the commands to switch between "command mode" and
>"conversation mode" would be metacommands that didn't affect the game
>state (in the sense of "state of the actual game", not the program
>state, because that would of course change).
What about having a separate window open with the conversation menu, so that
you could either type a normal command or pick a menu option (which copies the
text to the command line). You could do this with the status line, but you'd
want to do some fiddling to allow it to be selected with a keypress. (I'm
thinking more of opening two input windows with Glulx or one of the other
formats with more flexible screen models.)
That way you could allow the player to start a conversation (ie. open the
window) with "talk to..." an either select an "end conversation" option, or
just ignore the conversation and walk away. NPC's could also start
conversations with the player without breaking them forcibly out of command
mode: if you don't want to talk, just ignore the conversation menu when it
appears.
Joe
Joe Mason
>want to say nothing, but just wait, you have to first choose "end
>conversation", and then wait for a turn.
You could still have a "say nothing" menu entry which is equivalent to "wait".
Joe
Magnus Olsson
Joe Mason <jcm...@student.math.uwaterloo.ca> wrote:
>I would do this by echoing the choice to the command line (probably with a
>different prompt). Or maybe just do that for the transcript and not bother
>on screen.
>
> >talk to megalomaximus
>
> [ Menu appears, player chooses alternative ]
>
> >>comment on his size
>
> "Aren't you rather small for an emperor?" you say.
>
>That way you can easily match up the choice with what's in the menu the next
>time through, and it's obvious that a choice was made. In the first version
>it might look from the transcript like "talk to ..." just plays a prerecorded
>conversation.
This is an excellent idea!
Daryl McCullough
>Joe Mason <jcm...@student.math.uwaterloo.ca> wrote:
>>I would do this by echoing the choice to the command line (probably with a
>>different prompt). Or maybe just do that for the transcript and not bother
>>on screen.
>>
>> >talk to megalomaximus
>>
>> [ Menu appears, player chooses alternative ]
>>
>> >>comment on his size
>>
>> "Aren't you rather small for an emperor?" you say.
>>
>>That way you can easily match up the choice with what's in the menu the next
>>time through, and it's obvious that a choice was made. In the first version
>>it might look from the transcript like "talk to ..." just plays a prerecorded
>>conversation.
>
>This is an excellent idea!
Since the Photopia way of using integers (or strings) to refer to
choices is so easy to implement, what if you allow *both* a menu
and an integer input. Then in replay, the transcript would look
like
>5
(choose answer number 5) even if the choice was made through the
menu.
--
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Sean T Barrett
>Hmm... that would seem to eliminate one of my pet peeves that
>menu-based conversations generate: not having an exclusive
>conversation mode makes your NPCs really come off as mindless
>robotoids when the player starts a conversation with them, does a
>couple different, non-talking things, and then comes back to the
>conversation with the NPCs acting like the dialogue hasn't missed a
>beat.
Hmm, that reminds me, I should finish bugfixing my
game that went into beta four months ago. Sigh.
SeanB
OKB -- not okblacke
>What about having a separate window open with the conversation menu, so that
>you could either type a normal command or pick a menu option (which copies
>the
>text to the command line). You could do this with the status line, but you'd
>want to do some fiddling to allow it to be selected with a keypress. (I'm
>thinking more of opening two input windows with Glulx or one of the other
>formats with more flexible screen models.)
I am in the final stages of writing a Glulx library which does exactly
this.
--OKB (Bren...@aol.com) -- no relation to okblacke
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
J. Robinson Wheeler
>
> Sean T Barrett wrote:
> >It seems to me what you really want is for terps to support displaying
> >the status line at the bottom of the screen, then use the status line
> >for command input always, like in My Angel, because I think it would
> >be a lot more useable with the prompt at the same end as what you're
> >reading. This is the same as what you describe but there's no need
> >to switch modes to enter commands. The terps would have to do more work
> >to support the resizing input window, though. So in terms of what you
> >can actually do right now, ugh.
>
> Well, what I really *want* is for the terp to be able to write a menu
> in the main screen, right below the last output text, allow the player
> to click on a menu item (or simulate clicking with the cursor keys),
> and then erase the menu after the selection. Which is obviously not
> going to happen with the Z machine.
Seems like you might be able to do this in HTML-TADS by drawing
a banner with the clickable menu items, then removing the banner
after the selection is made.
--
J. Robinson Wheeler Games - http://raddial.com/if/
whe...@jump.net Movie - http://thekroneexperiment.com
John Colagioia
[...]
> * It's more unobtrusive to put the menues in the status line, as
> "Pytho's Mask". The main disadvantage to "Pytho", as I see it, is that
> it's easy to miss that the menu has changed, or even that there is
> a conversation menu. Perhaps the prompt should change or something.
On the other hand, it allows one to easily ignore any conversation in which
the player does not want to participate.
> * Then there's the question if the conversation should break out of
> the normal turn system. "Once" has a menu system simlar to "Pytho's",
> but the entire conversation is in essence one move. This has the
> disadvantage that you can undo the entire conversation, but not just
> the last thing you said. Some people may find this a feature rather
> than a bug, but I don't think I agree - what's the use of undo if you
> can't use it?
I wouldn't mind an "undo last comment" and an "undo conversation" command,
but that starts getting to be painful to program. And opens up new cans of
worms ("Why can't I undo three comments...?").
> What I think I'd like the most is a system rather similar to that in
> "Pytho's Mask", where the menu of choices appears in the status line,
> and converstaion choices are treated as ordinary commands (so you can
> undo), but where the system still has two different modes,
> conversation and command. So when you're in a conversation, you can
> only enter conversation menu choices, and you have to finish the
> conversation before doing other things.
I'm not a fan of "modes," honestly. Again, it might just be me, but I find
such things (even as subtle as changing the prompt) to seem a little
"hackish," as if the programmer failed to integrate the ability into the
game. Not that this is at all the case (since I'm sure many authors have
heavily considered their conversation system and decided it was the best),
just that it gives me that impression.
> Then there's of course the entire question of implementation... :-)
Well, if you want to get all technical about it, yeah...
Magnus Olsson
John Colagioia <JCola...@csi.com> wrote:
>Magnus Olsson wrote:
>[...]
>
>> * It's more unobtrusive to put the menues in the status line, as
>> "Pytho's Mask". The main disadvantage to "Pytho", as I see it, is that
>> it's easy to miss that the menu has changed, or even that there is
>> a conversation menu. Perhaps the prompt should change or something.
>
>On the other hand, it allows one to easily ignore any conversation in which
>the player does not want to participate.
As does a "terminate conversation" menu entry. And, more arguably,
"say nothing".
>> What I think I'd like the most is a system rather similar to that in
>> "Pytho's Mask", where the menu of choices appears in the status line,
>> and converstaion choices are treated as ordinary commands (so you can
>> undo), but where the system still has two different modes,
>> conversation and command. So when you're in a conversation, you can
>> only enter conversation menu choices, and you have to finish the
>> conversation before doing other things.
>
>I'm not a fan of "modes," honestly. Again, it might just be me, but I find
>such things (even as subtle as changing the prompt) to seem a little
>"hackish," as if the programmer failed to integrate the ability into the
>game.
Modes are in general considered bad interface design, so, no, it's not
just you.
But the very decision to use conversational menus is a decision to
make the program modal: one mode for conversations, one for everything
else. It's just a matter of how strict this modality is, and how easily
you can switch between modes.
To me, there is one question of game design: to use conversation menus
or ask/tell, and one question of user interface design: how to handle
the menu choices and the mode transition.
Sean T Barrett
>But the very decision to use conversational menus is a decision to
>make the program modal: one mode for conversations, one for everything
>else. It's just a matter of how strict this modality is, and how easily
>you can switch between modes.
This is false, and I meant to explain this in my last post but
I got sidetracked by the status line position and never got to
my main point. Picture the following: a game where you type
'talk to X' which brings up a conversation menu of things to
say to that character. You can always select '0' which cancels
without taking a turn.
Now, imagine that instead of typing 0, you can just type any
old command you please. (In other words, you get a real prompt,
but you have the option of typing in the number of a conversation
choice instead.) [There's an analogy here to a game in which
the only things you can say are "yes" and "no", which can be
thought of as choices from a two-item menu.]
Now move the conversation choices off to the status line so
you can leave them up all the time without filling the screen
and scrollback with them.
At this point, you're not at all modal between conversations
and everything else, although you are modal in terms of which
NPC you're talking to--unless you want to start showing all
of the conversation options for every character present at
all times.
Now, if you want conversation menus that you select by
using arrow keys and the like, that is going to be modal
in some sense compared to typing in commands, no matter what.
SeanB
ems...@mindspring.com
> Now, imagine that instead of typing 0, you can just type any
> old command you please. (In other words, you get a real prompt,
> but you have the option of typing in the number of a conversation
> choice instead.)
> Now move the conversation choices off to the status line so
> you can leave them up all the time without filling the screen
> and scrollback with them.
> At this point, you're not at all modal between conversations
> and everything else, although you are modal in terms of which
> NPC you're talking to--unless you want to start showing all
> of the conversation options for every character present at
> all times.
This is, in fact, exactly how Pytho's Mask works, with the additional
point that you can change the menu you see if you want to talk about a
new topic.
The further advantage of this (in my opinion, at least) is that it
allows the player to do NPC-interactive things in the midst of a
conversation -- react to something that has been said either with a
snappy remark or with a kiss or slap in the face or by storming out of
the room -- which is a kind of flow that is difficult if not impossible
to attain if you slip into another mode to handle conversations.
ES
ems...@mindspring.com
> * It's more unobtrusive to put the menues in the status line, as
> "Pytho's Mask". The main disadvantage to "Pytho", as I see it, is that
> it's easy to miss that the menu has changed, or even that there is
> a conversation menu.
Is it really? I've heard assorted objections before, but this isn't one
of them. I suppose I was assuming that if you're in the midst of a
conversation you would have one eye on the status line more or less all
the time; and, in my mind, at least, it provided an additional way to
characterize the PC by kind of showing the player what was running
through her head at any given moment.
De gustibus, I suppose. Future uses of this system will probably move
into glulx territory anyway, and I will be freer to fiddle with the
aesthetic side of things.
ES
Magnus Olsson
>>But the very decision to use conversational menus is a decision to
>>make the program modal: one mode for conversations, one for everything
>>else. It's just a matter of how strict this modality is, and how easily
>>you can switch between modes.
>
>This is false,
Is not! :-)
Actually, it's a matter of definition.
What I meant was this: in a game with conversation menus, you have one
mode which is just like an ordinary adventure game, except that the
"ask" and "tell" verbs are disabled. Then, you start talking to NPC Bob,
and the game starts behaving differently: suddenly, the command "1",
which in the normal mode is nonsense, means that you want to say something
- and, moreover, exactly what it means depends on the game state.
So I'd say that the game (the abstract entity, not the UI) is in a
different mode when doing the conversation. That this mode contains
the "ordinary" mode is of course a complication, but I'd still like to
think of it as a different mode.
In contrast, in a "traditional" game, you're free to say "ask Bob
about the crown" at any time. Of course, that command may give
different responses at different times (mostly, I suppose, "You can't
see any Bob here"), but it's still accepted by the parser.
Magnus Olsson
>Magnus Olsson <m...@pobox.com> wrote:
>> * It's more unobtrusive to put the menues in the status line, as
>> "Pytho's Mask". The main disadvantage to "Pytho", as I see it, is that
>> it's easy to miss that the menu has changed, or even that there is
>> a conversation menu.
>
>Is it really? I've heard assorted objections before, but this isn't one
>of them.
Well, it may be just the way my brain works... And it's more of an
observation than an objection.
>I suppose I was assuming that if you're in the midst of a
>conversation you would have one eye on the status line more or less all
>the time;
How could I? While talking to, say, the Moon Minister, his responses
are output in the main window, so I have to shift my attention to that
text. OK, as long as I'm just talking, I will immediately look back to
the status line, but I think the problem occurs when I do a
non-conversation command, in which case the status line loses its
importance, and I tend to forget to keep an eye on it.
Perhaps the real problem is that you're using the status line for
critical information - but in most games, the status line can be
ignored entirely. So I've programmed my mind to more or less filter
out the status line.
>and, in my mind, at least, it provided an additional way to
>characterize the PC by kind of showing the player what was running
>through her head at any given moment.
It certainly did. And please note that I'm not criticizing the system
itself - which I, as I've said elsewhere, consider one of the best
implementations of a conversation menu system that I've seen so far -
but just noting a difficulty that I had with it.
>De gustibus, I suppose.
I don't think it's much _gustibus_, really, but the ways we are used
to process information presented on the screen. In other words, I
think I'll need some time getting used to looking at the status line
more often.
And, with all respect, I object to the notion that this is a matter of
taste, hence it's meaningless to discuss it - au contraire, I think
that user interface considerations like this *should* be discussed, in
order that we can all improve our designs.
>Future uses of this system will probably move
>into glulx territory anyway, and I will be freer to fiddle with the
>aesthetic side of things.
I think - and hope - that moving to Glulx will provide us with the
power we need. Personally, I'm a bit reluctant to do so at the moment,
but if I find that the Z-machine screen model is too restrictive for
what I want to do (which may not at all coincide with what you want to
do), I will consider such solutions as well.
Starweaver
I think I have an idea that might work around these modalness problems
with conversation trees; what i'm planning on using on my gonna-someday
project anyway.
The basic idea is to, instead of parsing the response to a menu straight
through the entry line, parse it through a verb. Preferably one with a
convinent one letter synonym like 'r' or 'a'. Thus a selection would be
similar to:
.
.
.
The angry beaver king snarls at you, pink bunny shaped switchblade in
hand.
1.) Snarl Back
2.) Curse his ansestory
3.) Etc.
>a 1
The beaver backs away at the sound of your hiss.
1.) Snarl more
2.) Attempt to befrend it
>load shoutgun with ac9 shell
The beaver looks at you with sad puppy-dog eyes
1.) Threaten it with shotgun
2.) Hide gun and act peacefully
>a 1
.
.
.
This would seem to allow other actions during conversations without the
sloppy feel of switching windows or the more confusing method of making
ending and beginning it meta-zero-time commands, as was suggested earlier.
Wow, 2 delurks in a row. %D. I apologize for any confusing rambling
chararastics or poor spelling in this post, as it is 3:30 am here and my
main intent is to post this before I forget. Ja...
--
"Ronin Angel" Starweaver (RASX)
StarWeaver
<Xns9081247FEF8F...@63.192.42.254>:
Gaahhh. I also meant to mention that this system would be completly
compatable with the old 'ask person about thing' format, which is a
better solution in some situations, such as a shopkeeper in a store full
of items. Just ask him about the bread or apple, and leave the menu for
the type of thing that people have a hard time doing with that system.
Also, perhaps an alternate command that brings up a modal menu of 'things
that the player knows about', like 'the murder of count wimphfry' or 'the
worsening weather'. It would save the player from having to figure out
what the valad topics of conversation are, without revealing things not
yet known. Maybe it should just synonym into the ask/tell about x format,
which could also be used by people who so prefer.
Sorry for the ramblyness again...
Kevin Bracey
m...@pobox.com (Magnus Olsson) wrote:
>
> Well, what I really *want* is for the terp to be able to write a menu
> in the main screen, right below the last output text, allow the player
> to click on a menu item (or simulate clicking with the cursor keys),
> and then erase the menu after the selection. Which is obviously not
> going to happen with the Z machine.
Perfectly possible with version 6.
--
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc Tel: +44 (0) 1223 518566
645 Newmarket Road Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pace.co.uk/
Magnus Olsson
Kevin Bracey <kevin....@pace.co.uk> wrote:
>In message <9av7qj$e22$2...@news.lth.se>
> m...@pobox.com (Magnus Olsson) wrote:
>
>>
>> Well, what I really *want* is for the terp to be able to write a menu
>> in the main screen, right below the last output text, allow the player
>> to click on a menu item (or simulate clicking with the cursor keys),
>> and then erase the menu after the selection. Which is obviously not
>> going to happen with the Z machine.
>
>Perfectly possible with version 6.
Oh, didn't think of that.
How complicated would it be to do this stuff in v6? And how many
interpreters would be able to handle it?
Would there be any advantages over going the whole hog and using
Glulx?
Matthew T. Russotto
}
}I think - and hope - that moving to Glulx will provide us with the
}power we need. Personally, I'm a bit reluctant to do so at the moment,
}but if I find that the Z-machine screen model is too restrictive for
}what I want to do (which may not at all coincide with what you want to
}do), I will consider such solutions as well.
Do it... Java Glulx is at the point where it can run simple test
files, but I'll never finish it without a continuous stream of new
games as incentive. And maybe someone will be motivated to write a
decent Java Glk library. I'd post my interfaces and the PoorGlk
library, but my machine has connectivity issues at the
moment. (Northpoint, IYKWIM)
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
James Taylor
> m...@pobox.com (Magnus Olsson) wrote:
> >
> > Well, what I really *want* is for the terp to be able to write a menu
> > in the main screen, right below the last output text, allow the player
> > to click on a menu item (or simulate clicking with the cursor keys),
> > and then erase the menu after the selection. Which is obviously not
> > going to happen with the Z machine.
>
> Perfectly possible with version 6.
Will !Zip2000 for RISC OS do this too?
Kevin, I ought to take this opportunity to thank you most emphatically
for !Zip2000 without which I would not be able to enjoy this most
noble art form we call interactive fiction.
Is there any chance of getting your !TADS port to run in a similar
interface? I tend to limit myself to Z-code games precisely because
I cannot multitask the !TADS player.
What about Glulx? Presumably you wouldn't have time to port this too,
so RISC OS users will have to do without. :-( <sniff>
--
James Taylor <james (at) oakseed demon co uk>
Based in Hammersmith, London, UK.
PGP key available ID: 3FBE1BF9
Fingerprint: F19D803624ED6FE8 370045159F66FD02
Jon Ingold
> critical information - but in most games, the status line can be
> ignored entirely. So I've programmed my mind to more or less filter
> out the status line.
This is basically what a lot of people disliked about My Angel's NOVEL
mode too - moving the eyes up, and down, throughout the game. It seems
this is just what we're used to as players.
Jon
Mike Roberts
> What I meant was this: in a game with conversation menus, you have one
> mode which is just like an ordinary adventure game, except that the
> "ask" and "tell" verbs are disabled. Then, you start talking to NPC Bob,
> and the game starts behaving differently: suddenly, the command "1",
> which in the normal mode is nonsense, means that you want to say something
> - and, moreover, exactly what it means depends on the game state.
Some time ago I was toying with an idea for a hybrid menu-based conversation
system that would keep the menu but dispense with the modality. You'd see a
menu and an ordinary prompt; if you wanted to say something from the menu,
you'd type the number, otherwise you'd just type an ordinary command.
Since, as you say, typing just a number by itself is nonsense in "normal"
mode, we could easily start accepting a number by itself in normal mode as
selecting a menu item. This approach would be stateful but not modal, which
is not a bad fit for actual human conversations.
(I thought it might also be nice in html tads mode to use hyperlinks for the
menu items, with the hyperlinks entering commands like "say 'I won't give
you the emerald until you tell me the password'" rather than just the menu
numbers - in other words, each hyperlink would enter a "say" command with
the literal text of the menu choice, which the parser would match from the
menu tree. Naturally in non-html mode, where the player would be doing the
typing, the number alone would be equivalent.)
This approch would complicate the implementation somewhat by creating many
more ways to exit a conversation at any point (you could just walk out in
the middle of it, for example); but it might also make some things more
natural than with a strictly menu-based system, since you could manipulate
objects in the course of a conversation (give the npc an object, take an
object, read a letter you picked up earlier). I don't think the added
complication is insurmountable, though.
--Mike
John Colagioia
Not just your opinion. That is one thing that is almost a necessity for
smoothly-flowing conversation. Without it, body language of any sort becomes
entirely impossible (except where prespecified by a menu, perhaps, but that's
similarly unpleasant, because there are only so many listable choices).
I found "Pytho's Mask" to be the best compromise so far. About the only major
improvement I might suggest would be to link some of the usual conversation verbs
(ask, tell, and show, probably) to the "topic" verb. Then one could type, "show
the rotted banana peel to the cleaning lady," and be given more precise options
as to exactly what the player wants to say. Ideally, the verb used in that
context might even affect the comments available--that is, "ask woman about the
thermonuclear device" would supply questions, whereas, "tell woman about the
thermonuclear device" would supply a list of comments.
That last bit might be needlessly excessive for most purposes, however.
> ES
Neil Cerutti
>Magnus Olsson <m...@pobox.com> wrote:
>> What I meant was this: in a game with conversation menus, you
>> have one mode which is just like an ordinary adventure game,
>> except that the "ask" and "tell" verbs are disabled. Then, you
>> start talking to NPC Bob, and the game starts behaving
>> differently: suddenly, the command "1", which in the normal
>> mode is nonsense, means that you want to say something - and,
>> moreover, exactly what it means depends on the game state.
>
>Some time ago I was toying with an idea for a hybrid menu-based
>conversation system that would keep the menu but dispense with
>the modality. You'd see a menu and an ordinary prompt; if you
>wanted to say something from the menu, you'd type the number,
>otherwise you'd just type an ordinary command. Since, as you
>say, typing just a number by itself is nonsense in "normal"
>mode, we could easily start accepting a number by itself in
>normal mode as selecting a menu item. This approach would be
>stateful but not modal, which is not a bad fit for actual human
>conversations.
The multiple choice system I posted earlier in this thread works
like that. Here's the link again for anybody who would like to
see what a system like that feels like to use:
URL:http://homepages.together.net/~cerutti/cyoa.zip
>(I thought it might also be nice in html tads mode to use
>hyperlinks for the menu items, with the hyperlinks entering
>commands like "say 'I won't give you the emerald until you tell
>me the password'" rather than just the menu numbers - in other
>words, each hyperlink would enter a "say" command with the
>literal text of the menu choice, which the parser would match
>from the menu tree. Naturally in non-html mode, where the
>player would be doing the typing, the number alone would be
>equivalent.)
If the hyperlink could be kind of small, like only on the number,
it would be nice. Huge hyperlinks look crappy.
>This approch would complicate the implementation somewhat by
>creating many more ways to exit a conversation at any point (you
>could just walk out in the middle of it, for example); but it
>might also make some things more natural than with a strictly
>menu-based system, since you could manipulate objects in the
>course of a conversation (give the npc an object, take an
>object, read a letter you picked up earlier). I don't think the
>added complication is insurmountable, though.
I'm with you. And you could always reserve the option of
dynamically limiting a player's options any time you wanted.
--
Neil Cerutti <cer...@together.net>
OKB -- not okblacke
>The basic idea is to, instead of parsing the response to a menu straight
>through the entry line, parse it through a verb. Preferably one with a
>convinent one letter synonym like 'r' or 'a'.
This is what my under-construction library does. You select menu options
via a normal verb ("say") followed by a number corresponding to the menu option
you want.
OKB -- not okblacke
>I think - and hope - that moving to Glulx will provide us with the
>power we need. Personally, I'm a bit reluctant to do so at the moment,
>but if I find that the Z-machine screen model is too restrictive for
>what I want to do (which may not at all coincide with what you want to
>do), I will consider such solutions as well.
I can almost assure you that it does. I am ---><--- this close to
releasing a spiffy, separate-window, Glulx conversation menu system. (I was
going to keep it to myself until I'd written a game, but I guess I might as
well strike while the iron is hot. :-)
David Fletcher
[snip]
>
> What about Glulx? Presumably you wouldn't have time to port this too,
> so RISC OS users will have to do without. :-( <sniff>
>
Don't see why - I managed to compile glulxe with CheapGlk for RISC OS.
Unfortunately I don't have my Acorn machine or the binary any more,
and I don't think I ever put it on gmd. Still, someone should be able
to do it easily enough.
AFAIR it compiled straight out of the box with gcc and UnixLib. Of
course CheapGlk is not ideal but it did work.
--
David.
Adam Biltcliffe
> The angry beaver king snarls at you, pink bunny shaped switchblade in
> hand.
I think some of the people who've come up with examples like this should
be *made* to write games.
jw
Starweaver
<9bcs6n$6he$1...@newsg3.svr.pol.co.uk>:
It may be scary, but 'this one' intends to %D.
(Though that was more of a result of "it's 4 am and i need an example"...)
:}