That's a good question. Tradition usually suggests a ASK/SHOW/TELL
method, but I'm not too crazy about that. It makes NPCs feel very
unrealistic, because the player eventually winds up doing things that
elicit a canned response. IMHO, it's a better idea to somehow constrain
the number of actions the player is allowed to take, therefore making
the player's actions less random. As to how to do this, three ways come
to mind: The menu-system used in Once and Chicken and Egg, the similiar
system used in Photopia, and the YES/NO/Z system used in Spider and Web.
(granted, I'm no expert, but... >:===8)
"If you can get sent to hell for kissing, hell must be a pretty
overcrowded place." -Nocturnal Illusion
Long Live the Hentai Game!
Any way that actually works.
Sowwy, Doe hehehe
Doe doea...@aol.com (formerly known as FemaleDeer)
"In all matters of opinion, our adversaries are insane." Mark Twain
There's lots of ways.
"Photopia" has a nice and simple method.
Convention has the problem of potential "guess-the-subject" headaches.
You could try to emulate real sentences... but either go insane or run
into format limits in the process.
So... perhaps a compromise between the three systems? Or are there any
One of the problems is that the parsers used in the major systems aren't
particularly good at parsing conversational input, which limits us (pretty
much) to the systems we have at the moment. Writing a good parser to
deal with free-form converational text is hard. Very hard. For an example
of something that works reasonably well, check out this -
Now, assuming we find a way of dropping a reasonable conversation parser
into a game (This would probably involve using two or more parsers - one
for the game and one for the conversational aspects - possibly even one
for each NPC in the game) without ruining the feel of the game, we have
to actually react to the input the player gives. And even if we restrict
the input understood by an NPC to a domain that they might reasonably
be expected to understand, that domain is going to be unrealistically
small compared to the domain of a 'real' person. So conversations with
that NPC will always be tripping over 'boilerplate' responses, even with
sane player input.
What I'm trying to say is, we have a few paradigms that work within the
limited bounds we give them. The amount of work involved to code an
'realistic' NPC at the moment is pretty massive, even given the
restrictions we work to. Remove those restrictions, and the amount of
work will snowball, and realism of NPCs will most likely drop relative
to player expectations. I'm not saying we shouldn't explore other
possibilities, but the existing ways of doing things work pretty well
on the whole.
Just my £0.02
| ----- | Biased output from the demented brain of | ----- |
||MacOS|| Simon Stapleton. ||Linux||
|| 8.5 || || PPC ||
| ----- | sstaple AT liffe DoT com | ----- |
| -+-.| (if you can't figure it out...) | -+-.|
I have no idea how this could be done in Inform, TADS, et al, but if you
can program Tetris in Inform..... :-)
CAVE will in version 2 (yes, I know, v1 is not even out - yet) have a
stong focus on this kind of functionality. Where each NPC will (among
other things) have a chatter-box type interface to a knowledge base for
Anyone know of interesting links on the subject?
Time for some GPP in IF?
The conversation implementation in the Ultima adventures was interesting.
Basically, you can say whatever you like to any NPC. However, I think that
the whole extent of the parsing of your input was to obtain a list of
keywords. Saying "Please tell me about the magic ring of Kazam" and
"You can flush the magic ring of Kazam down the toilet, for all I car."
will elicit the same response: the NPC will dutifully tell you everything
he/she knows about the magic ring of Kazam.
The amazing thing is that, unless the player is actively trying
to fool with the game, it tends to work pretty well.
Actually, that's a subject that I have brought up in this newsgroup
before. There are two different senses in which a game can have a "bug":
(1) The player tries to do something that makes sense in the context
of the game world, but the game "breaks", and gives a nonsensical
response. (2) The player does something that makes no sense in the
context of the game (e.g. "Drink light bulb", "Eat door", "Take loud
noise"), and the game allows it.
Games that are only bug-free in the first sense may be perfectly
satisfactory to a certain kind of player, the kind who tries to
"get into" the game and only perform actions that are in character.
Phil Goetz had a brilliant suggestion about Virtual Stupidity a long while
When I get around to needing complicated NPCs, I'm going to try to use it.
As I recall, the ideas behind it were:
a) *I* am the center of attention
b) Everyone else is out to get me
c) If I know about it, I must be careful sharing that knowledge
d) If I don't know about it, someone is planning to use it against me
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
> The conversation implementation in the Ultima adventures was interesting.
> Basically, you can say whatever you like to any NPC. However, I think that
> the whole extent of the parsing of your input was to obtain a list of
> keywords. Saying "Please tell me about the magic ring of Kazam" and
> "You can flush the magic ring of Kazam down the toilet, for all I car."
> will elicit the same response: the NPC will dutifully tell you everything
> he/she knows about the magic ring of Kazam.
That's how CAVE works today. And (as you say) it works fine, as long as
the player is kind to the game...
However, I find it frustrating to work with *both* the 'ASK ABOUT' method
*and* through 'SAY' when implementing a game - or system.
As long as there is a 'SAY' verb - which is practical when it comes to
saying magical words and such - it feels un-natural if one isn't able to
"ask about" something through 'SAY'. And then the snowball is
This really goes for *any* interaction with NPCs.
A 'BUY' verb in a shop, for instance, is quite crippling, as you'd also
like to talk to the shop keeper, perhaps negotiate the price?
Typing of which, anyone has any games with good implementations of NPC
shop keepers to recommend?
Hemma hos: http://www.stud.ntnu.no/~jacob/
Maskiner: PowerMac 4400, Mac LC, Mac Plus, Sinclair Spectrum
The most common ones:
- menu based conversation. Fairly easy to implement, fairly easy to
develop the plot in. Limits the player and can cause the player to
not dig the character he/she is playing. (Photopia, Quest For Glory)
- ask/tell topic based conversation. Fairly easy to implement, not
easy to develop the plot with. Limits the player to relevant topics
and isn't all that great when it comes to long conversation threads
(in tennis terms: most conversations are 'aces', a 'rally' is
- free text using keyword or keyword-combo triggers for response.
Fairly easy to implement, fairly easy to develop the plot in.
Introduces a new mode: 'conversation mode' (Ultima, Starship
Titanic?). Gives the player a chance to enter totally ludricous
statements and receive a meaningful response. Limits the player to
relevant topics and can lead (like ask/tell) to 'guess-the-keyword'.
- question based conversation (4 in 1 comes to mind), which triggers
special parsing of questions, that start with 'who', 'what',
Rare to unheard of:
- a better chatterbox than eliza/julia/parry/racter. A pain to
implement (the chatterbox approach is connected to a specific
behaviour/response pattern, eg. non-directive counselling, paranoia,
etc.), could be easy to develop plot in. Introduces conversation
- shrdlu-like contextual parsing. A pain to implement, plot may go off
on a tangent. Conversations may be extended but are strictly limited
to the limited world model held by the NPC. Introduces conversation
- natural language parsing and understanding. A pain to implement
is an active area of AI research), and an even bigger pain to
the plot in. Introduces conversation mode and the step from
understanding what is being said to an appropriate response is in
the dream-phase. The parsers are often limited to grammatical
sentences and a limited (fixed) vocabulary (unless you want to
introduce machine learning, yet another active area of AI research).
- context-based, natural 'speech'-type language parsing and
understanding. If you can pull this off and solve the step from
understanding to an appropriate response, then your conversation
system is likely to pass the Turing Test with flying colours. (eg.
try my sig below as a starting point for a free-format conversation
between player and Cat that has 10 exchanges or more, free-format as
in the player is allowed to give any response and will receive an
appropriate response from the Cat as long as the player's response
makes sense in the context of the Cat's world model and/or the
conversation - hey, here is an idea for a minicomp!).
Almost all types (with the exception of ask/tell) introduce a special
'conversation' mode (generally begun with 'talk to' and terminated
'bye'), which require extra work on the part of the implementor given
the single prompt/command mode of the dominant authoring systems and
may be confusing to players at times.
IMHO, the traditional systems aren't that bad from an authoring point
of view. They could be improved upon, obviously. In ask/tell, for
instance, I would love to see a 'talk to/chat with' which would do the
smalltalk us humans seem to like so much. Or a game that would allow
'apologize to' ;-) (Hmmm, maybe I should write my own ...)
"Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat
(remove nospam to email me)
Rene van 't Veen - r.n_o_s_p_...@wxs.nospam.nl
>IMHO, the traditional systems aren't that bad from an authoring point
>of view. They could be improved upon, obviously. In ask/tell, for
>instance, I would love to see a 'talk to/chat with' which would do the
>smalltalk us humans seem to like so much. Or a game that would allow
>'apologize to' ;-) (Hmmm, maybe I should write my own ...)
In Mother Loose, the player can APOLOGIZE TO THE EGG. Don't
you just love it when somebody ignores every important point
you've tried to make and focuses on something completely
>...IMHO, it's a better idea to somehow constrain
>the number of actions the player is allowed to take, therefore making
>the player's actions less random. As to how to do this, three ways come
>to mind: The menu-system used in Once and Chicken and Egg, the similiar
>system used in Photopia, and the YES/NO/Z system used in Spider and Web.
To me those feel like a strait jacket. A feeling Plotkin's game used
to advantage, but not the others (to me).
It was intentional.
[ on menu-based or otherwise restrictive conversational systems ]
>To me those feel like a strait jacket. A feeling Plotkin's game used
>to advantage, but not the others (to me).
I would argue that, currently, any conversational medium is similarly
restrictive. It doesn't seem that having "the X ignores you" responses
to anything other than the magic sentence gives you more freedom.
One day, yeah. The day when one of my NPCs surprises me by replying
intelligently to something unexpected will be a good day. It's
hard to achieve the Eliza effect on ones own code.
(that is, surprises me in a way other than "Bus error. Core dumped")
Strange... for me it's exactly the opposite. After about ten minutes of
canned responses and 'conversations' that get me nowhere, frustration
kicks in, I get completely out of it, and the NPC becomes another puzzle
to be solved instead of a person to interact with. In a menu system I
can get the job done without slipping out of the illusion.
>I would argue that, currently, any conversational medium is similarly
>restrictive. It doesn't seem that having "the X ignores you" responses
>to anything other than the magic sentence gives you more freedom.
I disagree. The X doesn't have to ignore you, but can be coded to say
something or do something back, wander off, leave in a huff, etc. You
could even code randomized multiple events. I would rather be able to
use my own creativity and wits to think of stuff to ask (and risk that
type of "no info" response - after all, some people are like that at
times) than to be given a list, which essentially tells me: "Pick one
of these or forget it." At that point, my subjective involvement is
shut out, and I'm not part of it anymore. I'm more back into an
objective mode: pick A, B, or C, please.
I'm not claiming that either approaches any type of AI -- I just
dislike list-based IF conversations.
I'm going to step in here and say that I, for one, actually *like* the old
ask/tell guess-the-subject routine. Maybe I'm the only one, I don't know.
But as long as the NPC has a decent number of responses and a reasonably
interesting "I don't know" response, I generally don't mind chattering at
Which isn't to say that ask/tell can't be dreadfully boring as well, if you
don't put enough effort into it. If you go the traditional route, here are
1) Give the NPC lots of subjects. Just bite the bullet and make a huge list
and program them all in. How much is enough depends on the scope of the
game, but 20 is a good number to start at the minimum.
2) Give the NPC several different "I don't know" responses, picked on a
random basis. This ameliorates some of the repetition when guessing
3) Make your conversation subjects object-based, rather than keyword-based,
so you can take full advantage of synonyms and disambiguation. "yellow
squash" should be equivalent to "squash" but not "yellow cab."
4) Program the daemons for NPC so she does something other than answer
questions, e.g. muttering to herself, sniffling, going wearily back to her
spot-welding, whatever. Makes it a little less like pushing a button.
5) Pronouns. If you're using a system that doesn't already use pronouns,
program them in. It's a lot easier to keep asking questions when I can type
"ASK HER ABOUT" instead of "ASK GRUNNHILDE ABOUT".
Keep those in mind, and I, at least, will be happy with your rusty old
antiquated ask/tell system.
"If you don't eat your meat, you can't have any pudding.
How can you have any pudding if you don't eat your meat?"
I never said I disliked it. Indeed, so long as there's plenty of
responses, it's perfectly all right.
> Which isn't to say that ask/tell can't be dreadfully boring as well, if you
> don't put enough effort into it. If you go the traditional route, here are
> five suggestions:
> 1) Give the NPC lots of subjects. Just bite the bullet and make a huge list
> and program them all in. How much is enough depends on the scope of the
> game, but 20 is a good number to start at the minimum.
I agree. I usually put in plenty of subjects.
> 2) Give the NPC several different "I don't know" responses, picked on a
> random basis. This ameliorates some of the repetition when guessing
x=random ("x", "y", "z");
> 3) Make your conversation subjects object-based, rather than keyword-based,
> so you can take full advantage of synonyms and disambiguation. "yellow
> squash" should be equivalent to "squash" but not "yellow cab."
Info.h does this all for me.
> 4) Program the daemons for NPC so she does something other than answer
> questions, e.g. muttering to herself, sniffling, going wearily back to her
> spot-welding, whatever. Makes it a little less like pushing a button.
Little things can be good. Oh yes.
> 5) Pronouns. If you're using a system that doesn't already use pronouns,
> program them in. It's a lot easier to keep asking questions when I can type
> "ASK HER ABOUT" instead of "ASK GRUNNHILDE ABOUT".
Yeah. Pronouns are in!
> Keep those in mind, and I, at least, will be happy with your rusty old
> antiquated ask/tell system.
Those are always in my mind.
> IMHO, the traditional systems aren't that bad from an authoring point
> of view. They could be improved upon, obviously. In ask/tell, for
> instance, I would love to see a 'talk to/chat with' which would do the
> smalltalk us humans seem to like so much. Or a game that would allow
> 'apologize to' ;-) (Hmmm, maybe I should write my own ...)
There are games that allow APOLOGIZE TO. Quite a few of them, in fact. I
like interacting with NPCs, so I tend to try it a lot. Ditto THANK, which
games also implement (though not as many as do APOLOGIZE).
In fact, as, as I said, I like interacting with NPCs, I definitely plan to
APOLOGIZE TO in all the games I write. (Have some in progress, but as at
least one may be a potential entry in Comp '99 I can't really say anything
them yet.) Ditto THANK, INSULT, HELLO, and probably a few other verbs too.
Of course, it wouldn't be fair to have any of those verbs actually required
the game (at least, not without some pretty darn good clues to that
I like the extra possibilities they supply.
P.S. Please, no replies giving lists of other potential NPC-interaction
already have compiled quite a long list of such verbs I'm considering
(only a small fraction of which I am likely to actually implement), and I
too many other people would be interested in such a list.
------ Jason F. Finx
> Strange... for me it's exactly the opposite. After about ten minutes of
> canned responses and 'conversations' that get me nowhere, frustration
> kicks in, I get completely out of it, and the NPC becomes another puzzle
> to be solved instead of a person to interact with. In a menu system I
> can get the job done without slipping out of the illusion.
And an NPC with a menu of responses _doesn't_ feel like just another puzzle
to be solved, and _does_ feel like a person you can interact with? Okay...
If you say so...
I suppose this is a matter of personal preference, and nobody is going to
convince anyone else here (not that anyone is necessarily trying to), but
come down firmly on the side of ASK/TELL/SHOW. There may be a better
way, but I haven't seen it yet. Menu responses definitely aren't it. Your
possibilities with ASK/TELL/SHOW may be limited, but the limits aren't as
painfully obvious as they are with menus; you have at least more illusion
choice, even if there aren't all that many things the NPC will respond to.
I absolutely and thoroughly dislike the idea of limiting talking to NPCs to
menus. I understand there are some people who may prefer that method. I
am not one of them. I have no idea how to elegantly end this paragraph.
----- Jason F. Finx
>But as long as the NPC has a decent number of responses and a
>interesting "I don't know" response, I generally don't mind chattering
I tend to prefer the ask/tell system too. Of course, the NPC should have
a decent amount of responses, and should respond to queries about
anything the character should reasonably know about. If I ever actually
get around to writing a work of IF, I will take great pains to avoid any
'I don't know' responses as the 'default'. I prefer 'defaults' like these.
>ASK BUTCHER ABOUT BOOKSTORE
A long silence tells you that the butcher isn't interested in talking
>ASK CUSTODIAN ABOUT MAILBOX
"I can't see what I could tell you that you wouldn't know already."
as opposed to...
>ASK SCIENTIST ABOUT WORK BENCH
"I don't know much about that."
I've always felt that the just plain 'I don't know' defaults were
annoying, especially when the subject is something the NPC asked should
reasonably know about. The scientist in the last example doesn't HAVE to
answer questions about the work bench, but he/she shouldn't be forced to
claim he/she knows nothing about the work bench either (especially if the
work bench is in the laboratory). Default responses like the last example
should be avoided, unless the character in question is some hermit or
other type who doesn't get out much.
Also, all of the above examples contain defaults that are 'generic'. If
defaults are more character-specific, they can not only avoid 'breaking
mimesis' but can also help in the development of the character as well.
The following exchange from 'Lurking Horror' is a good example:
>ASK HACKER ABOUT CREATURE
The hacker studiously ignores you, loath to admit there is something he
doesn't know about.
This, I feel, is amusing enough, and helps to flesh out the hacker's
character. Of course, it still is dangerously close to the 'I don't know'
response, which threatens to 'break mimesis' if it comes up as a response
to something the NPC should reasonably know about. (Of course, since
hackers spend so much of their time hacking, this one can be forgiven for
not knowing too much about what's going on outside the Computer Center).
In any case, I feel that ask/tell works, as long as the NPC gives
responses to a decent amount of questions (depending on how talkative the
NPC is), and doesn't give 'I don't know' responses to subjects the NPC
should reasonably know about (but once again, 'I'm not interested in
talking about that' or 'I don't see what I could tell you that you
wouldn't already know' responses are more acceptable). One just has to
take care to make sure all of the NPC's responses, including the
'defaults', are in character with his/her/its personality.
This also depends a lot on the individual game. At the Implentor's Lunch
yesterday (which seemed to be a great success, BTW) this point was brought up
and almost nobody there argued for a menu-based system - not even me, and I'm
a big booster of the technique. The reason was that the game described sounded
like it would flow much better with an ask/tell system. An example of a place
where a menu system WOULD be appropriate is when the NPC is doing the asking
and the menu gives the possible player responses. This would avoid a
restriction to yes/no answers, and at the same time avoid bringing the game to
a standstill while the player searches for the correct syntax to answer the
NPC's questions. (Including a "say nothing" response is a good idea.)
For example, in a mystery or horror game, each door is an unknown.
"What's behind... THIS door?" "Uh, a bathroom?" "Well... what's in
the BATHROOM?" "Uh, towels."
-- Steven Marsh
> P.S. Please, no replies giving lists of other potential NPC-interaction
> verbs. I
> already have compiled quite a long list of such verbs I'm considering
> (only a small fraction of which I am likely to actually implement), and I
> don't think
> too many other people would be interested in such a list.
It is polite to restrict your line lengths to approximately 70 characters.
Please adjust your newsreader or take other steps to remedy the
staggered appearance of your posts on some other newsreaders. Using a
non-proportional font helps.
In the English language sphere it may work well - at least to anyone who
has played a bit of i-f - but it becomes apparent when used in languages
where modern i-f is quite uncommon. And where issues like these are not as
To me, it is more locical to *say* things to inviduals I encounter, than
to push defined buttons on them. For this reason, the chatterbox - or
chatterbot - approach is (ultimately) the only logical one - to me. And I
will state my case here.
I-f is the experiencing of virtual worlds through prose, (ideally) using
natural language commands to communicate with the game.
To me, ASK, TELL, a.s.o. are not very obvious - as compared to f.ex. TAKE,
EAT, GO - and, to be honest, if nothing (i.e. the manual) had told me
about these verbs, I would not have guessed them (forgetting now that I
already know about them).
For me, ASK is not a *verb*, it is a *command*. As such it works well when
you know it, just like DIR works well in DOS. When you know it.
I know I am taking an academic (and unpractical) stand-point focusing on
what would be the next step, rather than a pragmatic/practical one
focusing on what can possibly be done with the technology at hand
(existing i-f systems), but it is the road ahead that interests me most.
This is how I envision a system could work:
As I see it, there are three types of commands that one uses to control a
piece of i-f, and two types of output from it.
There are commands to control the game as such (HELP/HINT, BRIEF/VERBOSE,
SAVE/LOAD, QUIT). There are the verbs to control the player's character(s)
in the virtual world (GO, TAKE, EXAMINE, OPEN, EAT, WAIT). And there is
the interaction with the NPCs.
The two types of output are what is happening in the world, and what is
happening with the game.
In an i-f system it would - given that it has a graphic user interface
(GUI) - be logical to enter game commands through menus, player verbs
through the "classical" i-f prompt, and - or so I think - interacting with
NPCs through a separate chat-prompt.
Response to game commands, parser errors, a.s.o., scroll with the player
commands, while the consequences of player commands, and of the NPC
interaction, scroll in the "prose" window.
This is how it works in CAVE. (To cope with console type systems, every
game command has a corresponding "verb" that can be entered at the verb
prompt, and chat can be made through a SAY "WHATEVER" [TO SOMEONE] or
similar verb.) (As CAVE v1 only has a very simple chat engine (key word
detection), the chat prompt will probably not appear until CAVE v2.)
Now you say, but Eliza is no fun talking to. She is even more stupid than
*any* canned respons to ASK!
True, but using chatterbot technology in i-f will be quite different from
in a chat-only application.
Firstly, much has happende since Eliza....
Secondly, while a simple chatterbot does nothing but bend sentences and
throw them back at you, a chatterbot designed for i-f will also include a
knowledge-base for what that person knows.
Thirdly, different types of NPCs will have to have some special type of
"topic" that they treat in a special way. A bar- or shop-keeper selling,
negotiating and keeping stock is a good example.
Fourthly, and most importantly, a chat-only chatterbot is a second person
character (that is, a "you"), while an NPC is third person
("he"/"she"/"it"). It is a person with more that a spoken respons. This
means that an NPC will *do* things as a response to the chat.
In this way a chat-enabled NPC can bend your sentences, give you
information, negotiate, and *do* things as a result to what you SAY.
To me, that is much more interesting.
And I'm also working on it.... Wish me luck! ;)
: Personally, I find neither the menu or ASK/TELL approach fully satisfactory.
It's a very limiting grammatical structure. We really need a host of other
grammatical structures that can be interpretted. There was a good thread
not too long ago that ran down a list of ways that we can talk to NPCs.
Some good new (I haven't seen them used, but maybe they have been)
suggestions were "who is" and "where is". This opens the knowledge base
can of worms, and I'll mention it a few times throughout this post.
So what will new grammars get us... Well, Jacob is right in pointing out
that we shouldn't overload users by making them learn them all by heart
(by reading the manuals?!) word for word before starting a game. So how to
avoid opening the floodgates too far when it comes to possible grammars?
In this way, the extraordinarily crude keyword approach doesn't look so
Eventually, of course, the parser has to be a little more sensitive than
that, while retaining the ability to evoke the "right" response in more
than one way. That's a key feature. A true knowledge base system will help
that, but the implementation appears to be a big job.
: I-f is the experiencing of virtual worlds through prose, (ideally) using
: natural language commands to communicate with the game.
And for that very reason, I think that a game system can become
aestheticly unpleasing with too many menu-oriented functions. I'm talking
both about menus in the text (a la Photopia) and within the window
manager, if there is one for your system. As far as GUI type stuff -- I,
for one, would be happy to have directional (E/W/N/S) buttons, and perhaps
a menu method or pop up box to keep track of inventory persistently,
rather than have to check it. But that is about it. More comments on the
Photopia/Spider and Web method in a sec.
I found the comment on "virtual worlds through prose" to be really dead
on, and somewhat contradictory to your inclusion of menu functions. [And
I'm not a hard line straight ascii kind of guy, either.] I need to feel
like the entire game is being pushed through my character's central
nervous system in the form of the text output. And to segregate
conversational functions and physical functions too much is oddly
arbitrary. Some old Sierra games took this approach, although with
graphics, and I found it far less satisfying than either purely graphical
or purely text games. It's the artificial segregation that gets me, not
the menus themselves. I'm all for automation of repetitive tasks, with
menus, or any other way...
Which brings me back to Photopia. (The following is longwinded... read at
your own risk)
*sigh* To me, it seems maturity in I-F is greatly advanced by this kind of
game, and this kind of discussion of certain games and particular elements
in them. What I see out there is that quite a few standouts have managed
to carefully balance puzzles with some form of (albeit usually low level)
conversational interactivity. Some of it is conversational problem
solving, but there are good examples of characters whose brains you can
pick (a great one would be Christminster). Many times, though, there is
only one character in the game that serves nearly as an Oracle, and
sometimes even functions via keyword. This isn't much better than looking
up information in a book index, really. It gets old.
In order to deal with an open-ended conversation of potentially very very
high mathematical order, Photopia and Web cut down the answer space
vastly, by forcing you into choices. Not to say that this isn't
game-appropriate at times (very much so for the interrogator in Web), but
in Photopia it was more constraining. This kind of thing screams out for a
knowledge base, I think, coupled with good enough writing to keep the
player moving in the right direction. That part is the really hard part.
It could still be done with just ASK/TELL/SHOW/GIVE/etc, but would be more
fun with some added grammars.
: This is how it works in CAVE. (To cope with console type systems, every
: game command has a corresponding "verb" that can be entered at the verb
: prompt, and chat can be made through a SAY "WHATEVER" [TO SOMEONE] or
: similar verb.) (As CAVE v1 only has a very simple chat engine (key word
: detection), the chat prompt will probably not appear until CAVE v2.)
Good that you're making this provision, at least. I'd very much like to
see CAVE. It sounds like a pretty well thought out system, overall.
: Thirdly, different types of NPCs will have to have some special type of
: "topic" that they treat in a special way. A bar- or shop-keeper selling,
: negotiating and keeping stock is a good example.
Well, things like this are already very much possible. (It just depends on
what system you are using to figure out how hard it is going to be to
implement!) For instance, working in keywords, it will be very easy to
implement, despite being clunky for the parser. Quite a bit harder for the
major systems, and perhaps somewhere intermediate in difficulty for ALAN.
Simplicity of programming these NPCs is really pretty key, for a new
system though, if there is to be any hope of people doing anything fun
with it (and I'm not even talking about making the engine popular, just
scaleable and feasible and flexible). Hopefully Jacob has some ideas about
that with CAVE. To do it right, though, you probably need a fully
knowledge based system of the type that has been mentioned here by Phil G.
and others. That's quite a big jump, and I haven't seen and really serious
development like that yet.
: Fourthly, and most importantly, a chat-only chatterbot is a second person
: character (that is, a "you"), while an NPC is third person
: ("he"/"she"/"it"). It is a person with more that a spoken respons. This
: means that an NPC will *do* things as a response to the chat.
Certainly doable in current games, and has been used here and there, of
course. Frankly, this is a fault only for writers, not the systems,
because it isn't hard to program.
Haha, that's classic. Thanks. :)