Conversation in a character-oriented game
Skip the Penguin
Photopia. The plot was in embryo form long before I ever played the
game, it's just now coming out. It is conversation heavy, and I'd like
to ask RAIF's opinion as to which conversation system I should use:
(A) Inform standard
(B) The object-oriented version of Phototalk at the archive
(C) a menu-based thing, quite similar to the one on Titanic: Adventure
out of Time.
(D) telepathy (prob j/k, but who knows?)
(E) something else entirely
Also, which system should I use? I'm leaning toward RAIF POOL, but it
isn't ported to Linux yet. In fact, it doesn't seem to have been updated
this year, after last year's implementation of string theory. If I can't
use POOL, I'll have to pick Inform. Speaking of Inform, I've been unable
to get a response from CMP on the price of the Designer's Manual.
Skip the Crazy Penguin
--
Life found itself alive
And somehow knew its opposite was death.
We are ever being born, or dying
And the thrill of choosing is ours.
Only once, must we be born without our own consent.
Only once, must we die without our own permission.
- Calvin Miller, A Requiem For Love
Sent via Deja.com http://www.deja.com/
Before you buy.
Robb Sherwin
<skipro...@email.com> wrote:
>I'm writing a game which may be described as similar in theme to
>Photopia. The plot was in embryo form long before I ever played the
>game, it's just now coming out. It is conversation heavy, and I'd like
>to ask RAIF's opinion as to which conversation system I should use:
I used the Photopia-style menus for the game I entered into this
year's comp. I was really happy with it from a programmer's standpoint
and I felt it gave my main character a level of personality that he
would have otherwise not had.
It's a pretty simple matter to turn conversations "on" or "off" using
Adam's method -- so that when things happen in the plot you can have
any character you want be able to discuss it.
The way it is set up is also neat: you have all your conversations in
the same routine. You can, with ease, see everything that any
character could say without having to go to that character's
individual object.
If you tend to drone on a bit in your dialogue (like I did) I'd
definitely recommend phototalk.h. It was pretty much a snap to
incorporate: I think I needed to add one global variable to my program
in order to get it working, but that was it. You also need to add a
variable to all your characters so that the game knows which character
gets which conversations.
Good luck.
-- Robb
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robb Sherwin, Fort Collins CO
Reviews From Trotting Krips: http://ifiction.tsx.org
Knight Orc Home Page: www.geocities.com/~knightorc
Aman King
>
> I'm writing a game which may be described as similar in theme to
> Photopia. The plot was in embryo form long before I ever played the
> game, it's just now coming out. It is conversation heavy, and I'd like
> to ask RAIF's opinion as to which conversation system I should use:
> (B) The object-oriented version of Phototalk at the archive
> (C) a menu-based thing, quite similar to the one on Titanic: Adventure
> out of Time.
> (D) telepathy (prob j/k, but who knows?)
> (E) something else entirely
>
Hi,
I really liked the game Titanic: Adventure out of time. Got really involved
but I didn't like the ending. Anyway, I think that conversation style is
very good. Umm... but perhaps you could put in more options of dialogues to
choose from in the menu.
By the way, why not write the game in HTML-TADS with graphics and sounds?
Actually I just have TADS installed in my computer yet and that's why I'm
saying this. :-)
Hope to see your game soon.
Aman
BrenBarn
>to ask RAIF's opinion as to which conversation system I should use:
>(A) Inform standard
>(B) The object-oriented version of Phototalk at the archive
>(C) a menu-based thing, quite similar to the one on Titanic: Adventure
>out of Time.
>(D) telepathy (prob j/k, but who knows?)
>(E) something else entirely
to doubt my opinion, I still recommend either B or C (which, I think, are
similar choices). I tried A and it barely worked in the absurdly constrictive
environment I provided. E sounds interesting -- but a little vague :-). And
D would seem to generate the question: How do I implement telepathic
conversation?
But despite all my rage, I'm still just a rat in a cage on this issue.
I've sort of put the question on my back burner. I really liked Photopia, but
I really hate having to type in all the various conversations and format them
for whatever conversation engine (even my own :-).
Um. . . Yay menu-based conversation! :-)
From,
Brendan B. B. (Bren...@aol.com)
(Name in header has spam-blocker, use the address above instead.)
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
Nick Montfort
>(A) Inform standard
>(B) The object-oriented version of Phototalk at the archive
>(C) a menu-based thing, quite similar to the one on Titanic: Adventure
>out of Time.
>(D) telepathy (prob j/k, but who knows?)
>(E) something else entirely
I actually prefer option (E) - specifically, an Eliza-like
conversational system that uses simple pattern-matching to
rather accurately simulate a conversation with limited types of
characters (street preachers, persistent salesmen, Rogerian
psychotherapists, etc.) It wouldn't be impossible to implement in
Inform - probably bypassing the parser and doing all the
converstational pattern-matching beforehand would be the way to go.
Does anyone else think this would be an interesting conversational
interface option?
-Nick M.
Charybdis
> interface option?
Yes, but the second that it goes wrong then the character is dead in the
water. Take ELIZA for example - it's OK but it chokes pretty quickly. It
also (using pretty much every modern technique that I've seen) limits the
individuality of the characters to some, if not to a large extent.
- Richard
Skip the Penguin
Aman King <aman...@yahoo.com> wrote:
> By the way, why not write the game in HTML-TADS with graphics and
sounds?
> Actually I just have TADS installed in my computer yet and that's why
I'm
> saying this. :-)
Minor problem with that. I absolutly hate the TADS language. At first, I
tried to learn Inform. I got upset at the ->'s. I moved to TADS. When I
tried to code my first game, I got fed up at the restrictions. It was
too hard to code decent NPCs, in my opinion. I moved back to Inform, and
that's where I stay, until RAIF POOL comes out for i586 Linux. Also, I
absolutly hate the Windows TADS interpreter, which is the only one I've
ever used, since I haven't bothered to download the source to the Linux
one, since I hate the parser as well. Part of this may be due to the
fact that the first TADS game I played was that Parade thing.
--
In the middle of the faithless sky there hangs a small, dark world
that once was green and blue. Some say it killed itself by stabbing all
its lovely lands with deep atomic wounds. Some say it took an overdose
of hate. - Calvin Miller, The Singer Trilogy
Jon Ingold
> I actually prefer option (E) - specifically, an Eliza-like
> conversational system that uses simple pattern-matching to
> rather accurately simulate a conversation with limited types of
> characters (street preachers, persistent salesmen, Rogerian
> psychotherapists, etc.) It wouldn't be impossible to implement in
> Inform - probably bypassing the parser and doing all the
> converstational pattern-matching beforehand would be the way to go.
>
> interface option?
..not to mention that would take up a very large amount of code, wouldn't
it, and size is pretty restricted, so your game would then be a lot smaller
as a result - which may make the whole thing not worth it.
I haven't tried it though, so I don't *know*. :)
Jon
SteveG
>to get a response from CMP on the price of the Designer's Manual.
I guess that's coz the price is still an unknown quantity. We need to
be patient a little longer I think.
Go to deja.com and take a look at last year's posts on the topic by
Mike Berlyn. I just did.
In case you don't want to, in summary I found: the printed DM project
is a non-profit enterprise, the book was to be sold at a price
dependent on costs. Costs depended on the format and quantity of books
printed. The cost won't be much (if you're talking in US dollars, it
will be a lot in _my_ dollars :-( ) - at one stage an estimate of
$US7.50-$US15 excluding shipping was mentioned. Shipping etc could
also be somewhere in the same range depending on other stuff - like
where you live, I guess.
Also mentioned was that the publication time would be approximately
ten weeks after the text was passed to Mike B for printing. I think
the writing has only finished recently, if it has finished. So I'd
guess we still have to wait until about March for publication.
Disclaimer
- the above are non-facts based entirely on a few minutes reading
Deja and few seconds' guessing!
But HTH anyway.
--
SteveG
(Please remove erroneous word from address if emailing a reply)
Eric Heimburg
>conversational system that uses simple pattern-matching to
>rather accurately simulate a conversation with limited types of
>characters (street preachers, persistent salesmen, Rogerian
>psychotherapists, etc.) It wouldn't be impossible to implement in
>Inform - probably bypassing the parser and doing all the
>converstational pattern-matching beforehand would be the way to go.
Well, the technique Eliza uses is a simple keyword matcher. It knows no
grammar, no "patterns". It works like this: First, it figures out what all
the words in the sentence are. Then, it looks for a word that it "knows".
The first known word is used. Thus, if you type "Dream" you will get the
same response as "I had a dream last night".
Sometimes Eliza spits back out the text that you have input: that is, if you
say, "I need a sandwich", it will say, "Why do you think you need a
sandwich?" Here it just types "Why do you think " and then prints out your
statement's words, switching "I" to "you", "am" to "are", and so on. It has
a little list of words that it knows to change around so that when it spits
back out your sentence, it makes more sense. This definitely gives the
program a much 'smarter' feel, but it's just smoke and mirrors, sadly.
So, the point is that Eliza knows no grammar. [I should mention here that a
few versions of Eliza use tricks, like, if you say, "Dream", it doesnt give
you the "dream" response because it detects that there is only one word on
the line. But really it's the same thing, just a keyword-lookup program, but
with heuristics.]
That said, a keyword lookup works well in many game contexts. I am using
this method in the game I am currently writing. But it has some problems. It
can't discern the difference between "I hate you" and "You hate I". So, it
can either print out a generic sentence based on the keyword "hate", like
Eliza does ("Hatred isn't a useful emotion here"), which disguises the fact
that I have no idea what the user is actually saying, or else I have to use
actual grammar rules. In practice, I have to use a combination of both
methods, since you can't always get away with a generic sentence like this.
The big problem with the keyword lookup is that many times, most times in
fact, the user will want to type a sentence that contains multiple keywords.
In other words, "Steve, drive me to the mall" might trigger keywords for
"drive" and "mall". It isn't good enough to just respond as if they had
said, "drive me to the moon", because in this particular case, Steve will
actually drive the player to the mall. So I check to see if "drive" is in
the sentence, and if it is, if "mall" is in the sentence somewhere after
"drive". This is a very simple example, but you get the idea. Basically they
are pseudo-grammar rules, with more slop space than actual grammar lines.
They work well, and don't make my program too much larger than other
methods, but these are quite hard to implement [well].
I am making some functions and classes that make this sort of approach
easier to write, and once I finish my game, I'll release the tools as a
library-add-on if I am satisfied with them.
- Eric Heimburg
Nick Montfort
"Eric Heimburg" <heimburg...@mpinet.net_spamfree> wrote:
> Well, the technique Eliza uses is a simple keyword matcher. It knows
> no grammar, no "patterns". ["How it works" deleted.]
Your explanation is right on - but it does describe a process known as
pattern-matching. The keywords themselves and the "I need PHRASE1"
rules are the patterns it knows.
> So, the point is that Eliza knows no grammar.
True, but not necessarily failing in creating a character. If you
say "hell" or "Jesus" or "Islam" to a (somewhat caricatured) street
preacher, you are very likely to get the same type of response no
matter what other words are in the sentence. For certain characters, in
a dramatic situation where the user is playing along, this can be very
effective. As you point out, "I love Jesus" and "Jesus sucks
blue whale" would get the same response. If that response is "Jesus is
lord, brother! We must all confess it!" then maybe that's just fine.
With certain characters the ambiguity can be very plausibly ducked. The
trick is picking the right characters that work within this medium.
Janet Murray's book Hamlet on the Holodeck has more on this very topic.
(The book does not suggest Hamlet as a candidate for implementation
as an Eliza-type character.)
> The big problem with the keyword lookup is that many times, most
> times in fact, the user will want to type a sentence that contains
> multiple keywords. In other words, "Steve, drive me to the mall"
> might trigger keywords for "drive" and "mall".
Right, this pattern matching approach works very poorly for commands.
If you're going to have to order characters about I'd retract my
suggestion - or maybe a conversation mode and ordering-about mode are
in order. (Anything to avoid a menu of dialog options.) But in the case
of the street preacher, who takes his orders from a higher authority
anyway, the more "important" word can simply take precedence and
trigger the most emotional response.
> I am making some functions and classes that make this sort of
> approach easier to write, and once I finish my game, I'll release the
> tools as a library-add-on if I am satisfied with them.
Excellent! They will be a valued addition - valued by me, at the very
least.
-Nick M.
Adam Cadre
> True, but not necessarily failing in creating a character. If you
> say "hell" or "Jesus" or "Islam" to a (somewhat caricatured) street
> preacher, you are very likely to get the same type of response no
> matter what other words are in the sentence.
I seem to recall that at one point, Douglas Adams was planning an
Eliza-like program called "Reagan", based on his observation that
during the 1984 presidential debates, it was clear that Reagan had
simply memorized some index cards and would spout their contents
based on a pattern-matching system no more complex than that described
in this thread ("Let's see... blah blah blah, welfare-- welfare!
He's talking about welfare! That was card #8... how'd it go...? Oh,
my turn to talk... 'My fellow Americans, the welfare system is being
abused by Cadillac-driving con artists...'")
-----
Adam Cadre, Sammamish, WA
http://adamcadre.ac
Andrew Plotkin
> say "hell" or "Jesus" or "Islam" to a (somewhat caricatured) street
> preacher, you are very likely to get the same type of response no
> a dramatic situation where the user is playing along, this can be very
> effective. As you point out, "I love Jesus" and "Jesus sucks
> blue whale" would get the same response. If that response is "Jesus is
> lord, brother! We must all confess it!" then maybe that's just fine.
> With certain characters the ambiguity can be very plausibly ducked. The
> trick is picking the right characters that work within this medium.
For example, characters that have some established relationship to the
player, so that either the verb or the subject of the communication can be
assumed. Or, if not those, the *range* of verbs and subjects at least.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
David Glasser
> Nick Montfort <nickmo...@my-deja.com> wrote:
>
> > With certain characters the ambiguity can be very plausibly ducked. The
> > trick is picking the right characters that work within this medium.
>
> For example, characters that have some established relationship to the
> player, so that either the verb or the subject of the communication can be
> assumed. Or, if not those, the *range* of verbs and subjects at least.
For example, the PC could be tied to a chair by a bad guy who only lets
the PC say 'yes' or 'no'. But nobody would ever get away with something
so blatantly forced as that.
--
David Glasser | gla...@iname.com | http://www.davidglasser.net/
rec.arts.int-fiction FAQ: http://www.davidglasser.net/raiffaq/
"Maybe Glulxification will cause people to start using Scheme for IF. Or
maybe not. Anyhow, I just like saying 'Glulxification'." -andyf on ifMUD
Bert Byfield -- no mail
The same can be said about lots of carbon-based life-forms, too! ;-)
**********************************************
Bert Byfield
http://www.caravelabooks.com (or amazon.com)
Now in print: Rage of the Bear and Scream of the Eagle
In Preparation: Last Stand at Perekop
********************************************
snail
>>to get a response from CMP on the price of the Designer's Manual.
>I guess that's coz the price is still an unknown quantity. We need to
>be patient a little longer I think.
>Go to deja.com and take a look at last year's posts on the topic by
>Mike Berlyn. I just did.
<delurk>
Is it still possible to get added to the distribution list for this ?
I was overseas when most of this was discussed the first time round.
</delurk>
--
snail | sn...@careless.net.au | http://www.careless.net.au/~snail/
I'm a man of my word. In the end, that's all there is. - Avon
SteveG
>SteveG <stev...@erroneous.moc.govt.nz> wrote:
>>On Sun, 09 Jan 2000 03:42:10 +0000, Skip the Penguin
>>> [snip] Speaking of Inform, I've been unable
>>>to get a response from CMP on the price of the Designer's Manual.
>>I guess that's coz the price is still an unknown quantity. We need to
>>be patient a little longer I think.
>
>>Go to deja.com and take a look at last year's posts on the topic by
>>Mike Berlyn. I just did.
>
><delurk>
>Is it still possible to get added to the distribution list for this ?
>I was overseas when most of this was discussed the first time round.
></delurk>
I don't know if its possible to be added to the list of people to be
notified when the 'DM' book is published (because bookings closed many
months ago.) I guess it wouldn't hurt, though, to email a mention of
your interest to 'CMP'.
Just guessing again, but I imagine the publication will be announced
in rec.arts.int-fiction and that orders will be accepted from other
people once those who pre-booked have had a chance to confirm their
orders.
Philip Goetz
news:38784723...@news.frii.com...
> The way it is set up is also neat: you have all your conversations in
> the same routine. You can, with ease, see everything that any
> character could say without having to go to that character's
> individual object.
This may be another example of when object-oriented is bad.
Hey, I love OO, but sometimes it does more harm than good,
particularly (IMHO) in some aspects of IF.
Phil G., heretic
You can tell I'm a government contractor -- I used 3 acronyms in one
sentence.
Kevin Forchione
news:UH_j4.7438$Ve7.1...@iad-read.news.verio.net...
> This may be another example of when object-oriented is bad.
> Hey, I love OO, but sometimes it does more harm than good,
> particularly (IMHO) in some aspects of IF.
In all seriousness I would be interested in your views on this. I've been
debating OO versus a more procedural approach (like Inform employs) in my
own library development and have been leaning toward the latter.
--Kevin
Philip Goetz
news:u1MqVLPa$GA.272@cpmsnbbsa04...
You want to organize things in some fashion. OO focuses on nouns.
Sometimes, in IF, you want to focus on verbs. I would usually
rather have the details for how a verb like "open" or
"break" or "burn" works be implemented in the verb rather than
in the object. The object should just have properties. This is
because I am lazy, & because I take a simulationist approach
to IF: I would rather have a world in which the effects of
sledgehammers and matches are consistent, although
described with little literary value, than a world in which a
few crucial objects can be broken and burned with beautiful
handcrafted descriptions.
You can have different classes of objects with their own burn
methods, but not unless you have a better method of dealing with
multiple inheritance than I am aware of (and than is allowable
in C++ or Java). Sometimes you want to focus on events
(eg. conversations), sometimes on dramatic progressions.
You can't always divide your world up so that your objects
organize the world; sometimes you have some information about
the same objects that you want to organize in one way, and
some information you want to organize in another way.
Phil
Kevin Forchione
> Sometimes, in IF, you want to focus on verbs. I would usually
> rather have the details for how a verb like "open" or
> "break" or "burn" works be implemented in the verb rather than
> in the object. The object should just have properties. This is
> because I am lazy, & because I take a simulationist approach
> to IF: I would rather have a world in which the effects of
> sledgehammers and matches are consistent, although
> described with little literary value, than a world in which a
> few crucial objects can be broken and burned with beautiful
> handcrafted descriptions.
Intriguing. This is exactly what I've done with my current project, Venture
library (TADS). This library has all of the verification and action methods
in the verb, reducing the object definitions down to a handful of defining
attributes -- and one object definition superclass to handle the most common
mechanisms, such as moveInto(), etc.
It's similar to Inform in approach, allowing you to override the default
behaviour in a preAction step, and allowing you to override the default
message in a postAction step.
There are some immediate consequences to this approach. First the code
becomes very compact, because to a greater degree objects become irrelevant
and attributes more important. Thus one method can handle the opening of
doors and openable objects. One method can handle locking, another
unlocking. And if you create a mechanism for handling generated actions (as
opposed to player command actions) this begins to look very attractive.
Another consequence is that verification methods for direct and indirect
objects collapse into one message (otherwise you need to implement
attributes for the objects, such as turnee and turner.) Thus, in TADS, where
the direct object verification might print: "Attacking <<self.thedesc>>
doesn't appear productive. " and the indirect object: "It's not very
effective to attack with <<self.thedesc>>. "; you have to use something
similar to Inform's "Violence isn't the answer to this one.".
> You can have different classes of objects with their own burn
> methods, but not unless you have a better method of dealing with
> multiple inheritance than I am aware of (and than is allowable
> in C++ or Java).
I'm not following you here, can you elaborate on the problem? The multiple
inheritance structure of TADS has sometimes caused conflicts for me. For
example, when I was developing the 'enterable' class I needed behaviours
from several classes. Their behaviours conflicted. I needed to be able to
specify the order of inheritance at a method level in order to make it
work -- in the end I simply created the object with all of the required
methods coded up, inheriting only from the base class.
>Sometimes you want to focus on events
> (eg. conversations), sometimes on dramatic progressions.
> You can't always divide your world up so that your objects
> organize the world; sometimes you have some information about
> the same objects that you want to organize in one way, and
> some information you want to organize in another way.
Oh, I see. But by objects, do you mean game objects as opposed to verb
objects? Or objects in general? Maybe some examples would help.
--Kevin
Sean T Barrett
>> rather have the details for how a verb like "open" or
>> "break" or "burn" works be implemented in the verb rather than
>> in the object. The object should just have properties. This is
>> because I am lazy, & because I take a simulationist approach
>> to IF
>
>library (TADS). This library has all of the verification and action methods
>in the verb, reducing the object definitions down to a handful of defining
>attributes -- and one object definition superclass to handle the most common
>mechanisms, such as moveInto(), etc.
>Another consequence is that verification methods for direct and indirect
>objects collapse into one message (otherwise you need to implement
>attributes for the objects, such as turnee and turner.) Thus, in TADS, where
>the direct object verification might print: "Attacking <<self.thedesc>>
>doesn't appear productive. " and the indirect object: "It's not very
>effective to attack with <<self.thedesc>>. "; you have to use something
>similar to Inform's "Violence isn't the answer to this one.".
Hmm, when I did this sort of thing on my mud I viewed it as a two
step process: first parse what the player means, which involves
analyzing the verb and what objects the player knows about and can
reach; then it is turned into an "action", the undertaking of which
varies with the action and number of objects involved. There would
be a specific "turner"/"turnee" attribute/query, for example. However,
as often as possible, verbs map to related actions that share
attributes, so you don't end up having attributes on every object
for every verb, but only for every action. Thus, as I mentioned,
liquid transferral used a number of different verbs (I think there
were actually 5 different phrases) which mapped to three different
actions (emptying, filling, and singleton transfers), all of which
were built upon the single unique transferral action. An object
couldn't override "fill X from Y" but not "empty Y into X" directly
(although by specifying that Y couldn't be 'moved', 'emptying'
becamse impossible, since it was assumed it involved tilting it,
which wouldn't be flexible enough if you had a spigot--whereas
the former command just requires that one or the other be mobile,
since it can be done by pouring or by dipping).
The low-level act of motion queried individual objects to see
if they wanted to disallow it; three objects were involved, and
each was allowed to know about the other two. The return code
from a move failing had six possible values, which were something
like "can't move object X", "object Y won't let X be removed",
"object X doesn't want to go in object Z", "object Z doesn't
want to allow an object from X", and "object Z doesn't want
objects from Y" (which actually omits one case). But normally
things wouldn't block on this low a level; if a character didn't
want to accept a 'give' that showed up at a higher level.
SeanB