City of Secrets conversation interface
Daniel Barkalow
interesting (I'm not yet sure exactly how interesting; I need to play
through it by a different path still). Being a programmer at heart,
however, I want to review not the game but the engine.
The mechanism of playing IF is, for the most part, exploration. Whether or
not the story involves literal exploration, the player is always exploring
the edges of what they've tried before, looking for new responses which
lead, hopefully, in a promising direction.
This engine opens up a whole new mode of interaction between the player
and the game. In addition to the world model we've had since Colossal
Caves, there's a "world" model involving interacting with NPCs. There have
been such models before, but they've largely involved one-step
interactions with the NPC; you come up to the NPC and show an object, or
mention a topic, and the plot advances. Contrast that with the world
model, where you move around in the space, carry objects, and so
forth. The NPC model has largely been an additional interaction in the
world model. Emily has made an NPC interaction model which is, in many
ways, by itself akin to the whole world model. You can wander from topic
to topic and select among a set of options, some of which advance the plot
and some of which hinder it. You can carry topics from one NPC to
another. You have as much state in the conversation as you do in the model
world. It's a vast new world, tuned to character interaction rather than
map exploration.
On the other hand, I feel like I'm lost in this interface. I can identify
my immediate choices, and I have some idea of where I'm going, but when I
make a move, I feel like I'm losing track of where I've been, how to
get back, and where else I could go next. City of Secrets has a build-in
map and an on-screen compass, but there's no assistance for conversation,
which is the greater part of the game. I think there are a few simple
things lacking in the set of commands.
The first thing is that, after I say something, I can't get that response
again. Of course, this makes some sense; NPCs should just repeat the same
thing over and over if you keep saying the same thing. But it then becomes
useful to provide some way of getting the response again as
meta-information, either having the player recall what the NPC said about
a certain topic or simply asking the NPC to repeat themselves. Certainly
it shouldn't work just by having the NPC ignore the fact that the
conversation is going around in circles, but there should be some way to
review the information, especially in a game where NPC interaction is
replacing a good portion of item-finding and area-exploration, both of
which are easy to repeat.
The next thing is that, when I see an option, I may think it's something
I'll want to say eventually, but not right away. However, I don't have any
way of determining how to get the option again in the future. Obviously,
some options won't work later, because the NPC's attitudes have changed or
they've left or something. But it's frustrating to have a lull in the
conversation and remember that there was something I wanted to say, but
not be able to find it, either due to not knowing what topic it was on, or
to having had it pruned from the topic without my knowing.
I think the particular interface in City of Secrets was a bit more
problematic. I often found that I said something I really didn't want to
say to a given character just because it was the only thing left in the
topic when I went back to it after talking to someone else. Furthermore, I
spent quite a few game turns trying to find topics I hadn't exhausted, or
trying to find a topic that what I wanted to know would fit into, and then
the NPC would think I didn't have anything to say. I think that "topic"
should never take any time, and shouldn't be potentially dangerous.
It seemed to me like City of Secrets was both extra hard and extra
easy; the player could so easily fall out of critical conversations or
lose track of important information that it couldn't have been difficult
without being unfair, so it had to be easy. It seems like the engine has
now been worked out for realism and feeling like a conversation, but the
interface needs work for game balance.
When doing object interaction, you can have the descriptions repeated as
often as you want, you can get a list of the objects locally available,
and you can get a list of the objects you're carrying and might use in a
new situation. These are all important not only for realism but for
playability. With this engine, we so far have only the third (in the form
of the "topics" meta verb). I think it would be useful to have a further
menu for reviewing interactions you've already had with a particular NPC
on a subject, and to have a count of things you've seen that you can say
to this NPC by each topic in the list which you have tried with this NPC.
I suspect that this would make current games really easy, make more
difficult games possible, and make it more clear when the path you take
through the conversation actually does matter.
-Iabervon
*This .sig unintentionally changed*
Gunther Schmidl
> The first thing is that, after I say something, I can't get that
> response again.
...unless you check in the terp scrollback or have a SCRIPT running.
> The next thing is that, when I see an option, I may think it's
> something I'll want to say eventually, but not right away.
...the game can't be made unwinnable, so you can say whatever you want
whenever you want.
-- Gunther
OKB (not okblacke)
> Daniel Barkalow wrote:
>> The first thing is that, after I say something, I can't get that
>> response again.
>
> ...unless you check in the terp scrollback or have a SCRIPT running.
Well, sure, but when the volume of text in question is really
large, like in CoS, it's not that simple. Scrollback might be huge, and
you might have forgotten exactly when it was you said what you're trying
to find again. An extra-game technique like searching an external file
is a possible solution, but I do think that in most cases it's better to
provide an in-game way to deal with these kinds of problems.
>> The next thing is that, when I see an option, I may think it's
>> something I'll want to say eventually, but not right away.
>
> ...the game can't be made unwinnable, so you can say whatever you want
> whenever you want.
Again, sure, but not wanting to say something right away doesn't
necessarily mean "you're afraid you might die if you say this right now"
-- maybe you just want to say something else first. Of course, arguably
this amounts to making an end run around the psychological model that
presumably underlies the conversation mechanism -- in real life, it IS
possible to lose your opportunity to say something -- and therefore is
not fair play on the game's terms. Nevertheless, I do recall
experiencing a similar frustration with conversation not working the way
I expected and/or hoped.
--
--OKB (not okblacke)
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
Kevin Forchione
news:Xns937A6B...@130.133.1.4...
> Gunther Schmidl wrote:
>
> > Daniel Barkalow wrote:
> >> The first thing is that, after I say something, I can't get that
> >> response again.
> >
> > ...unless you check in the terp scrollback or have a SCRIPT running.
>
> Well, sure, but when the volume of text in question is really
> large, like in CoS, it's not that simple. Scrollback might be huge, and
> you might have forgotten exactly when it was you said what you're trying
> to find again. An extra-game technique like searching an external file
> is a possible solution, but I do think that in most cases it's better to
> provide an in-game way to deal with these kinds of problems.
An in-game journal, say indexed by topic and/or character should be a simple
device to implement.
--Kevin
Daniel Barkalow
> Daniel Barkalow wrote:
> > The first thing is that, after I say something, I can't get that
> > response again.
>
> ...unless you check in the terp scrollback or have a SCRIPT running.
Not very helpful if you save and stop playing for a month, which I've done
with other games in the past.
> > The next thing is that, when I see an option, I may think it's
> > something I'll want to say eventually, but not right away.
>
> ...the game can't be made unwinnable, so you can say whatever you want
> whenever you want.
The real problem is when you haven't really excluded a particular option,
but don't know how to find it again. There are some options which you only
get for two turns after an event (because they're contextual responses to
the event), and if you want to use these options, you have to do so at
once. But you might then change the topic, and there might be another
option you'd like to say eventually, but it doesn't seem to be on a topic
you can identify.
(There are actually situations where you can't say something at a later
time, because the NPC will no longer talk to you; I found this less of an
issue, because that's part of the game)
ems...@mindspring.com
> On Tue, 13 May 2003, Gunther Schmidl wrote:
>
> > Daniel Barkalow wrote:
> > > The first thing is that, after I say something, I can't get that
> > > response again.
> >
> > ...unless you check in the terp scrollback or have a SCRIPT running.
>
> Not very helpful if you save and stop playing for a month, which I've done
> with other games in the past.
>
> > > The next thing is that, when I see an option, I may think it's
> > > something I'll want to say eventually, but not right away.
> >
> > ...the game can't be made unwinnable, so you can say whatever you want
> > whenever you want.
>
> The real problem is when you haven't really excluded a particular option,
> but don't know how to find it again. There are some options which you only
> get for two turns after an event (because they're contextual responses to
> the event), and if you want to use these options, you have to do so at
> once. But you might then change the topic, and there might be another
> option you'd like to say eventually, but it doesn't seem to be on a topic
> you can identify.
Eh, well, wandering off topic is part of the game, too. But, okay,
you don't like this.
For release 3, which I hope to upload in the next week or so, I have
added
a) a user option to turn off the automatic speaking of a sole
remaining menu item, so that if you wish you're guaranteed to see what
you are about to say before you say it in all cases.
b) a verb that will allow you to see what already-explored topics
currently have active conversation items in them. (It will not mention
viable conversation topics if you have not yet discussed them in the
game.) I am frankly not crazy about this, since it seems to me to
play up the gamey fakeness of the conversations, and play down the
mimesis. But if you don't want to use it, you don't have to; so you
can still experience the thing as I originally intended, and all the
people who disagree can have it their way as well. [No, I'm not
really sure why I see this as inherently different from letting the
player take inventory. Perhaps because inventory is an old and
accepted convention.]
c) a verb to remind you of what you've talked about in this particular
conversation. Probably less useful or interesting, but still, there
if you want it.
Now, (d) -- that is, a complete, well-organized database allowing you
to review verbatim everything you've been told thus far in the game --
may not be possible to retrofit as such, despite Kevin Forchione's
optimism. I can think of ways to program it; I can't, given the way
conversation is generated, think of a very good way that wouldn't
involve caching a copy of the actual output as it's printed to the
screen. A lot of the conversation is affected by in-game variables:
the mood of the NPC you're talking to, how many times you've discussed
this topic with someone else before, specific game states that might
change before you got around to executing the recap, and so on.
*Some* of the conversation is also mildly randomized to ensure that
that phrasing of certain things doesn't get repetitive. So it's not
as though there's a
say_this [; "blah!"; ],
property that I can simply call a second time to show the exact same
text again.
To caching, then. There are between 3500 and 4000 conversational
exchanges in the game. The easiest way to record them would require,
I think, creating one additional object apiece for record-keeping
purposes. More sophisticated (and thus more difficult to program and
more error-prone) techniques might be able to cut this down quite a
lot -- after all, not *every* statement comes in multiple forms -- but
I am still concerned about the overhead. I did quite a lot of hackery
and library rewriting to speed the game up and minimize the number of
items, and it still plays much too slowly, to my mind. I've heard
rumors of it being successfully played on a Zaurus, but it's doubtless
beyond the average handheld; I'd prefer not to make it too sluggish
for anyone's desktop to run, either. There are already noticeable
pauses even on my (rather nice) iMac.
I'm also worried, from the other end, about how to make a
conversation-recall tool that would be usable; there are 250-odd
topics available, and 38 talking characters, so that even a "What do
you want to remember?" menu organized by topic and character could
become almost unbearably cumbersome by the end of the game. If it's
sufficiently irritating to use, there's not a great deal of advantage
to including this in-game, instead of allowing the player to pop open
the transcript in a text editor and doing a search for the NPC's name
or the topic keyword.
To add even more hideousness, some NPC conversation is not stored as a
response to a question or statement, but as a comment that the NPC
will volunteer when the conversation state is right. Trying to catalog
these for later retrieval might be a pain, since they can't be filed
under 'answers to foo' or 'statements about bar'.
I do appreciate the undesirability of note-taking as part of the IF
process; I tried, with the THINK ABOUT verb, to make your thoughts
about a few really critical topics reflect your discoveries, as a kind
of summary of what you've learned. I suppose I could expand that
system somewhat if it would be a useful thing -- so that THINK ABOUT
FOO would produce "you've discussed this with x, who said a, and with
y, who said b". The downside of *this* alteration is that it would
require a lot of careful hand editing to prepare; another couple of
weeks or even months, maybe, before I could get it installed. But
probably it would create less drain on the system than a complete and
full conversation-recap ability. Then again, maybe it wouldn't be
satisfactory if you couldn't remember the exact words.
(Another idea I considered, then tossed out, is using one of the nifty
libraries that would incorporate an in-game notepad object on which
your character could take notes. A cool piece of coding, but I think
probably an inadequate substitute here, since if I understand properly
what you want is to avoid the necessity of taking the notes in any
form, not merely the necessity of having a piece of paper on your
desk. Besides, there are good plot reasons for the main character not
to be wandering around with a notebook full of jottings.)
My original theory about this, and the reason I assumed that recap
wouldn't be necessary in this game, is that most of the information
you gather, you gather gradually and through repetition. There are
almost always multiple sources of information on a given topic; it is
extremely rare for anyone to tell you anything that you have to
remember exactly, and those few things are accounted for by the THINK
ABOUT system. So I suppose I expected the player not to ask the same
person the same question over and over, but to ask *different* people
the same question, thus reinforcing the factual content while
developing a sense of the different personae and attitudes involved.
Anyway, I've been thinking about how to correct the problems you cite,
and nothing obvious comes to mind on this particular score. I'd
welcome any suggestions. Making the underlying system practical for
general use in other games is not possible, but I would like to make
*this* game as playable as possible given the time investment it
represents.
--
On a less technical note, I think the "I want to be able to drop the
game for one or two months and come back to it and have everything
available" approach is just simply not going to work with this
particular game. It is dense enough, and dependent enough on its
narrative pacing, that I think of it more like a novel than like a
crossword; you're not meant to set it aside, forget everything, and
then return to it cold. It doesn't take long to replay from the
beginning if you already know what you're doing, and I suspect the
experience would be superior to trying to pick the threads up again
from where you left off.
I suppose it's fairly officious for me to tell people how to play my
game, and, of course, everyone's free to do what they like. But I
wrote it assuming that the player would be playing it over the course
of one or two sessions (or four or five, but closely spaced); and that
assumption did have a large effect on how I wrote it. In my
experience it's the more puzzle-oriented games that fare best with a
long hiatus of play, where stepping back for a moment actually makes
it more likely that you'll be able to figure out what to do next.
Here (I hope) that is less of an issue.
Finally, the easyness of the game was the result of commission
constraints from the outset, and not really (I think, anyway) a
necessary and inherent outcome of having a conversation system. Of
course, to prove this I'd have to write a difficult-yet-playable large
conversation game. Oh well.
ES
Lucian P. Smith
: Now, (d) -- that is, a complete, well-organized database allowing you
: to review verbatim everything you've been told thus far in the game --
: may not be possible to retrofit as such, despite Kevin Forchione's
: optimism. I can think of ways to program it; I can't, given the way
: conversation is generated, think of a very good way that wouldn't
: involve caching a copy of the actual output as it's printed to the
: screen.
<and later>
: (Another idea I considered, then tossed out, is using one of the nifty
: libraries that would incorporate an in-game notepad object on which
: your character could take notes.
I think this is your answer--cache the last statement and the last
statement only, and when the player types '>LOG CONVERSATION "What Evaine
thinks of Malik"', record it to a notebook (or just '>LOG', of course).
That being said, I personally never had a problem remembering the salient
points of my various conversations, though this is possibly because I
replayed the game a bunch. Then again again, it semed to me the original
poster was musing more on potential games that might be played with this
system, not how to improve CoS directly, I think. In other words, CoS is
perfectly playable as is, but with a different conversation system,
different types of games could use the same basic mechanisms.
-Lucian
Daniel Barkalow
> Daniel Barkalow <iabe...@iabervon.org> wrote in message news:<Pine.LNX.4.21.030513...@iabervon.org>...
> > On Tue, 13 May 2003, Gunther Schmidl wrote:
> >
> > > Daniel Barkalow wrote:
> > > > The first thing is that, after I say something, I can't get that
> > > > response again.
> > >
> > > ...unless you check in the terp scrollback or have a SCRIPT running.
> >
> > Not very helpful if you save and stop playing for a month, which I've done
> > with other games in the past.
> >
> > > > The next thing is that, when I see an option, I may think it's
> > > > something I'll want to say eventually, but not right away.
> > >
> > > ...the game can't be made unwinnable, so you can say whatever you want
> > > whenever you want.
> >
> > The real problem is when you haven't really excluded a particular option,
> > but don't know how to find it again. There are some options which you only
> > get for two turns after an event (because they're contextual responses to
> > the event), and if you want to use these options, you have to do so at
> > once. But you might then change the topic, and there might be another
> > option you'd like to say eventually, but it doesn't seem to be on a topic
> > you can identify.
>
> Eh, well, wandering off topic is part of the game, too. But, okay,
> you don't like this.
I like wandering off topic, I'd just like the ability to play a character
who can remember what they'd been talking about better than I can.
> For release 3, which I hope to upload in the next week or so, I have
> added
>
> a) a user option to turn off the automatic speaking of a sole
> remaining menu item, so that if you wish you're guaranteed to see what
> you are about to say before you say it in all cases.
Thanks.
> b) a verb that will allow you to see what already-explored topics
> currently have active conversation items in them. (It will not mention
> viable conversation topics if you have not yet discussed them in the
> game.) I am frankly not crazy about this, since it seems to me to
> play up the gamey fakeness of the conversations, and play down the
> mimesis. But if you don't want to use it, you don't have to; so you
> can still experience the thing as I originally intended, and all the
> people who disagree can have it their way as well. [No, I'm not
> really sure why I see this as inherently different from letting the
> player take inventory. Perhaps because inventory is an old and
> accepted convention.]
Is this a different verb from "TOPICS" or an extension of the same verb?
> c) a verb to remind you of what you've talked about in this particular
> conversation. Probably less useful or interesting, but still, there
> if you want it.
Do you get a chance to invoke it right after the end of the
conversation? This would be nice.
> Now, (d) -- that is, a complete, well-organized database allowing you
> to review verbatim everything you've been told thus far in the game --
> may not be possible to retrofit as such, despite Kevin Forchione's
> optimism. I can think of ways to program it; I can't, given the way
> conversation is generated, think of a very good way that wouldn't
> involve caching a copy of the actual output as it's printed to the
> screen. A lot of the conversation is affected by in-game variables:
> the mood of the NPC you're talking to, how many times you've discussed
> this topic with someone else before, specific game states that might
> change before you got around to executing the recap, and so on.
> *Some* of the conversation is also mildly randomized to ensure that
> that phrasing of certain things doesn't get repetitive. So it's not
> as though there's a
>
> say_this [; "blah!"; ],
>
> property that I can simply call a second time to show the exact same
> text again.
Nifty; I hadn't realized that you had conversational snippets that were
that flexible. I'd assumed that each conversational turn was a single
chunk of text. Having played the game through only once so far, I've only
seen each response one way.
> I do appreciate the undesirability of note-taking as part of the IF
> process; I tried, with the THINK ABOUT verb, to make your thoughts
> about a few really critical topics reflect your discoveries, as a kind
> of summary of what you've learned.
I didn't try that verb much; I'd just assumed from the description that it
only provided information from before the story.
> I suppose I could expand that
> system somewhat if it would be a useful thing -- so that THINK ABOUT
> FOO would produce "you've discussed this with x, who said a, and with
> y, who said b". The downside of *this* alteration is that it would
> require a lot of careful hand editing to prepare; another couple of
> weeks or even months, maybe, before I could get it installed. But
> probably it would create less drain on the system than a complete and
> full conversation-recap ability. Then again, maybe it wouldn't be
> satisfactory if you couldn't remember the exact words.
I think this is actually the ideal solution, and you wouldn't really need
to include all the details. Just "x said this. y said that. z wouldn't
talk about it"; that's about the level of detail I remember about past
conversations in real life. I remember thinking, "Somebody said I should
go somewhere if I wanted to find this person. Where did they say to
go? Was it someone I believe?" Like as not, this information was actually
in the "THINK ABOUT this person", but I didn't realize that was where I
could find the info.
The only thing I would add would be a conversation option which appears at
the end of a topic which asks the NPC to repeat themselves. I.e., "1: What
kind of cheese did you say you liked?" This one wouldn't do away, and the
response would be something like "I said I liked smoked gouda", which you
can repeat without sounding odd. Maybe if you keep using it, the NPC gets
annoyed at you, though.
> My original theory about this, and the reason I assumed that recap
> wouldn't be necessary in this game, is that most of the information
> you gather, you gather gradually and through repetition. There are
> almost always multiple sources of information on a given topic; it is
> extremely rare for anyone to tell you anything that you have to
> remember exactly, and those few things are accounted for by the THINK
> ABOUT system. So I suppose I expected the player not to ask the same
> person the same question over and over, but to ask *different* people
> the same question, thus reinforcing the factual content while
> developing a sense of the different personae and attitudes involved.
I noticed that important details which you had to remember exactly were
written down somewhere you could go back to (for example, information in
books). Also, individual opinions weren't all that important. I sort of
felt these aspects were a constraint of the system; they could just as
well be the basis for the optimization of the system.
> Anyway, I've been thinking about how to correct the problems you cite,
> and nothing obvious comes to mind on this particular score. I'd
> welcome any suggestions. Making the underlying system practical for
> general use in other games is not possible, but I would like to make
> *this* game as playable as possible given the time investment it
> represents.
I think the only things that didn't work for me in City of Secrets were
accidentally saying something I didn't want to and the passage of time
while trying to find a useful topic from the topics list. And these didn't
hinder playing the game, but did somewhat interfere with trying to stay in
character; when my character blurted out something I wanted to keep
secret, nothing bad happened.
Can I request one more feature? I'd like to have the name of the current
topic visible somewhere, and note the topics of any conversation options
that aren't from the current topic but are from another topic (if this
happens at all).
We're not getting a library of this system any time soon? :( Alas...
> --
>
> But I
> wrote it assuming that the player would be playing it over the course
> of one or two sessions (or four or five, but closely spaced); and that
> assumption did have a large effect on how I wrote it. In my
> experience it's the more puzzle-oriented games that fare best with a
> long hiatus of play, where stepping back for a moment actually makes
> it more likely that you'll be able to figure out what to do next.
> Here (I hope) that is less of an issue.
Certainly; what I wanted to bring up was the set of changes that would
need to be made to the system to allow puzzle-based games to be written
with it, because there's no reason couldn't have a puzzle-heavy
conversational game with suitable support. My point in starting this
thread was to discuss how other games that used a similar interface would
have to modify that interface for less forgiving plots, in hopes of
establishing suitable conventions.
> Finally, the easyness of the game was the result of commission
> constraints from the outset, and not really (I think, anyway) a
> necessary and inherent outcome of having a conversation system. Of
> course, to prove this I'd have to write a difficult-yet-playable large
> conversation game. Oh well.
I don't think I really mean "difficult" so much as "cruel" (in the sense
that "So Far" is cruel). If the game cut off options left and right as you
chose different things to say, I think the engine would have to be
significantly different to make it useable.
ems...@mindspring.com
> > b) a verb that will allow you to see what already-explored topics
> > currently have active conversation items in them. (It will not mention
> > viable conversation topics if you have not yet discussed them in the
> > game.) I am frankly not crazy about this, since it seems to me to
> > play up the gamey fakeness of the conversations, and play down the
> > mimesis. But if you don't want to use it, you don't have to; so you
> > can still experience the thing as I originally intended, and all the
> > people who disagree can have it their way as well. [No, I'm not
> > really sure why I see this as inherently different from letting the
> > player take inventory. Perhaps because inventory is an old and
> > accepted convention.]
>
> Is this a different verb from "TOPICS" or an extension of the same verb?
It's different, though I suppose I could make TOPICS contextual
instead. Hrm.
> > I suppose I could expand that
> > system somewhat if it would be a useful thing -- so that THINK ABOUT
> > FOO would produce "you've discussed this with x, who said a, and with
> > y, who said b"....
<snip>
> I think this is actually the ideal solution, and you wouldn't really need
> to include all the details. Just "x said this. y said that. z wouldn't
> talk about it"; that's about the level of detail I remember about past
> conversations in real life. I remember thinking, "Somebody said I should
> go somewhere if I wanted to find this person. Where did they say to
> go? Was it someone I believe?" Like as not, this information was actually
> in the "THINK ABOUT this person", but I didn't realize that was where I
> could find the info.
Well, it could probably stand to be more flexible/deep if I'm going to
rely on that. I'll have a look at it and figure out how much real
work is involved in strengthening the implementation here.
> The only thing I would add would be a conversation option which appears at
> the end of a topic which asks the NPC to repeat themselves. I.e., "1: What
> kind of cheese did you say you liked?" This one wouldn't do away, and the
> response would be something like "I said I liked smoked gouda", which you
> can repeat without sounding odd. Maybe if you keep using it, the NPC gets
> annoyed at you, though.
Hrm. Not useful in all cases. I'll consider.
> > My original theory about this, and the reason I assumed that recap
> > wouldn't be necessary in this game, is that most of the information
> > you gather, you gather gradually and through repetition. There are
> > almost always multiple sources of information on a given topic; it is
> > extremely rare for anyone to tell you anything that you have to
> > remember exactly, and those few things are accounted for by the THINK
> > ABOUT system. So I suppose I expected the player not to ask the same
> > person the same question over and over, but to ask *different* people
> > the same question, thus reinforcing the factual content while
> > developing a sense of the different personae and attitudes involved.
>
> I noticed that important details which you had to remember exactly were
> written down somewhere you could go back to (for example, information in
> books). Also, individual opinions weren't all that important. I sort of
> felt these aspects were a constraint of the system; they could just as
> well be the basis for the optimization of the system.
My general theory about designing research/knowledge-based puzzles is
that they *should* be like this; it's the equivalent of having
multiple solutions to a physical object puzzle. At the same time, the
repetition is not purely pointless, because the challenge is then to
figure out whether you find someone's evidence reliable, and what your
overall sense of the situation is.
> Can I request one more feature? I'd like to have the name of the current
> topic visible somewhere, and note the topics of any conversation options
> that aren't from the current topic but are from another topic (if this
> happens at all).
Originally-- well, no. At one point, and this game has gone through
*many* points -- this was an included feature, but it turned out to be
annoying occasionally. (There was a little thing in the header of the
topic where it said, "Say to <Mr. Foo> about <topic bar>.) There are
a few topic classifications that don't really lend themselves well to
this -- for internal reasons, "saying yes" is a topic, for instance.
But even when you filter that sort of thing out, it was just difficult
to make sure that it always looked perfectly sensible.
Maybe I should have another crack at it.
> We're not getting a library of this system any time soon? :( Alas...
Well, er. I mean, I could publish a library, but my experience with
really complicated libraries is that no one but the author ever uses
them. That combined with the fact that it takes a long time for me to
write tutorials is the reason I've never released a conversation
library: I don't see the point of wasting my time on polishing and
presenting something that people aren't going to use. Someone else
requested permission to look through the Pytho source and library-ize
it, but it's been well over a year now since that happened, and I'm
not sure how likely it is to be forthcoming.
There are already some libraries in various languages that will do
topic-menu management. They seem purer than my accretively-designed
stuff, and they don't involve the numerous 'features' that I decided
to add somewhere along the line to achieve some specific and highly
arcane goal. It's a nightmare. Really.
> Certainly; what I wanted to bring up was the set of changes that would
> need to be made to the system to allow puzzle-based games to be written
> with it, because there's no reason couldn't have a puzzle-heavy
> conversational game with suitable support. My point in starting this
> thread was to discuss how other games that used a similar interface would
> have to modify that interface for less forgiving plots, in hopes of
> establishing suitable conventions.
This raises some interesting questions. When I've mentally sketched
out more difficult games based on a conversation system, the
difficulty mostly involves trying to manipulate people to different
things -- intrigue-based, rather than knowledge-based. I have a bunch
of defunct WIP starts that do assorted takes on this idea: that you
have to go around and get NPCs on your side, without letting them
catch you in any outright lies, for instance. Or you have to get
enough of a sense of the relationships between people to be able to
use them against each other. (I never said this involved a *moral*
protagonist.) But the challenge wasn't so much intended to be in the
figuring out; it was supposed to be in the realizing where a given
piece of information could be effectively employed to leverage an
interesting result.
> > Finally, the easyness of the game was the result of commission
> > constraints from the outset, and not really (I think, anyway) a
> > necessary and inherent outcome of having a conversation system. Of
> > course, to prove this I'd have to write a difficult-yet-playable large
> > conversation game. Oh well.
>
> I don't think I really mean "difficult" so much as "cruel" (in the sense
> that "So Far" is cruel). If the game cut off options left and right as you
> chose different things to say, I think the engine would have to be
> significantly different to make it useable.
Hrm. Yes, possibly. Or possibly, a la Varicella, it would just have
to be short enough that the expectation was for the player to replay.
-- Emily
Miguel
issues, gender identity, gender differences...whatever you want to
call it.
Specifically, I was reading in a book by linguist Deborah Tannen that
many women can remember a lot of details about who said what to whom
(i.e. can remember the intricacies of the interrelationships between
people) because they have been socialized to be able to do so, whereas
many men have trouble remembering same, are not interested very much
in talking about relationships, and enjoy talking about _information_.
Without making too much of it, this dichotomy seems to be paralleled
in this very thread: Daniel's interested in making the conversation
interface more acceptable for puzzle-oriented games, and
puzzle-oriented games in themselves reflect an emphasis on information
over interrelationship. By that I mean, a puzzle-oriented game often
involves a lone protagonist wandering through an environment largely
devoid of other people (usually an environment depopulated through
some plot device: in Glowgrass, nucleur holocaust; in House of the
Midnight Sun, vampirism and moral decay; in Curses, the flight of
close relatives to a vacation spot--hope I got that one right), or, as
Daniel pointed out in his original post, if there are other people
available for interaction, they exist largely as information-givers.
The emphasis in puzzle-fest games is not on relationships but on
information.
With this idea in mind, of the possibility of one gender being more
skilled at and focused on (because more practised at) one aspect of
conversation, and another gender being more skilled at, focused on,
and practised at another aspect of conversation, and how this
difference of emphasis can also be reflected in a difference of
emphasis in the structure of text adventures, I think it's interesting
and intriguing that a male player wants more features in the
conversation system that highlight the information-content of the
conversations, and that a female writer would write a game in the
first place that is strongly based on conversation and
character-to-character interaction as opposed to the traditional(ly
male) puzzle model!
Cedric Knight
[snip]
>> We're not getting a library of this system any time soon? :( Alas...
>
> Well, er. I mean, I could publish a library, but my experience with
> really complicated libraries is that no one but the author ever uses
> them. That combined with the fact that it takes a long time for me to
> write tutorials is the reason I've never released a conversation
> library: I don't see the point of wasting my time on polishing and
> presenting something that people aren't going to use. Someone else
> requested permission to look through the Pytho source and library-ize
> it, but it's been well over a year now since that happened, and I'm
> not sure how likely it is to be forthcoming.
>
> There are already some libraries in various languages that will do
> topic-menu management. They seem purer than my accretively-designed
> stuff, and they don't involve the numerous 'features' that I decided
> to add somewhere along the line to achieve some specific and highly
> arcane goal. It's a nightmare. Really.
Well, how about just publishing the main relevant routines and some
sample topics? I think there is a demand - someone here was asking
about it a few weeks ago. IMHO conversation menus may be one complex
bit of behaviour where authors don't like reinventing the wheel. Plus,
all the little frills are the bits that take development time - authors
won't use them if they don't need them.
Just my opinion.
CK
Daniel Barkalow
> Daniel Barkalow <iabe...@iabervon.org> wrote in message news:<Pine.LNX.4.21.030515...@iabervon.org>...
>
> > The only thing I would add would be a conversation option which appears at
> > the end of a topic which asks the NPC to repeat themselves. I.e., "1: What
> > kind of cheese did you say you liked?" This one wouldn't do away, and the
> > response would be something like "I said I liked smoked gouda", which you
> > can repeat without sounding odd. Maybe if you keep using it, the NPC gets
> > annoyed at you, though.
>
> Hrm. Not useful in all cases. I'll consider.
I think it's useful in the situations which are frustrating in an
unrealistic way: where the NPC is willing to help and knows something, but
won't tell you because you've already asked. It also means that NPCs won't
entirely run out of things to say.
> > > My original theory about this, and the reason I assumed that recap
> > > wouldn't be necessary in this game, is that most of the information
> > > you gather, you gather gradually and through repetition. There are
> > > almost always multiple sources of information on a given topic; it is
> > > extremely rare for anyone to tell you anything that you have to
> > > remember exactly, and those few things are accounted for by the THINK
> > > ABOUT system. So I suppose I expected the player not to ask the same
> > > person the same question over and over, but to ask *different* people
> > > the same question, thus reinforcing the factual content while
> > > developing a sense of the different personae and attitudes involved.
> >
> > I noticed that important details which you had to remember exactly were
> > written down somewhere you could go back to (for example, information in
> > books). Also, individual opinions weren't all that important. I sort of
> > felt these aspects were a constraint of the system; they could just as
> > well be the basis for the optimization of the system.
>
> My general theory about designing research/knowledge-based puzzles is
> that they *should* be like this; it's the equivalent of having
> multiple solutions to a physical object puzzle. At the same time, the
> repetition is not purely pointless, because the challenge is then to
> figure out whether you find someone's evidence reliable, and what your
> overall sense of the situation is.
I think that it makes sense to have some puzzles that can only be solved
in one way, so long as it makes sense for the puzzle. And having multiple
sources which you may or may not trust is only significant when they
disagree, in which case you're down to fewer NPCs who say a particular
thing (and, if you only really trust one NPC, it's particularly important
to be able to review the information, including what you heard before you
came to trust them).
> > Can I request one more feature? I'd like to have the name of the current
> > topic visible somewhere, and note the topics of any conversation options
> > that aren't from the current topic but are from another topic (if this
> > happens at all).
>
> Originally-- well, no. At one point, and this game has gone through
> *many* points -- this was an included feature, but it turned out to be
> annoying occasionally. (There was a little thing in the header of the
> topic where it said, "Say to <Mr. Foo> about <topic bar>.) There are
> a few topic classifications that don't really lend themselves well to
> this -- for internal reasons, "saying yes" is a topic, for instance.
> But even when you filter that sort of thing out, it was just difficult
> to make sure that it always looked perfectly sensible.
>
> Maybe I should have another crack at it.
I think, for all of the non-internal ones ("saying yes" doesn't appear in
TOPICS and I don't think you can switch to it), just putting the topic in
parentheses at the end of the line would be sufficient. It's
meta-information anyway, so it just has to be consistent.
> > We're not getting a library of this system any time soon? :( Alas...
>
> Well, er. I mean, I could publish a library, but my experience with
> really complicated libraries is that no one but the author ever uses
> them.
That's what I would think, but you actually used my library in
Savior-Faire. Of course, "no one but the author and Emily Short ever
used..." doesn't change things much in this case. But the Inform library
is also complicated, and people obviously use that. I suspect that people
use libraries for things which they expect to be really hard. But I think
the reason this would make an interesting library is that it could form
the basis for interface conventions.
> That combined with the fact that it takes a long time for me to
> write tutorials is the reason I've never released a conversation
> library: I don't see the point of wasting my time on polishing and
> presenting something that people aren't going to use. Someone else
> requested permission to look through the Pytho source and library-ize
> it, but it's been well over a year now since that happened, and I'm
> not sure how likely it is to be forthcoming.
>
> There are already some libraries in various languages that will do
> topic-menu management. They seem purer than my accretively-designed
> stuff, and they don't involve the numerous 'features' that I decided
> to add somewhere along the line to achieve some specific and highly
> arcane goal. It's a nightmare. Really.
Possibly there ought to be a re-implementation of the idea. But having a
library that was useable for one game by one author, at least, would give
a good idea of how the library could be written cleanly. I agree with
Cedric that an unpolished version which people could refine would be
worthwhile; for that matter, having something that multiple people refine
might lead to a more widely useable result.
> > Certainly; what I wanted to bring up was the set of changes that would
> > need to be made to the system to allow puzzle-based games to be written
> > with it, because there's no reason couldn't have a puzzle-heavy
> > conversational game with suitable support. My point in starting this
> > thread was to discuss how other games that used a similar interface would
> > have to modify that interface for less forgiving plots, in hopes of
> > establishing suitable conventions.
>
> This raises some interesting questions. When I've mentally sketched
> out more difficult games based on a conversation system, the
> difficulty mostly involves trying to manipulate people to different
> things -- intrigue-based, rather than knowledge-based. I have a bunch
> of defunct WIP starts that do assorted takes on this idea: that you
> have to go around and get NPCs on your side, without letting them
> catch you in any outright lies, for instance. Or you have to get
> enough of a sense of the relationships between people to be able to
> use them against each other. (I never said this involved a *moral*
> protagonist.) But the challenge wasn't so much intended to be in the
> figuring out; it was supposed to be in the realizing where a given
> piece of information could be effectively employed to leverage an
> interesting result.
I thought a lot about writing such games at one point quite some time
ago. Then I determined that I had no idea how to manage such a project,
and also lacked skill at writing dialogue and at figuring out how people
behave. But I think it would be a really interesting sort of game if
someone managed to pull it off.
Of course, you'd still really want to be able to look up what interactions
you've had with each character, and the game should probably tell you
(unless the author wanted the player to take a lot of notes...)
ems...@mindspring.com
> I think that it makes sense to have some puzzles that can only be solved
> in one way, so long as it makes sense for the puzzle. And having multiple
> sources which you may or may not trust is only significant when they
> disagree, in which case you're down to fewer NPCs who say a particular
> thing (and, if you only really trust one NPC, it's particularly important
> to be able to review the information, including what you heard before you
> came to trust them).
Mm, I suppose. Though here (as in Pytho's Mask, actually) the
different versions you're getting aren't completely and radically
different; they're opinionated spins on the same thing, with the basic
factual information remaining more or less constant, and few outright
lies occurring. (There are some, of course, but once you realize it
it is fairly clear which they are.)
> > > Can I request one more feature? I'd like to have the name of the current
> > > topic visible somewhere, and note the topics of any conversation options
> > > that aren't from the current topic but are from another topic (if this
> > > happens at all).
> >
> > Originally-- well, no. At one point, and this game has gone through
> > *many* points -- this was an included feature, but it turned out to be
> > annoying occasionally. (There was a little thing in the header of the
> > topic where it said, "Say to <Mr. Foo> about <topic bar>.) There are
> > a few topic classifications that don't really lend themselves well to
> > this -- for internal reasons, "saying yes" is a topic, for instance.
> > But even when you filter that sort of thing out, it was just difficult
> > to make sure that it always looked perfectly sensible.
> >
> > Maybe I should have another crack at it.
>
> I think, for all of the non-internal ones ("saying yes" doesn't appear in
> TOPICS and I don't think you can switch to it),
(You can switch to it, if you >SAY YES or >YES or >Y or a bunch of
other synonyms; it just isn't very useful unless you've just been
asked a yes/no question.)
> just putting the topic in
> parentheses at the end of the line would be sufficient. It's
> meta-information anyway, so it just has to be consistent.
Hrm. I suppose.
> > > We're not getting a library of this system any time soon? :( Alas...
> >
> > Well, er. I mean, I could publish a library, but my experience with
> > really complicated libraries is that no one but the author ever uses
> > them.
>
> That's what I would think, but you actually used my library in
> Savior-Faire.
With S-F I made a deliberate effort to find and use library extensions
that seemed like they might help. I'm not sure how much other people
do this.
<re. releasing conversation libraries>
> I agree with
> Cedric that an unpolished version which people could refine would be
> worthwhile; for that matter, having something that multiple people refine
> might lead to a more widely useable result.
Even just extracting the relevant code and writing some examples would
be a not-entirely-trivial task; the conversation code makes certain
assumptions about the UI code and the presence of the scene moderator,
so it's vitally connected to a couple of my other libraries. Cleaning
it up so that it didn't rely on those things would take a while.
Also, on those occasions when I have sent copies of code (usually
Pytho code, which is much simpler than that used for CoS), people have
responded by saying, "Oh wow, okay, this is way too difficult for me
to use," and have gone on to do something entirely different.
Either way, this experiment has more or less proven to my satisfaction
that this is not a viable model for future games. Kathleen Fischer's
"Redemption" does something quite clever that gets rid of the overt
menus, which I like a lot -- I agree with mjr's comments about why
it's desirable not to use menus if they're at all avoidable. But it
would not be easy to retrofit that to my system. More to the point,
though, this system requires an unacceptable amount of development
time in order to make a single game viable.
-- Emily
ems...@mindspring.com
> I played City of Secrets through once this past weekend, and found it very
> interesting (I'm not yet sure exactly how interesting; I need to play
> through it by a different path still). Being a programmer at heart,
> however, I want to review not the game but the engine.
At the risk of resurrecting a dead thread: I recently started Stark
Spring's "Words of Power". I'm not nearly done with it yet, but it
seems to me that it might provide another data point in this
discussion. It does several of the things you suggest City of Secrets
needs: major questions can be reasked, and there's a list of
conversation topics that you can reasonably switch to, in the same
menu with the actual lines of dialogue. I'd be curious what other
people thought of it.
-- Emily
Lucian P. Smith
: At the risk of resurrecting a dead thread: I recently started Stark
: Spring's "Words of Power". I'm not nearly done with it yet, but it
: seems to me that it might provide another data point in this
: discussion.
For those curious (as I was), this game can be found at:
http://mirror.ifarchive.org/indexes/if-archiveXgamesXglulx.html
under 'words.zip'.
-Lucian
Stark Springs
> I'd be curious what other people thought of it.
>
> -- Emily
So would I :)
Stark
Daniel Barkalow
Now that I've tried it, I like it. I think a few of the topics should have
started with different names and then changes based on things you then
discovered. I think some items might have been made available prematurely
(I'm not sure that the engine can test for player knowledge in addition to
conversational state), but I liked the interface. Of course, it didn't
have any conversation flow items so far as I could tell, which makes the
interface simpler but the conversation more stilted.
I suspect that your authoring tools allow for sanely writing more fluid
conversations. As the author, did you notice things which would be
problematic for a game like City of Secrets with that interface?
I think it ought to have a topic command for introducing topics which the
player realizes to be important out of a flash of insight, rather than out
of the conversation.
Brian Slesinsky
conversation, I stopped thinking of commands in the form <verb> <noun>
and just thought in terms of keywords, as if using Google. To use a
made-up example, typing "t lamp" started to mean just "topic lamp"
rather than (more properly) "tell the man about the lamp". Others
have mentioned the fading distinction between "ask" and "tell".
Sometimes I tried to remember to use the correct verb, but it didn't
seem any more natural than typing "go north" instead of "n".
Also, the conversational interface started out as modal (you're
talking to only one person at a time), but there are parts of the
story where multiple people are around at once, and then topic choices
start appearing for talking to another person in the room. If you're
speaking with the lady in red, you might have choices such as:
1) "Ignore him."
2) [To man in black] "Excuse us, we're busy."
So what happens if we take this interface as far as it could go?
Suppose we forget about having a special mode for conversations and
unify conversations and actions into the same interface? Forget
grammar. Type one or more words in any order, and the game gives you
a list of choices ranked from most to least obvious:
> lamp
1) Light the lamp.
2) Set the lamp on the ground.
3) Rub the lamp.
4) [To gnome] "Where do you suppose this lamp came from?"
5) [To gnome] "How much would you give me for this shiny new lamp?"
6) [Show more choices]
The effect would be something like using Google. Searching on a
common word would result in a list of popular (and possibly boring)
choices, but you could also type multiple words to bring less common
choices to the top of the list. So, "rub lamp" would give you the
expected first choice. But so would "lamp rub".
This might be a more intuitive and forgiving interface for beginners,
since there are many more people who search the web than who use
command-line interfaces.
Puzzle design would be quite a bit different as well; no more guess
the verb. But there are a lot of word combinations out there, and I
think clever authors would still find ways to hide things. Just as
the more difficult web searches are partly a matter of discovering the
correct keyword.
Only one minor detail: how to implement such a thing?
- Brian
ems...@mindspring.com
> On 29 May 2003, ems...@mindspring.com wrote:
> > I recently started Stark
> > Spring's "Words of Power". I'm not nearly done with it yet, but it
> > seems to me that it might provide another data point in this
> > discussion. It does several of the things you suggest City of Secrets
> > needs: major questions can be reasked, and there's a list of
> > conversation topics that you can reasonably switch to, in the same
> > menu with the actual lines of dialogue. I'd be curious what other
> > people thought of it.
>
> Now that I've tried it, I like it. I think a few of the topics should have
> started with different names and then changes based on things you then
> discovered.
Possibly, though to be fair the presence of the extra-game materials
makes it even more difficult than usual to figure out what the player
has and hasn't learned yet.
> Of course, it didn't
> have any conversation flow items so far as I could tell, which makes the
> interface simpler but the conversation more stilted.
>
> I suspect that your authoring tools allow for sanely writing more fluid
> conversations. As the author, did you notice things which would be
> problematic for a game like City of Secrets with that interface?
Well, it seems to me that it's largely a matter of scale. Characters
in City of Secrets, particularly in the midgame, tend to have active
things to say about 80 or 90 topics when you first meet them (out of a
possible 200-odd list of topics, but many topics don't mean much to
most of the characters). So it doesn't really work to have an 80-item
menu in the sidebar there.
What might make (somewhat) more sense would be to list only the topics
that are related to where the player is now. (So if you're talking to
the pirate about treasure, it might list statements about the
treasure, and topics for the treasure map and the sunken Spanish
galleon, but not a topic for the pirate's Aunt Clorinda.) The
advantage would be that the obvious leads would be, er, obvious;
less-obvious ones would be accessible via a topic command, maybe. But
it would discourage segue-less conversation unless the player actually
wanted to jump streams. This seems perhaps advantageous. Hmm.
I'm not sure how well my current system could be fitted to handle
that. It would be easy enough to find the topics that have followups
to the last statement; beyond that, topics fit in a tree, which
represents how they're related to each other, sort of like this:
Topic family;
Topic parents;
Topic Mom;
Topic Dad;
Topic siblings;
Topic brother;
Topic sister;
So I guess one approach might be to show the parents, children, and
siblings of the current topic in the tree. But I'm concerned that
this would expose the structure of the conversation system a bit too
mechanically.
As for the question of "flow", I have no idea how this system works
under the hood, so it's hard for me to say what it would and would not
be able to do in that regard -- but my guess is that it was an
authorial/writing choice, rather than a programming choice, not to
include more conversation items that depend on others. In my system,
conversation objects have (among other things) a prereq routine that
is called to ask the statement whether it is ready to be said -- which
means that it can be dependent on pretty much any aspect of the game
state. There are also shortcuts for "you can say this only
immediately after statement y" and so on. It's not really very
difficult, and I'd be surprised if Springs' system didn't do something
similar, because he's clearly making statements available/unavailable
at specific junctures.
Where the difficulty shows up is in the writing of the bazillion
statements, because each time you write a statement that's good only
for one turn after some other statement, you decrease the likelihood
that the player will ever see that fork. If you have multiple
dependencies, that likelihood becomes more and more attenuated. So
you have to write more and more material in order to have "enough"
available at any one time.
> I think it ought to have a topic command for introducing topics which the
> player realizes to be important out of a flash of insight, rather than out
> of the conversation.
Yes-- this seems fairly important if you're doing anything
puzzle-based with the conversation. In Words of Power I wasn't really
bothered by it, since it seemed that conversation existed mostly as
exposition (though spun according to the prejudices and interests of
the person speaking, yes); and it was no more or less efficient than
having a book with chapters on all these topics. (More interesting,
but the puzzliness or non-puzzliness was about the same, I'd say.)
Ultimately, though, I think one wants to be careful about how much to
do puzzles via conversation. It seems that there are basically two
kinds of conversational puzzle you can do:
1) Interlocutor knows something. You must ask him about the right
thing in order to find it out. This requires you to look around the
environment and figure out which topic to raise with him. Having all
available topics listed would ruin this kind of puzzle.
The thing about this is that it's not really a puzzle about the
conversation; it's a puzzle about intuiting what you ought to ask, and
the clues to this could be blatant or subtle. Once you've asked the
right question, you've already solved the knowledge puzzle that led up
to it. And you don't (I assume) stand there staring at someone
thinking, "if only I knew the right topic to ask him about"; instead
you explore other things, and only realize when you've found the topic
that it's likely to be a fruitful source of conversation with
character x. At least, that was my experience with the conversation-
and research-based puzzles in Anchorhead.
2) Interlocutor is touchy/grumpy/whatever, and will only react well to
you if coddled into a state of cooperativeness. This kind of puzzle
can (I think) be either trivial or unfair: in the trivial case, the
mood is changed easily and as a result of an obvious behavior, in
which case, it's not a very interesting puzzle. (You need to make
someone mad, so you pick an insulting statement out of >TOPIC MOTHER,
and voila.)
But if it is *not* changed as a result of obvious behavior, and
instead requires a complex chain of actions on the player's part, then
it seems very hard to write the puzzle in such a way that it's
comprehensible. A good complex puzzle needs to let the player replay
and replay, always getting precise feedback about what's going wrong;
an NPC conversation that happens the same way over and over is
anti-mimetic; so you're stuck with a fundamental problem here.
I think Varicella played with the edges of this in interesting ways;
most of the other examples I can think of are basically
non-conversational in content (the old >GIVE BONE TO DOG routine), and
there again the real puzzle is usually more the finding of the bone
than the giving of it.
I haven't actually thought about this last issue in these terms until
tonight, so I apologize if this seems a bit unformed.
-- Emily
Stark Springs
>
> Now that I've tried it, I like it. I think a few of the topics should have
> started with different names and then changes based on things you then
> discovered. I think some items might have been made available prematurely
> (I'm not sure that the engine can test for player knowledge in addition to
> conversational state), but I liked the interface. Of course, it didn't
> have any conversation flow items so far as I could tell, which makes the
> interface simpler but the conversation more stilted.
>
although there might be a few bugs in there. An example is the "white
arrow" topic which
only appears in particular circumstances. Also, the game assumes that
the character has read Baxter's book, which the player might not have
patience to do :)
As for conversation flow, designing was the major problem. Coding was
fairly
trivial once the engine was in place. The ration of design vs. coding
was something like 10:1 and the conversations are far from complex.
> I think it ought to have a topic command for introducing topics which the
> player realizes to be important out of a flash of insight, rather than out
> of the conversation.
The next game will support the topic command (as well as ask and
tell). Already explored topics will remain visible (unless exhausted)
so you can return to them easily and I'm thinking of introducing a
meta-command that toggles the automatic display of topics the
character knows about, for players like myself who don't like to guess
the topic.
Of course, it kind of excludes conversation based puzzles, which was
not a problem in Words of Power, but it might be in other games. Also,
as Emily mentioned, when you have a hundred topics for a character
this interface will become unuseable.
Changing the topic name is a neat idea, btw, and not difficult to
implement, at first glance. Thank you :)
Stark
Stark Springs
>
> As for the question of "flow", I have no idea how this system works
> under the hood, so it's hard for me to say what it would and would not
> be able to do in that regard -- but my guess is that it was an
> authorial/writing choice, rather than a programming choice, not to
> include more conversation items that depend on others. In my system,
> conversation objects have (among other things) a prereq routine that
> is called to ask the statement whether it is ready to be said -- which
> means that it can be dependent on pretty much any aspect of the game
> state. There are also shortcuts for "you can say this only
> immediately after statement y" and so on. It's not really very
> difficult, and I'd be surprised if Springs' system didn't do something
> similar, because he's clearly making statements available/unavailable
> at specific junctures.
>
Each character has a list of topics and each topic has conversations
items (although an item can appear in more than one topic). Game
events (mostly conversation events, but also finding items or getting
to a particular location) change the status of conversation items (or
topics, for that matter), from disabled to enabled to ask again to
whatever.
If anybody is interested I can e-mail them the source code, although
I'm not sure how useful it will prove :)
>
> But if it is *not* changed as a result of obvious behavior, and
> instead requires a complex chain of actions on the player's part, then
> it seems very hard to write the puzzle in such a way that it's
> comprehensible. A good complex puzzle needs to let the player replay
> and replay, always getting precise feedback about what's going wrong;
> an NPC conversation that happens the same way over and over is
> anti-mimetic; so you're stuck with a fundamental problem here.
>
Hmm... maybe you can have the NPC reply in dozen different ways to the
question/statement, all of which essentialy convey the same
information without seeming repetitive. It happens in real life too --
I deal on a daily basis with people whose English is even worse than
mine, so they ask the same question again and again and I have to
rephrase the answer until I get my point across. I shudder when I
think of the amount of work this entails, though.
Stark
ems...@mindspring.com
> ems...@mindspring.com (ems...@mindspring.com) wrote in message news:<a69830de.03060...@posting.google.com>...
> items (although an item can appear in more than one topic). Game
> events (mostly conversation events, but also finding items or getting
> to a particular location) change the status of conversation items (or
> topics, for that matter), from disabled to enabled to ask again to
> whatever.
Aha hrm. Okay, this occurred to me as another possible way of doing
things. I think that with a really large number of conversation items
(or really complex criteria for whether they're available), this
becomes less workable. It may indeed make it harder to set up "allow
the player to say X only immediately after statement Y" types of
conditions, as well. Up to the author whether he wants to worry about
that, I suppose.
> > But if it is *not* changed as a result of obvious behavior, and
> > instead requires a complex chain of actions on the player's part, then
> > it seems very hard to write the puzzle in such a way that it's
> > comprehensible. A good complex puzzle needs to let the player replay
> > and replay, always getting precise feedback about what's going wrong;
> > an NPC conversation that happens the same way over and over is
> > anti-mimetic; so you're stuck with a fundamental problem here.
> >
> Hmm... maybe you can have the NPC reply in dozen different ways to the
> question/statement, all of which essentialy convey the same
> information without seeming repetitive.
Hmm. I guess what I had in mind was more what people call an 'emotion
maze' -- where you're trying to get the NPC to feel the correct
sequence of emotions in order to get to some ideal state -- and for
that it seems as though simply repeating exchanges isn't likely to be
convincing. ("Do you trust me now? No? How about now?")
-- Emily
Stark Springs
>
> Hmm. I guess what I had in mind was more what people call an 'emotion
> maze' -- where you're trying to get the NPC to feel the correct
> sequence of emotions in order to get to some ideal state -- and for
> that it seems as though simply repeating exchanges isn't likely to be
> convincing. ("Do you trust me now? No? How about now?")
>
I see. I have a similar problem right now, trying to instill a
particular emotion into a character. I keep a variable which is
increased by certain conversation items and certain actions
performed by the PC until it reaches a threshold after which the
NPC will do what the PC wants. I don't really like this solution
from a coding standpoint. If you have any ideas that you can share,
I'd really appreciate it :)
Thanks,
Stark
Jessica Knoch
>
> The engine is supposed to test for player knowledge and game context,
> although there might be a few bugs in there. An example is the "white
> arrow" topic which
> only appears in particular circumstances. Also, the game assumes that
> the character has read Baxter's book, which the player might not have
> patience to do :)
>
The following might be considered a mild spoiler.
.
The only quirk I noticed was this: I didn't explore every single topic
branch with the cat, and never heard from the cat that Yom was dead. Yet
when I'm talking with Baxter, I get the following as an option for something
to say: "But Yom is dead. The cat told me." Other than that, I didn't have a
single problem.
--
Jess K.
Coyote : Fear not, Homer. I am your spirit guide.
Homer : Hiya.
Coyote : There is a lesson you must learn.
Homer : If it's about laying off the insanity peppers, I'm way ahead of you.
Daniel Barkalow
> Daniel Barkalow <iabe...@iabervon.org> wrote in message news:<Pine.LNX.4.21.030606...@iabervon.org>...
> >
> > Now that I've tried it, I like it. I think a few of the topics should have
> > started with different names and then changes based on things you then
> > discovered. I think some items might have been made available prematurely
> > (I'm not sure that the engine can test for player knowledge in addition to
> > conversational state), but I liked the interface. Of course, it didn't
> > have any conversation flow items so far as I could tell, which makes the
> > interface simpler but the conversation more stilted.
> >
> The engine is supposed to test for player knowledge and game context,
> although there might be a few bugs in there. An example is the "white
> arrow" topic which only appears in particular circumstances.
I thought that might have been based on the conversation so far (unless I
missed where that showed up as a function of player knowledge).
> Also, the game assumes that the character has read Baxter's book, which
> the player might not have patience to do :)
I didn't have a suitable reader installed already, and finished the game
without getting stuck, so I didn't end up getting one.
> As for conversation flow, designing was the major problem. Coding was
> fairly trivial once the engine was in place. The ration of design
> vs. coding was something like 10:1 and the conversations are far from
> complex.
It seems to me that your conversations have the same "question and
answer" quality that Emily says her conversations had before she switched
to using a separate format for writing the conversations and converting it
to Inform with a perl script (according to the notes to the CD version of
City of Secrets, which she quoted here recently).
Actually, what I mean by "conversation flow items" was things like
"Yes" or "Thank you" or "Look out!", where the item is available not
because of what you know, but because of what just happened or what the
NPC just said. These increase the number of things you might not get to
say (so the game doesn't make you feel like you should try to see the full
range of conversational responses, which is unrealistic), but they don't
really fit into any topic, which might be a problem for your interface.
> > I think it ought to have a topic command for introducing topics which the
> > player realizes to be important out of a flash of insight, rather than out
> > of the conversation.
>
> The next game will support the topic command (as well as ask and
> tell). Already explored topics will remain visible (unless exhausted)
> so you can return to them easily and I'm thinking of introducing a
> meta-command that toggles the automatic display of topics the
> character knows about, for players like myself who don't like to guess
> the topic.
I think anything that somebody mentions should be fair game for a topic
that the player has to pick up on without prompting. Perhaps only things
that the NPC is willing to repeat. But I can imagine that:
"I got this ring when I beat John's sister in poker."
> topic sister
1. "Sister!? John doesn't have a sister!"
Where the player has to realize from the things people say that
"sister" might actually be relevant to the game (since, of course, the
player doesn't know anything about a sister). It's no different from
having items you have to examine in the room description. I've just been
reading "Freedom & Necessity" by Stevan Brust and Emma Bull, where much of
the plot revolves around people noticing what's suggested but not stated
explicitly in what other people say, which makes me think that this would
be a satisfying sort of puzzle.
I think that listing all the topics that are supposed to be obvious, but
also having other topics which require insight (and have a good set of
synonyms) would work well.
> Of course, it kind of excludes conversation based puzzles, which was
> not a problem in Words of Power, but it might be in other games. Also,
> as Emily mentioned, when you have a hundred topics for a character
> this interface will become unuseable.
Perhaps there could be nested topics? So you select "hotel service", and
then you get a list with "food" and "room", and so forth.
Stark Springs
>
> Perhaps there could be nested topics? So you select "hotel service", and
> then you get a list with "food" and "room", and so forth.
>
another "food" sub-topic for let's say "restaurant"? Where the
resolver takes into account the current topic? Interesting and I think
possible. Now I have to get back to the problem of designing a
realistic conversation :)
Stark
Edmund Kirwan
>
> The effect would be something like using Google. Searching on a
> common word would result in a list of popular (and possibly boring)
> choices, but you could also type multiple words to bring less common
> choices to the top of the list. So, "rub lamp" would give you the
> expected first choice. But so would "lamp rub".
>
That's a great idea! I was just in the middle coding a load of
questions: "Why did <thing> <verb> <thing>," and, "do you know where
<thing> <verb - past tense>," etc - which is sublimely tedious.
But just comparing keywords could be more effective.
I suppose it would be important for some command just to show you what
a person thinks you just said to him. For example, if you typed,
"brian take banana?" and intended to ask, "Did Brian take the banana?"
then you'd probably want to know if the character interpretted this
as, "Brian is to be ordered to take the banana."
.ed
Jon Ingold
> > common word would result in a list of popular (and possibly boring)
> > choices, but you could also type multiple words to bring less common
> > choices to the top of the list. So, "rub lamp" would give you the
> > expected first choice. But so would "lamp rub".
This is essentially how the conversation code in "insight" works; with some
allowances for articles and the like (but not too many) and a
slighty-too-generous reading of meaningless sentences.
Jon