<i>[Ed. note: I exchanged some email with the author of these remarks, and ascertained that the reader thought this was to be the only material on NPC presentation. Given that, I would take the suggestions about further AI and NPC conversation with a grain of salt, since there will be some other discussion of this material elsewhere.]</i>
<P>
First, about the basic structure of the article: It's clear enough to me, and explains some basics about what a NPC should do and how it could be coded in Inform/TADs.
<P>
However, I immediately began thinking about some books/articles the author either might wish to cite, read, and/or include in his/her discussion:
<P>
- Chris Crawfor'd latest book on Interactive Storytelling and his work on Erasmatron
- Richard Bartle wrote some good articles about AI planning in http://www.skotos.net/articles/. They're the later parts of "Notes from the Dawn of Time Column... "
- Informaiton about AIML for creating chatterbots
- Some notes about AI state machines, as well as planning, and perhaps fuzzy state machines. I just read a good book on game AI, and I can get you the title. The book doesn't conver conversations though.
<P>
<P>
Which leads to another issue which I don't think you'll be able to deal with in your book: Inform and TADs do not have the infrastucture necessary to handle decent NPC architecture. I've been dealing with these issues for my authoring system, so let me describe the modules, as they are brought up by this article:
<P>
<P>
State machines - The article describes a simple state machine. I created a stack-based state machine (not sure if that's the right technical name) that allows several "goals" to be running at once. (A goal is a state machine.) Each goal has a priority. The highest priority goal gets to act, and continues to do so until it lowers its priority or it finishes. (A goal can raise its own priority based on circimstances).
<P>
For the example of the NPC setting up shop, there would be a goal of the NPC spending 30 minutes preparing, 1 hour cleaning, 1 hour making ice cream. When the goal got to cleaning, it would create a sub-goal that would do all the cleaning tasks; the sub-goal would return control to the main goal when it had finished cleaning. Cleaning tasks might include their own sub-goal.
<P>
Another example: I have a "goal" that causes the NPC to walk from point A to point B. It automatically uses A* to determine the best path. If there are any doors in the way, it automatically opens them, walks through, and closes them. It will even unlock and re-lock the doors. At some point I'll modify the goal so the NPC can automatically solve any puzzle's in its way, such as pressing the red button to open the door. (The author will need to tell write code so that NPCs will know to press the red button, though.)
<P>
A parallel goal would be running that would cause the NPC to notice any PCs entering the room and say hello. If the PC said hello back, another goal would be added to the system causing the NPC to wait N turns for the PC to respond. If the PC didn't respond, the NPC would abandon the wait-for-PC goal and go back to whatever goal it was doing. This system is much less hack-ish than the one described in the article. But, Tads/Inform can't handle it.
<P>
<P>
Descriptions - TADs/Inform have a magical "player" object, and all other objects. Because of this, you get description problems described in this article. The author has to make sure the players aren't told, "Fred cleans his icecream shop", if the players aren't around. The root of the problem is the "print ()" statement. The print() statement need to be modified to only notify the occupants of the room.
<P>
<P>
Natural language processing - The way AIML handles parsing makes for easier conversations with NPCs than the way Inform/TADs do their parsing. The way AIML interprets the parse isn't as good though. What you need for a conversation system is a NLP front-end that converts an english sentence into a simple command. For example: "Hi, how are you?" or "Howdy there" -> "`hello". "Do you have any ice cream for sale?" or "I want a cone, please." -> "`areselling `icecream".
<P>
The article seems to gloss over the problems that players will have when trying to talk to NPCs. The problem is that there are N ways to rephrase "drop the nasty knife", but M (where M is much more than N) ways to rephase "I'd like a vinalla ice-cream cone." This has to be dealt with through a number of mechanisms:
<P>
a) A better parser. Plus, it has to be very easy for the author to add in hundreds of different phrasings.
<P>
b) Having the NPC say "I'm sorry, I don't undersatand. Do you want to buy an ice cream cone?", or some wording that causes the player to rephase their request in the right manner. Speech recognition systems commonly use this trick to get listeners to say in-vocabulary utterances.
<P>
c) Keep a log of everything beta testers type in, and fine-tune the NPC's vocabulary accordingly.
<P>
<P>
<P>
The conversation - Having a conversation with a NPC is like wandering through a complex of rooms. Instead of a room being something physical, a room is a topic of conversation. (Furthermore, the player might be in several rooms at once.)
<P>
For example: The first "room" is the greeting. Upon entering a "room", the player can say something that not only evokes a response from the NPC, but also moves to another room (topic of conversation). The NPC then has the opportunity to say something that's on its mind. The NPC's resposne potentially moves the converstion to another room. The player then his chance at the conversation and directs it to yet another room.
<P>
Basically, each convesation has a state or set of states, such as "expecting hello" or "talking about the weather" or "talking about sports". (A state corresponds to the "room" that the conversation is in.) The player's raw text is interpreted based on the context: An obvious example of this is if the player just types "Yes". What does this mean? It depends upon the current topic of conversation: "Do you like green eggs and ham?" or "Do you think Sally is cute?"
<P>
The NPC also needs a list of "questions", or items that it might bring up when it gets a chance. Each one has a score that's based on how important the question is, as well as how well it relates to the current conversation topic. For example: A NPC might say "It's sure is sunny." with a score of 0.1 and for any topic. If the topic is sports, it will say "Don't those Yankees suck this year!" with a score of 0.5. Or, if the topic is about rings, "My aunt once had a magic ring." with a score of 0.5. Thus, if the NPC can't think of anything to say, it'll talk about the weather. (Each question is only brought up once per conversation.) But if the PC directs the conversation into sports or magic rings, he'll get more interesting information. If the NPC has something very important to tell the PC, such as "Mad Dog Mahoy is out to kill ya!" then this would have a very high score, so high that it would be brought up no matter what the topic of conversation is.
<P>
This makes conversations more realistic, although far from perfect. Conversations are no longer a player-driven interrogation. Instead, it's a two way interaction (or duel) where the PC asks a question. The NPC answers, and potentially asks its own. The PC answer back and potentially asks his own.
<P>
<P>
Like/dislike, trust/mistrust, and emotions (happy/sad, anger/fear) - I also have these implimented, although they may not be as relevent to the IF that you're thinking of where only a handful of NPCs exist in the game. Like/trust and emotions also tie into a conversation model.
<P>
<P>
Questions to ask a PC - There are many more questions than the ones listsed... I have a list I've been writing up, although it's may not be strictly appropriate to IF. For example: One of the questions is "Do you like NPC Y?", and "What does NPC Y do?". Also, a PC might ask "Do you like my necklace?" to see if the NPC likes jewelry, and use that information to conclude that giving the NPC jewelry will make the NPC like the PC more, and perhaps reveal more information.
<P>
<P>
NPCs talking to NPCs - Another issue. Chris Crawford's book discussed this in great detail.
<P>
NPCs remembering what they told to the PCs - Very useful.
<P>
NPC emoting to the PC - If a PC says something that upsets a NPC, the NPC needs to emote. Same for making the NPC happy, arousing the NPC's interest, etc. Likewise, if the NPC "Takes a sip of coffee," how does that illustrate the NPC's emotional state and feelings toward the PC?
<P>
PC emoting to the NPC - Does a "wave at NPC" count as a "hello"? If the NPC tells a joke, can the PC "laugh"?
<P>
NPCs with common knowledge bases - Every NPC in the village should know where the inn, bank, and grocery store are.
<P>
<P>
<P>
Some other comments:
<P>
- The introduction to the article talks about how characters are important to a novel/story. It then ties this in with IF, unintentionally implying that such wonderful characters can also be created in IF. The fact is that until AI gets very good (many many years from now), computer AI will be uninspiring. The trick is to know what can be done well with the current technology, and what is too difficult for the technology to do.
<P>
- The more controlled the conversation is, the more realistic the author can make the character appear. BUT, some players may dislike the lack of control. Example: Linear fiction can make characters appear to be very real, but players can't interact at all. A fully interactive NPC with no predetermined conversation context will allow the player to ask anything, and will very-quickly show off the NPC's stupidity. For every NPC, the author must decide where the tradeoff between realistic-NPC and player-interactivity is optimum.