In the wake of such ground breaking games as "Galatia," "Photopia," and "Best of Three," NPC conversations have become all the rage. Although there are numerous ways to implement conversations (Emily Short identifies at least seven on her NPC Characterization page) the two dominant forms seem to boil down to conversation menus, and the age-old classic ASK/TELL.
As a developer I have always preferred the ASK/Tell system and most of the implementation of the ORLibrary has been based upon expanding this paradigm. This article, in fact, describes four different models for Ask/Tell implementation, details what purposes they serve in a story, and parallels their use in real life. It is also worth mentioning that, quite by coincidence, one of these models of the Ask/Tell theory lends itself particularly well to a menu interface.
This is an article on the theory of Ask/Tell, and I am attempting to keep away from platform specifics. For this reason, although library modules might be mentioned in passing, no code or implementation will be given here. For those who want more, however, this game is accompanied by a sample one-room conversation game, written in Inform, which bears some meager resemblance to both "Best of Three" and "Galatea." The code for this game, named "Medusa," will compile to both the Z-Machine and GLULX Native platforms. It leverages the ORLibrary framework, and can be found here:
A compiled version of the game (compiled to .Z5 format because it is more common right now than GLULX) can also be found here:
Additionally, to aid in understanding, a conversation map has been created and can be downloaded from the following URL:
For additional implementation information I would suggest the Advanced NPCs articles "Converstation and Learning" available from:
2 Theory of the Ask/Tell Paradigm
How do we, as people, choose what we are going to say to another person? For the purposes of this article I will site four different forms of the human conversation model and relate these to topic based conversations. It is important to realize that each of these four forms of conversation is used in life to serve different needs just as each of these forms of conversation is used in a game to serve different needs.
2.1 The Librarian
The vast majority of IF games use this model. It is a response-only model where the NPC will respond to the player only if spoken to but otherwise does not initiate conversation. In life, this is a model we see in service staff, such as a librarian who does her duties and answers questions but otherwise minds her own business. The advantage of this model is that it is fairly easy to implement. This model has the disadvantage of only being player driven. Creative writing can temper the effect to some degree, but an NPC that simply answers questions isn't really much of a conversationalist.
2.2 The Rambling Idiot
In life, this conversation model is most often used by people who have just met. Particularly with strangers of whom nothing is known, there is little to do in a conversation than to make some random generic statement such as "How about them Yankees?" or "Nice weather we've been having." In a perfect world these little generic bits of conversation will lead to a more personal level of discussion ("The Yankees haven't played this bad since my freshman year of college." Or "Yes, this is great golfing weather!") but until the other person has "bitten," we are just fishing for a conversation.
In IF, the advantage of this model is that NPCs can initiate conversation on their own and do not have to wait for the player to address them. However, if used alone this model has the disadvantage of not "flowing" from one topic to another. Normal conversation tends to progress in a chain of related subjects ("You followed the Yankees in college? What school did you go to?" or "You like to golf? So does my brother."). Without this relation between topics, the randomness of conversational blurbs makes people (or NPCs) appear to ramble as though intoxicated. This could be exactly what the developer is looking for in a character, but for a "normal" NPC, this model alone leaves something to be desired.
2.3 The Lecturing Professor
In life, we use this third form of conversation when we have something specific to say. A lecturer in a class room, for example, has specific points that must be made. As the lecture progresses, the points are made one-by-one until the lecture is concluded. It is possible that the students will keep quiet and the lecture will occur exactly as written on the lecturer's note cards. It is equally possible that members of the audience will ask questions.
When a lecturer answers a question, it can possibly be about related information that would not otherwise have been covered in the lecture. The question could also cover lecture material prematurely in which case those points need not be made again as the lecture continues.
In IF, this third model is ideal for ensuring that necessary information gets conveyed to the player. It is perhaps the most useful technique for writing NPC conversation "scenes" in a story since it conveys the appropriate information, yet allows the player to be as interactive (or not) as he/she desires.
One small disadvantage of this model is that the technique isn't truly "drivable" by the player. That is, there is a predetermined outcome that will come to pass regardless of what the player does. This is most likely what is desired in an IF story anyway, however this model simply doesn't work well for "conversation" games with multiple endings and "decision trees." For art to more closely imitate life, another model is needed...
2.4 The Conversationalist
This final conversation model is the logical continuation of the "Rambling Idiot" model discussed previously. In life, when we communicate with other people, we key into what is being said and keep a running pool of things to Ask/Tell which are related to the conversation. Each statement can have several related topics which, in turn, have their own related topics. Together, these weave chains of interweaving topics (or a "Topic Web") which the player can navigate and be prompted with reasonable, natural statements/questions from the NPC. As an example, let's continue with one of the conversation statements covered previously:
An NPC can be programmed to respond to this statement with a number of related statements, each response having its own set of related topics:
Obviously the advantage to this system is that it allows for complex conversations seen in games such as "Best of Three" that can be driven equally by the NPC and the PC together. As an additional advantage, the concept of related topics is particularly well suited to support a menu. The menu, in turn addresses a disadvantage with the Ask/Tell paradigm as a whole: the difficulty of leading the player in the appropriate direction.
By its very nature, the Ask/Tell paradigm doesn't limit what the player can try to say. This openness of Ask/Tell is both a positive and a negative. It gives the player freedom since there need be no rhyme or reason to what is said to an NPC. If the player chooses, he can play the "rambling idiot" all he wants, but most players will look for clues when trying to determine what to say next. Without a menu, strong hints need to be made. One way to accomplish this would be through protagonist thoughts, but this technique grows more difficult as the number of conversation branches increases. For the four options above, several lines of text must be added:
As with any Ask/Tell system, this puts a fair burden on the shoulders of the author to make adequate suggestions about what the player might say next. Hopefully, with a bit of luck the player will read the above and consider one or more of the following:
Use of a menu system lightens this burden somewhat for both the author and player. This intertwining of menus and Ask/Tell has an additional advantage. Unlike non-Ask/Tell based menu systems, the player is not bound to choose one of these menu items. A menu used in conjunction with Ask/Tell can be exited and the player can "change the subject" by choosing another, non-related topic to Ask or Tell in the conventional manner.
The ease of a menu combined with the power of the command. Now that's flexibility!
As I said up front, this article is about the theory behind Ask/Tell. There will be no code given here that describes implementation. Still, it would be irresponsible of me to simply end the article without some advice on where to go from here.
As a matter of personal preference, I am a big subscriber to the philosophy of reusable code. Most of the work that I do in this area I package into reusable modules and publish it in the ORLibrary. The sample, open source game produced for this article leverages the library and primarily demonstrates the fourth model discussed ("The Conversationalist") with a combined menu system. What follows is a list of pertinent ORLibrary modules that can be used to implement the models covered in this article:
3.1 The Librarian
ORKnowledgeTopic - This is the ORLibrary basis for all information used in the Ask/Tell paradigm as a whole.
ORNPC_AskTellLearn - NPCs derived from this class are given the ability to answer ASKed questions to which they know the answer.
3.2 The Rambling Idiot
ORNPC_Converse - This class instills NPCs with the ability to pick random subjects and TELL them to the player or another NPC.
3.3 The Lecturing Professor
ORKnowledgeScript - a derivation of the ORKnowledgeTopic class. This topic will interrupt the "Rambling Idiot" methodology and force the NPC to iterate through a list of topics (skipping topics that have already been talked about).
3.4 The Conversationalist
OROptionList - A class to support lists. This is not really an NPC component class, but NPCs can be derived from this to give them a "conversation pool" to retain topics for ASKing or TELLing.
ORKnowledgeWeb - a derivation of the ORKnowledgeTopic class. This object exposes a list of related topics that will be added to a characters "conversation pool" when told.