I’m not sure if this is the right place for this, as this forum tends to be used more for questions and assistance, but I figured it is a general “Quest” forum, so it will work for now.

I wanted to start a dialogue (no pun intended) about conversations. Part of this is philosophical/theoretical, which can be fun on its own, but I also wanted to possibly work toward the creation of something new – a Quest conversation engine.

First, the idea bantering phase… So, what exactly do I mean by a conversation?

Part of that should be fairly obvious: the player having communication with other characters (also known as “non-player characters” or “NPCs”). There is already code in Quest – plus an extended such library written by The Pixie in the “Libraries and Code Samples” forum – which supports basic “ask” and “tell”. This takes the form of something like “ask Mary about George” or “tell janitor about fire”. You have a target character and what’s known as a “topic”. Typically, this basic implementation responds with a fixed response (e.g. look up string “topic” in character’s “ask” string table), with an occasional implementation of selecting randomly from a set of fixed responses.

But we usually want more…

There have always been questions, wishes, requests for NPCs to be more interactive. Now, this is black art at this point, and I don’t propose to have a definitive answer (maybe we can move toward that through this), but the point is, game author’s want more dynamic responses, based on any number of variables including previous topics, the time of day, what has occurred in the game, the state of play, and possibly even the emotional state of the character.

My own (limited) game design and wishes took me further.

Consider related desires. It has often come up that author’s want, say, room descriptions to change based on, well, more or less the same things listed above (though emotions come into it less). Similar design choices could be made for object descriptions, NPC descriptions, etc.

I had this revelation one day, as I began to see patterns in this. It finally occurred to me:

In a text adventure (or “interactive fiction”), everything is a conversation.

Let’s list some examples.

1) NPC conversation. The player wishes to ask characters in the game about things, requesting responses to topics. The character responds with information (or some non-committal shrugs or “I don’t know”, if not).
2) Room descriptions. The player makes queries to the game about the room. We ask the room, “Tell me about yourself,” and it responds. This extends as well to scenery. We often will put scenery objects into a room just to hang descriptions off of. These are not interactive objects as such – they exist in the game framework just so the user can type something like “x carpeting” and get a response. In the mindset of conversations, this could be thought of as asking the room about its carpeting. (In other words, the room is the character we’re conversing with, and the “carpeting” is the topic.)
3) Object descriptions. Similarly, when we “x” an object, we are asking it to describe itself.
4) NPC descriptions. Sort of like object descriptions but with a different feel.
5) Hints. Hints are really a bit of a one-way conversation, a running commentary by the game on what you’re doing. Certainly, there could be a “hint” command that forces a response, but there is also the system whereby hints are offered unbidden at the appropriate times. This, in a real sense, is the game conversing with you based on the state of play.

So you might be wondering why I’m trying to lump everything into conversation. The reason why was mentioned before: because we want all of the above things to have a certain dynamic to them, and that dynamic is common across them. We want them to not be static. We want them to change over time, not only randomly but in response to the game world. In a very real sense, as we are playing a game, we are in a conversation with the game itself, and we want this conversation to be alive and engaging.

Currently in Quest, the above areas are handled separately. Room, character and object descriptions (well, rooms and NPCs are objects, after all) are handled via a “description” attribute, which can be a string or a script. Ask/tell are handled via string dictionaries. And hints are basically “roll your own.” Which means that if you wanted to add dynamic responses for all of them, you’d need to implement separate code in separate places.

I’d like to change that. I know in my games (largely contemplated and only minimally implemented, mainly due to wanting too much), I have made stabs at implementing the above pieces.

One example: I wanted my rooms to have “directional descriptions”. By that, I mean that you would get a different description depending on which way you came into a room (or “area”). As an example, let’s say you’re outside in a clearing and you see a path to the north, so you type “n”. A stock description once you get there would be “You’re on a path. To the north, you can see a pond. A clearing lies to the south.” That bugged me a bit. Of course a clearing lies to the south – I was just there. I have walked north. In my head, I’m facing north.

What I wanted was that if you came north onto the path, it would say something like, “The path continues north. You can see a pond in the distance.” Whereas, if you came onto the path from the north, heading south, it would say, “The path winds further south, leading to a clearing.” Now, we can get into debates about where the full set of exits is listed. My option was to have a ubiquitous “exits” command that would dump the out (e.g. “You can go north and south.”) There are other ways to do it. But the point is: the game responds in context. To me, that is much more immersive than “push level B and get response Q”.

Now even if directional descriptions don’t make sense to you, other things undoubtedly will. For example, if you have a game that spans days within the same environment, you might want the descriptions to change based time of day or what the weather is. A whole host of possibilities come up. The same might be true even of NPC descriptions: in the beginning, the sidekick is immaculately dressed in blue. After the flight from the enemy agents, her top is torn and her hair is askew. The next day, having changed, she’s in black jeans, and she has donned a graying wig and wrinkled skin prosthetics like in “Mission Impossible.”

How would you do all that? Lots of “if” statements? I must confess – I love writing code, but it makes my skin crawl to write lots of special-case code, because it’s incredibly brittle and requires all sorts of mental gymnastics to keep straight. I’d rather write some nice general, data-driven code that seemingly by magic does the right thing.

So now we’re down to the proposal part – I’d like to begin working on a community Quest “conversation” engine. Not a library. Not “ask/tell”. I mean a full-on, topic-based, evolving over time sort of engine that anyone can use and enjoy. To that end, I’d like to get any thoughts that people have on the subject, any design considerations, possibly even any code designs that you’ve tried yourself. For anyone who's interested, let's put our heads together (and chickens are welcome as well as pigs - if you don't know what that means, either skip it or look it up).

There are different approaches to NPC conversation, but I want this engine to be something that can be used universally in a game as well as (on some level) for all those things listed above. Perhaps that’s too big an ask, but I want to set the bar high going in. Then we can see where we get to.

I’m going to follow this post up with some of my own (soon), but I wanted to get this started. And if this thread belongs elsewhere, please let me know!

Interesting idea, but I can't catch it at the moment. Perhaps I wouldn't call it conversation. "ask xxx for yyy" is not a conversation, it's just a question (in my opinion!).
So I will wait for your next posts

Ok, let's not get hung up on terminology. Let's just call it "rich, dynamic responses to player queries or actions". But, yes, more thoughts coming soon.

(First of several parts)
What we will call “conversing” (I’m going to stick with that, as perhaps it will someday become more like that) is in reality selecting text to display to the user – choosing something for a character to “say” - either in response to a query (direct trigger) or based on conditions (indirect trigger).The trigger might have a topic or topics associated with it (e.g. a query about a topic), or the trigger might be neutral (e.g. a hint engine that runs on each turn searching for phrases to present, or a particularly chatty NPC who offers up information in his/her own when the time is right).

How do you select what to say? For things like object/room/character descriptions, the standard is either a hard-coded string or some code which typically selects and assembles the output based on whatever specific logic is programmed in. For something like ask/tell, the implementation is a string lookup in a dictionary.

That is the current state-of-the-art in Quest. There’s any number of ways to go as far as how we can implement string selection. I’ll cover a couple of directions I have explored.

Boolean Logic

The most straightforward is to implement some sort of hard “yes or no” selection. That is, we look through the available phrases and see which ones match. Either a phrase matches or it doesn’t. What to do if more than one matches depends on the situation (and so complicates things a little bit). For interactions with an NPC, you’d probably want it to spit out a phrase at a time in response. You could randomly select one, for example. Another possibility is to show all matching phrases.

The latter is what I did in my room description implementation. Each room could have various “topics”. A topic would then have conditions. Standard topics included “base” (the base description), “first” (text to show the first time), “later” (text to show when not the first time), “north”/”south”/”west”, etc (text to show based on arrival direction), etc. Custom topics could also be added, depending on conditions and needs.

A sample room might have text like:

<baseDescription>"This is the second floor landing."</baseDescription>
<westDescription>"Further to the west you can see an archway leading to another hallway. A broad staircase leads up and down."</westDescription>
<eastDescription>"The hallway continues east. A broad staircase leads up and down."</eastDescription>
<upDescription>"The stairs continue up. A hallway heads off to the east, and through an archway to the west, you can see another hallway."</upDescription>
<downDescription>"The stairs continue down. A hallway heads off to the east, and through an archway to the west, you can see another hallway."</downDescription>

The description would be a combination of the base description and any directional ones. So, for example, if you move west to get the landing it will show:

This is the second floor landing. Further to the west you can see an archway leading to another hallway. A broad staircase leads up and down.

which is a combination of the “base” and “west” descriptions. (The fact that strings are surrounded by quotes is due to the fact that I would “eval” the attribute to get its real value. This allowed me to put expressions in the strings.)

Here are some of the conditions (in the base room type) that trigger the various pieces:

<baseCondition>true</baseCondition>
<northCondition>lastdir="northdir"</northCondition>
<northwestCondition>lastdir="northwestdir"</northwestCondition>
<westCondition>lastdir="westdir"</westCondition>
<firstCondition>not GetBoolean(room, "visited")</firstCondition>
<laterCondition>GetBoolean(room, "visited")</laterCondition>

Now, this is all well and good and works fine for rooms. The conditions can vary, and the text shown will vary accordingly. But it is very static. What it’s missing is any sense of history, any inclusion of what has been shown (to some extent, what has been “discussed”). For NPC interactions, I wanted more.

Fuzzy Logic

Moving beyond the yes/no, hot/cold, show/don’t show of binary, Boolean logic, we arrive at another alternative – that of fuzzy logic. I have only toyed with a test implementation of this; with no real world uses, it might end up needing some more design to make it all work properly. I’ll describe what I have considered so far.

The basic idea behind this is the notion of a current “conversation context”. This context holds information about the current set of topics. This set of topics changes over time as different topics are explored.

Each NPC would have its own conversation context. Each possible phrase would also have related topics. Triggering a phrase will update the conversation context, which will then influence subsequent phrase selection. Let’s see how this might work with an example.

Here are the phrases. The first part is the string. After that is a list of topic weights associated with that phrase. Weights range from 0 to 100. (There might be a use for negative weights as well.) I hope this isn’t too contrived…

[id=1] “My father was a farmer.”, father=100, farming=100, family=50, history=80
[id=2] “I grew up on a farm.”, farming=100,history=80,home=100
[id=3] “My brother’s name is John”, brother=100, family=50, john=100

Let’s look at these a bit. For the first one (“My father was a farmer.”), we have the topics “father” and “farming” being a strong match. The topic “family” matches 50%. The weights have two purposes:

1) They help in matching by showing how much a topic matches the phrase.
2) They are used in modifying the conversation context when they are used. (More on this below.)

The idea behind 2) is that our minds are very associative - when we discuss topic "A", it brings in other related topics ("B", "C", and "F"). We want to have a similar behavior in our phrase selection.

Initially, the conversation context is empty. Nothing has been discussed.

Context = {}
Let’s say the player enters “ask about father”. Due to this, the “father” topic gets injected into the current conversation context:

{ father = 100 }

Now, we search. The search is done by generating scores for each phrase via a sort of “dot product”. (If you don’t know what that is, don’t worry.) Basically, we multiply the context with each phrase’s topics and generate a score. In the following, the first number multiplied is the value in the context; the second number is the number in the phrase weights. A missing weight has value 0.

[id=1] score = (father) 100*100 + (farming) 0*100 + (family) 0*50 + (history) 0*80 = 10000
[id=2] score = (father) 100*0 + (farming) 0*100 + (history) 0*80 + (home) 0*100 = 0
[id=3] score = (father) 100*0 + (brother) 0*100 + (family) 0*50 + (John) 0*100 = 0

In this case, phrase 1 is the clear winner. If the topic were “brother”, I hope it’s clear that phrase 3 would be the winner.

Let’s see what happens if we have “ask about family” as the topic. In this case, the context would be {family=100}. Running scores, we get:

[id=1] score = (family) 100*50 + (father) 0*100 + (farming) 0*100 + (history) 0*80 = 5000
[id=2] score = (family) 0*0 + (farming) 0*100 + (history) 0*80 + (home) 0*100 = 0
[id=3] score = (father) 100*50 + (brother) 0*100 + (John) 0*100 = 5000

In this case, both phrases 1 and 3 match “family” about the same. What happens is to be defined. Either it could spit out one phrase (chosen randomly perhaps, or in order), or it could spit the both out (“My father was a farmer. My brother’s name is John.”).

Let’s go back to the “father” case. In that case, we would have a result of phrase 1. So the NPC would say, “My father was a farmer.” Based on standard human conversational associations, we would want to update the conversation context with any related topics brought in due to that phrase. I’m not sure of the ideal algorithm for that. For this case, let’s assume we generate averages. (A better weighting scheme might make more sense.)

Context = {father = 100}
Phrase = {father = 100, farming = 100, family=50, history = 80 }

new “father” = (100 + 100)/2 = 100
new “farming” = (0 + 100)/2 = 50
new “family” = (0 + 50)/2 = 25
new “history = (0 + 80)/2 = 40

New Context = {father = 100, farming = 50, family = 25, history = 40)

This is now the current conversation state. What I had wanted was for NPCs to be able to initiate conversation as well, not just respond to player queries. If the player were idle in this case, the NPC might decide to come back with its own search for something to say. Performing the search again with the current conversation context (let’s assume we won’t repeat a phrase), we get these weights:
[id=2] score = (father) 100*0 + (farming) 50*100 + (family) 25*0 + (history) 80*40 + (home) 0*100 = 8200
[id=3] score = (father) 100*0 + (farming) 50*0 + (brother) 0*100 + (family) 25*50 + (John) 0*100 + (history) 40*0 = 1250

In this case, phrase 2 matches, so the NPC will follow up with: “I grew up on a farm.” After this phrase is uttered, the conversation context will be updated to:

New Context = {father = 50, farming = 75, family = 12.5, history = 60, home = 50)

Note that we didn’t discuss “father” again, and so its weight has decreased. Also note that farming has been emphasized. And we now have a new topic (“home”) which may trigger additional, subsequent phrases.

There are many variants to this, possibilities for manipulating the parameters. Perhaps the new conversation context should not be a simple average but a weighted one. Perhaps the conversation context should “decay” over time, if there is no conversation (that is, if you cease talking, the weights gradually move to 0 and disappear with each command). Perhaps a new topic injected should enter into the context with some lower weight than 100. As far as not repeating phrases, perhaps the “memory” of a phrase being spoken decreases over time (possibly at a rate determined by the age of the NPC), such that it will eventually be repeated. There would also need to be some determination of what to do if either no phrases match (“I don’t know about that”), or all matching phrases have already been spoken (“I don’t have any more to say about that.”)

There is one downside to these weights which needs to be addressed. A queried subject might want to be searched more forcefully than one where the NPC follows up on its own. For example, after “ask about father”, if the player enters “ask about the moon”, it wouldn’t make sense for the NPC to come back with “I grew up on a farm” (which it would if straight weights were used and the priority of the topic wasn’t taken into account). One way to work that out is that a new query from the player generates a new temporary search context with just that topic, with the weights from any chosen phrase adding into the current context afterwards.

Next: Bringing in the world state, the best of both worlds, and some emotions.

(To be continued)

This is really awsome
Well, I don't understand all the coding aspects, but to have more interactive npcs and rooms as well is high on my list to achieve in my quest games. Granted, I have a long way to go and I'm still struggling with the basics, but dynamic npcs would be a long-term goal for me ^^

I read Emily Shorts article about that: http://emshort.wordpress.com/how-to-play/writing-if/my-articles/conversation/ It's very interesting.

Your approach with topics having certain weights depending what the player said does sound intriguing. Maybe the npc can have different mood/emotion conditions that can increase or decrease depending on the topics he/she is is asked. For some npc maybe a 'war' topic or the name of a lost one can trigger a sad mood (or increase the sad mood until a threshold is reached and the npc is now in a sad mood) or maybe trigger an angry mood if the see the player take an object in their room, something like that. The different moods would result in differend response, in refusing to answer some questions, maybe even in attacking the player or doing other actions (leaving the room, hiding an object, attacking another npc etc.). You could even have an affection level for the npc in order to court npcs. How you would call it doesn't matter. It would be simliar to the weight score, but maybe with a more lasting effect, opening a whole new palette of npc reactions.

I think npc could make great puzzles. Figuring out what to ask a npc and how could be the key to a puzzle. To calm or persuade a npc with an object he/she likes or a favorite topic. Giving objects to npc could unlock new topics as well as achieving various sub-goals in the game, for instance if the player cures another npc, maybe the father, the son could have new reactions. And if you add to that the possibilty to talk (or lie) to one npc about another npc, the conversations can become very complex and dynamic.
I do believe one or more of this ideas were already implemented in some games, I'm just brainstorming a bit

But I think this is very hard to implement. I wouldn't even know where to start. I don't even know what differences exist between libraries, dictionaries, lists etc. At the moment I can just contribute with general ideas and feedback.

I do hope you continue to share your ideas with us ^^

Thanks for the comments. Yes, that's an interesting article. (I had read it before, but it's always good to review. ) I think we need to factor in the "effect" part as well. But then, we need to factor effects into all of a player's actions, so why not what is said?

One thing to note is that what I'm discussing here so far is largely how to make the NPC respond contextually (and, by extension, anything else you'd want to apply this to, like room descriptions, etc). The input side - how the player actually gets topics into the system - is a whole 'nother thing!

Assuming what we have been discussing so far actually works, then we now have some sort of scheme for modeling an evolving conversation. It does mean that you as the author have to actually go in and create all the response phrases – and decide all the topic weights. While the thought of having NPCs actually generating utterances on their own (putting words together to form coherent sentences) is a wild pipe dream, that is not what we’re talking about here.

(Aside: In Emily Short’s article listed above and in her other ones, she uses the word “quip” for what a character says. While that is a bit of a fun word, it had a connotation to me of levity which I didn’t think was generally applicable. So, being the programmer that I am, I am going with the more generic “phrase”. Even that might not be entirely accurate, but we need something.)

What we have gone over attempts to address selecting phrases based on topics, but it’s fairly self-contained. The only inputs are topics. We also want to interact with the game world, to somehow have the world state influence phrase selection.

By “world state,” I mean pretty much anything of interest in the game world. It can be things like:
- where the player is
- where they have been
- what they possess
- what they have possessed
- whether a murder (or some other significant event) has occurred
- the time of day
- the presence or absence of other NPCs
- the emotions of the various NPCs
- who has just walked past in the corridor
- choices the player has made in the past
- anything else relevant to the story being told (or the puzzles therein)

You could, in theory, use weights for that, and inject state in as topics. I tried that for my room descriptions at first but quickly abandoned it. There are two problems:
1) You need to create a topic for each piece of world state (“has_stake”, “visited_crypt”, “saw_vampire”, “killed_vampire”, etc or, in my case, “east”, “west”, “north”, etc ), which can quickly become unwieldy.
2) Such state is typically binary – we only want certain phrases to be eligible when certain conditions are true. In order to do binary in a weighted scheme, you have to not only add weights for what you want but also (short of some notation which I tried and gave up on) add negative weights for what you don’t want, to prevent the phrase from being selected when those topics are present. It’s possible but, again, quickly becomes painful.

What I have come to is that we want to somehow utilize both schemes, “binary” and “fuzzy”. The “binary” part would be used for phrase eligibility, based on world state; the “fuzzy” part would be used for selecting from among the eligible phrases, based on topic or other fuzzy considerations. This is the next area of thought for me, so I don’t have any ready answers yet. Perhaps some sort of uniform notation could be adopted. I’m open to that if it would work; in fact, I’ll probably revisit it myself, as I like to unify things.

One piece of “world state” we might want to consider is the emotions of the NPC. For example, if I ask a character about her father, if she loves me, she might respond, “I can’t wait for you to meet Papa!” whereas if she is feeling antagonistic towards me, such queries might be met with, “That’s none of your business!” or something even more venomous. Whether such state is “hard” (binary) or “fuzzy” is really a question of design, depending on how the emotions are modeled. That’s another discussion to be had. It could be implemented as simply (but crudely) as a boolean “inLove”, if that’s all you care about, or as a variable “loveState” ranging from 0 to some upper number, or as a scale ranging from hate to love. You can also have different ranges for different kinds of emotions. The point is: you will need to determine how that is going to be modeled before you can decide how to integrate it with a conversation model. Hopefully, if this all comes together, you’ll have plenty of flexibility to do it the way you want.

A random, somewhat related thought: this one's about room descriptions.

Typically, room descriptions are centralized. When I say "look", it goes to the room object (in Quest) and says, "Give me your description", and that description is either a string or a script. And there is boilerplate code that dumps out the objects in the room, the exits, etc.

Now, let's say that conditions can change in the room. Maybe a chair is there sometimes and other times not. How do you handle it?

The typical way in Quest is via an "if". You make your room description a script, you dump out the stock part of the room description, and then you put in an "if": "if the chair is in the room, also print *this*". It's all a bit clunky, and it's also rather centralized. The room has to know about the possibility of the chair. It's all very static, very hard-wired, very brittle.

Let's turn the notion on its head a bit. What if we look at the command "look" as an invitation from the player for description, which goes not just to the room but to all within it. Now, instead of the room having to know that a chair is possibly there in order to add in custom text, we will have the room respond with its description and we'll let the chair chime in as well with its own description (with such description being the minimal "There is a chair in the corner" sort of thing, with a full description forthcoming if the player directly queries the chair further). And if the chair isn't present, well, then nothing is there to say it. Imagine the room saying in a booming voice, "You're in the library" and then you hear a small voice from the corner say, "There's a plush chair in the corner." They get written out together in one block of text. Now, instead of a single voice, we have mutiple voices all responding together. Instead of having to put "To the east, there is a foyer", the east exit will itself add in the text to alert the player to its presence - if it wishes. "Hey look! You can go this way."

A bit bizarre on first thought, perhaps, but I really like this sort of thing...

If I understand the purpose of this, is to:

make a more comprehensive~massive library~engine dealing with all types of "conversations" (npc objects and their dialogue topics, room object descriptions, and etc) and their changing (dynamic'ism) based upon factors (other previous dialogue responses, events~flags like time of day or whatever else, attributes ~ set plateaus i.e. at 100 degrees Celsius = water boils i.e. if npc.hostility > 50 or = string values like "hate ~ angry ~ hostile ~ war" then npc attacks you ~scales ~ ranges ~ weights, and etc).

first, how should we do this? We've got a few different methods of doing so, as a...

1. Library
2. Scripting (a library-like massive "engine or kit" script~s that creates the "conversations" for the game player, though, I'm not sure how this could be converted for the game maker, lol. Well, actually, this is probably akin to making the core scripts, so maybe it could be done... maybe)
3. Tabs (using the GUI~Editor)
4. ??? (Are there other options?)

--------------------------

I'm still learning to use the Tabs well, so I can't be of too much help. I know nothing yet of string working, their script lines, nor of string logic, as I haven't tackled in learning ~working with~ this yet, so I can help much with Jaynabonne on this, either. I'm not good enough to construct a library, as this is a massive project, even if I could build my own library for simple things.

--------------------------

We'd need to hash out all the aspects involved, which this seems to be also a part of the intent of this thread, but I think I kinda got an idea of how to do this, via scripting (nothing special, especially for you coders, but it's cool that I think I get it well enough to have these ideas of mine, lol):

Actually this "Scripting" would work like a "creating your own conversations within your game, as the game player, lol. create your own world, as the game player, hehe"

A quick and very incomplete and improper formatting example only:

<game name="blah">
  <start type="script">
    conversation_creation_function
  </start>
</game>

<function name="conversation_creation_function">
  msg ("What thing do you want to make a conversation for?")
  show menu ("room_object;npc_object;data_structure_object;list;dictionary",";") {
    actor = result
    switch (actor) {
      case ("room_object") {
        create object
          room description dynamic script block
      }
      etc etc etc
    }
    (looping_start)
    msg ("What dialogue choices do you wish to create for your choosen thing?")
    actor.topics = new_list_/_dictionary
    get input {
      add list/dictionaryitem (result)
    }
    etc etc etc
    (looping_end)
    (looping or cancel=done)
    etc scripting (whatever other aspects that are needed to be addressed)
  }
</function>

---------------------------------------

this is actually a cool idea... that should maybe have it's own thread, as it's a grander project:

instead of merely creating an in-game (by the actual user playing the game) creation of conversation, they'd create their own game and world, hehe.

making a game, that allows the user playing the game, to create their own game (a KIT or an in-game core engine/GUI/Editor, hehe). Now, that's the power of quest!

You know, this sort of thing is an amazing idea. I can't say that the vast majority of text adventure would really benefit from such a thing being created: those worlds, as exciting and diverse as they may be, aren't so dynamic that there would be a big difference.

A system like that is so dynamic and intricate, it could almost be a game mechanic in and of itself: you have to establish the correct contexts before a character will divulge the information you want in a spy game and so forth.

But I've also had ideas that could benefit greatly from such an engine. In the Collaborative Quest Project topic, I've outlined an idea I had for a game that almost needs a dynamic engine like this. In fact, something like this could change the fact that games largely don't need it: they don't provide this sort of flexibility out of necessity, not for lack of want.

I've experimented with a lot of conversational stuff before. I've made a character in which you're forced into a multiple-choice style conversation and whether or not they like the responses you pick becomes a factor at the end of the conversation.
The ability to have dynamic room descriptions is an intriguing one as well: if you can make room descriptions dynamic you no longer have to come up with an excuse for why the player can't push a chair around the house. They can, and the rooms in which is was and will be will change their descriptions in accordance with that action.

Addressing your points about conversations with NPC's: I always tend towards binary logic. I am very well aware of the mental gymnastics that can go into coding dynamic conversations with characters: you should see the size of the switch statements I've written. Nonetheless, it could be an extended balancing act to make something like the fuzzier logic to work, and in the end I don't think it would fare any better than well-implemented binary.

For instance, you have topics with weights and these weights represent a topic's relevance with respect to what the player asked about. It's a novel idea, and it flows wonderfully: you can track a topic's relevance throughout the conversation on a scale of 1 to 100. But I think that the power of the system would be wasted in almost every case (except maybe for a game that is entirely a single conversation). Consider a similar system with binary logic:

Every topic either pertains to a topic or it doesn't. Using your examples:
[id=1] “My father was a farmer.”, father=true, farming=true, family=true, history=true
[id=2] “I grew up on a farm.”, farming=true,history=true,home=true
[id=3] “My brother’s name is John”, brother=true, family=true, john=true

With this system, anything that relates to a topic is valid, although it isn't any more valid than any other response. This might limit how dynamic a conversation is, but I think not, and I would point to the fact that each one of these phrases has a topic that pertains only to that phrase. Now, I think your intention was to imply that these three phrases are but a few in a very large repertoire of phrases that will all share topics, but I think that leaving some topics unique could make this system work well.
The benefit I see immediately from this system is that you don't have to come up with a complicated (and more importantly, imperfect) algorithm to figure out what phrases will be a response to what inputs. If the player asks about family, they'll hear about the farmer's father and/or the farmer's brother. As far as context, it would be a similar system. The topics that are associated with phrases would become contextual topics, and the others would remain false. Deterioration in topic relevancy could be done after a number of turns: if a topic hasn't been discussed in so many turns, it becomes false again as well.

I prefer binary systems like that because of how straight-forward they are about what you're getting when you type in a certain phrase. It would be an enormous feat to make all the responses make sense after the player has been playing with the context algorithm for a short while. I'm not sure that the binary system defeats that more readily (it could exacerbate that particular grievance), but I would prefer to work with that than work in weights that are averaged and deteriorating.
Then again, I hate such organic systems--even though they work better than almost all others.

Hopefully I've added something to conversation here, but I feel like I've simply restated something in a different way. Maybe this will be more clear to those who had trouble digesting the pseudo-code above.

HegemonKhan: As far as the methods to do it, I think it would be all three of what you list - scripts in a library and probably using tabs to expose it to the author. Regarding your other idea, I find it intriguing to be able to not only interact with a world but also to create within it. It should be fairly simple to do what you're saying. I'm looking forward to seeing where it takes you.

homeeman: I really appreciate your comments. Even if it's a different emphasis from mine (going with more binary than "fuzzy"), I don't mind considering it, as it's really, in the end, about getting something that works and is usable by game authors. As I implied before, I initially tried to use weights for my room descriptions and gave it up because it wasn't working. So... It could be tried both ways. To be honest, it would be easier to author if you just attach multiple topics to a phrase (you wouldn't even need the "=true" part - just presence would be sufficient) as opposed to having to assign meaningful values to them. And believe me, I'm on board about the need for reproducability and full coverage in testing.

This is good food for thought. I still think we need to distinguish "eligibility" in a world state sense from "topicality", as someone might bring up a topic (or trigger a phrase) that doesn't make sense in the current game context. But perhaps it can be rolled in somehow.

Thanks again, and now it's time to think some more.

By the way, throughout all this, I'm pretty much assuming I'd be taking the first stab at writing this. I'm not excluding anyone who wants to contribute code, but I'm also not reaching out to others to write as such. I'm more trying to get a feel for what people would want, to pick up any requirements or ideas I may have missed, and to get called out on anything I might be completely off base about. Also, if it drums up interest or even excitement, that makes it that much easier to dive into. If it's just me, then I'll go off and write my own offbeat games at a different pace. So any comments are welcome. Keep em coming!

These are all interesting ideas that I definitely think have potential but I just want to go back for a second to the implementation of such a system on room descriptions.

The way I see it, there are different facets to any game which can be broadly divided into 3 categories, very closely related to the 6 aspects of storytelling in general- the who, what, where, when, why, how. There's the logical aspect, the puzzles you create, the skills required to complete them, and what you're asking the player to actually do in order to progress the game; these constitute the how. Then there's the narrative, the story you're creating that sets the logical aspect in context; the what and the why of what they're trying to achieve. Finally you have what this aspect of the proposed system would control- The stage it is all set in, the world you have created and the characters and objects that comprise it; the who, where, and when.

Text games have one additional aspect though that's not so important in a visually oriented game and that is language. An object in a picture just is or it isn't, you look at it and all the conditions of an object can be applied or not based on certain inputs and be displayed as generated by a logical computing system. Text is a different matter. Language has a rhythm and fluidity, sentences can be aesthetically pleasing or clunky and jarring in a way that's subjective and not easily recognised by a logical set of standards. Which is why "The Da Vinci Code" is an OK book with its puzzles and twists, but "The Picture Of Dorian Gray" is a classic.

So to get to point (in a rather long winded way) you could have a system set up whereby each object pipes up and announces its state upon entering a room, but to then arrange all those inputs in a way that doesn't just become a slightly verbose list of things in the room would require much as much testing and revision as simply using "if" scripts in the first place. Creating an environment that is engaging and interesting to read about requires much more than that and the type of author that would want to make use of a dynamically changing world to enrich their descriptions would be stifled by the grammatical and syntax problems introduced by such a system.

I'm not saying it wouldn't work, there are plenty of games where the room descriptions are no more than a list of things anyway, but if someone goes to that little trouble to design their world in the first place, why would they bother with the programming or extra writing with the dynamic room description. It is an interesting concept from a programming point of view but I don't think it would be a tool that would contribute to the making of a great text game.

That only applies to the "stage" aspect though. As a means of narrative construction through conversations I think it could be a very powerful tool, so please don't mistake this tangent for a criticism of the idea itself.

Liam, conventionally you are exactly right, such a system in a standard text game very well might just degrade the quality of the writing within the game, but under certain circumstances and with the right approach to the technique, it could be a great boon, or at least indistinguishable while adding a great deal to the flexibility of the game.

Summarizing the game concept I linked to earlier, entire places--rooms, objects, everything--would be randomly generated. There would be little to no predefined constants, but because the game is text, it would still need logical descriptions for everything the player saw. A system like this (and very few other things) would allow thorough descriptions to be made without a long list of "if" statements clogging up the attributes of every object that might be created in a game.

For use in a more conventional setting it might aid the flexibility of a game. There's the moving chair example I made, and then there's the idea that something constant happens to an object that exists in some way in every room: say there's a mechanism in a creepy manor that rotates all the paintings in the building, showing a different image or a map in nearly every room. Sure, you could make "if" statements for every room, changing the description when that happens, or you could make it a constant attribute of the painting object.

Basically, you're exactly right to point out that a system like this does not in any way aid the language in a game. In that aspect, there's probably not much room for anything but hurting it. However, as a tool to make life easier for the game creator, and a tool to be able to allow functions and events in the game that could not be easily implemented otherwise, it would be a great boon.
Is something like this prone to abuse? Yes. Could it hurt more than it helps? Most definitely. But you always have to pick the right tool for the job, and just as I can see numerous situations in which this tool could be useful, I believe the idea is that hopefully, other writers would do the same.

Liam315 wrote: It is an interesting concept from a programming point of view but I don't think it would be a tool that would contribute to the making of a great text game.

I agree with that mostly. Most things can be done without a new system, for example you can modify your room descriptions with inroomdescriptions for objects. But one thing is missing in Quest at the moment, a real conversation engine (talking to NPCs I mean). And if it would be possible to create such conversations, even if it would be only a smart part of Jays engine, it would be a great benefit for Quest .

Liam, I understand what you're saying completely. I was actually thinking about that very thing on a walk after I made that post, as I was contemplating it further. I do think the idea still has merit and offers some interesting possibilties. I know what I had proposed above sounded a bit systemic (as in, "Hey, what if we set it up to be this way!"), but I would never want to constrain an author along paths that don't work for them. If it works in the situation you need, great. If not, work your text another way - use "if"s if you like or any other method to gets the job done. I see it as another potential tool for game developers. And also an interesting way to look at things.

Perhaps I should give a little background into what has spawned all of this.

I had an idea for a game that was meant to take place over 4-5 days in an instituton for "gifted" young people. At its heart, it's a love story (or could be, if the player steers it that). The main thrust is the relationship between the protaganist and the partner assigned to work with him/her. There are others involved as well, and there are events which propel things along, but it's really about what happens between those two over the course of those fateful days.

I was running into things like:
1) When you first arrive, it's night time. So the outside of the building will have one description. The next morning, and perhaps even on subsequent days, you'd expect the description to be different, based on things like time of day, the weather, etc. This was the driving force behind wanting to include description in this "conversation" model I'm talking about - to make it variable and dynamic.
2) The other characters in the game are autonomous NPCs. In other words, they have their own goals, their own activities, some of which intersect with yours. They have their own inner states. They move about, they enter rooms, they push elevator buttons. You can follow them around and watch them if you want. They engage in occasional conversation,some that you initiate, some that they might. This was the impetus behind wanting a fluid conversation model with memory and topics based on the such state as whether the NPC likes you or not and what has happened up to that point.
3) Descriptions for NPCs will change over time. Perhaps I'd want to display even indications of inner state (smiles, sneers, etc).
4) The development of the main relationship is not just a series of puzzles to be solved. It's based on how the player interacts with the co-protaganist and others.

The bottom line: this was never meant to be a typical "find key-use in lock" sort of game. In fact, any objects found and used would probably be incidental to what you're actually meant to be doing (e.g. the bird seed you can get from the kitchen to feed the bird that occasionally shows up on the back patio, the stick the farmer's dog brings you in the field with intent to play.)

Now, Liam, what you are referring to has been a constant design concern of mine - how do you assemble dynamic text without having it seem assembled? How do inject art into a process? And I don't have a good answer yet. Perhaps it will never be <insert favorite author here>, but I would be satisfied with something that at least seems natural to the player. In other words, if I can fake it and pull it off, I'd be satisfied.

The question is: could I actually pull it off, that and everything? The answer: I don't know.

I know that if I tried to do this all with hard-coded "if" statements, I'd either go mad or I'd be unhappy with it, as it would be either too complex or too simplistic. What I really wanted - and still want - is a dynamic system that responds and adapts to what the player does, where each player - to some extent - can have their own unique experience. It might all be a pipe dream, and maybe it will never come to fruition. But it's the sort of game I'd like to write, and so that's what drives me.

Unfortunately, I got bogged down and sidetracked from it. Having written all the above, I can feel the excitement again. Maybe it's time to dust it off and try once more.

Pertex wrote:But one thing is missing in Quest at the moment, a real conversation engine (talking to NPCs I mean). And if it would be possible to create such conversations, even if it would be only a smart part of Jays engine, it would be a great benefit for Quest .

Don't get me wrong, I absolutely agree with that, and I think Jay's proposition is a really good idea for going about building such an engine. My points were only leveled at the dynamic room description being contained within objects themselves. The NPC conversation part is solid because each response itself is still constructed by the author rather than compiled by an algorithm, yet the single response selected is still a dynamic response to events.

jaynabonne wrote:Now, Liam, what you are referring to has been a constant design concern of mine - how do you assemble dynamic text without having it seem assembled? How do inject art into a process? And I don't have a good answer yet. Perhaps it will never be <insert favorite author here>, but I would be satisfied with something that at least seems natural to the player. In other words, if I can fake it and pull it off, I'd be satisfied.

The question is: could I actually pull it off, that and everything? The answer: I don't know.

I think I understand what you're aiming for a bit more clearly now, I was thinking only of room descriptions in a utilitarian sense, what's actually there, rather than how the character might be feeling about what's actually here (which has made me reconsider a couple of things I had going on in my game). Maybe there's a halfway point between a static room description and one where the objects announce themselves based on your mood, weather, etc. Rooms are kind of organised at the moment into exits, scenery objects, active objects, etc. perhaps there's a different way to classify objects and therefore different chunks of the description. (I've started typing and retyping this sentence to offer suggestions but each one crumbles in my head and it's making my brain hurt.)

I think I understand what you're aiming for a bit more clearly now, I was thinking only of room descriptions in a utilitarian sense, what's actually there, rather than how the character might be feeling about what's actually here (which has made me reconsider a couple of things I had going on in my game).

I think I look at it as a combination of both. If I have a game world where things can come and go (granted, not all games will be this way!), where the same object - be it a character or a thing - can show up at different times in different places, then it's actually impossible to put the object description in with the room's, unless you're really masochistic and don't mind duplcating code and/or text all over the place. The remaining existing alternative, which is common in Quest, is to have the engine report what's in the room with you - and that usually ends up being "You can see a chair," which is really uninspiring. But it can't do much more, because it just doesn't know. You can then look at the item to get a further description, but the room objects don't take part in the overall "look" experience. By allowing them to participate in the overall environment description, I think it can end up providing richer experiences for the player. It might be as simple as an extra "short description" (for lack of a better phrase) that gets reported instead of "You can see a chair." It's just one more "hook" for an author, another place to communicate with the player.

As authors, we have text that needs to get conveyed to the player, for all sorts of entities in all sorts of situations. The question is how. Consider this one more possible mechanism for doing that.

(I've started typing and retyping this sentence to offer suggestions but each one crumbles in my head and it's making my brain hurt.)

I've been there on both counts. I figure this can't all be worked out at once; it needs to grow and evolve over time, by trial and error and experience. Perhaps this can be some first steps toward that.

I toyed with the idea of an Elder Scrolls style conversation some time ago.

The basic idea is that every response for every NPC is held in an ordered list. Quest would go through the list and respond with the first one that matches the current situation. A response might specify the NPC is Prince George, that the player is wearing the crown and is in the throne room. If they all match (and nothing earlier in the list did), that response is used. If the player is not wearing the crown, that response is skipped and another searched for. At the end of the list are all the generic responses to catch anything unexpected.

I did not get very far with it though...

Thanks for that. Similar ideas, and I like when we get down to discussions of data strutures.

You raised a point in that thread about performance. That has been a concern of mine as well (That's one reason why working with a bunch of weights might be too much for Quest to handle.) I think it all depends on how many topics and phrases you have. I think we *should* be able to make something work.

Your delving into data structures prompted me to do a test. I know Alex had added the ability to put dictionaries inside lists, lists inside lists, dictionaries inside dictionaries, etc, but I didn't know to what extent that had been implemented. It turns out that you can statically define any arbitrary structure you want. The attached file shows a simple one: a list of "phrases"; each entry in the list is a dictionary, containing a "condition" string to be eval'd, a list of topic strings, and the actual phrase text. Unfortunately, the GUI editor has no way of editing it, so you'd have to create the data in code view, but at least it is possible to create the sort of structures we might need.

An alternative would be what you had contemplated - phrase objects. I had tried that as well in some "hints" code I never finished. You have to be careful if you want the children ordered, though. In my experience, child objects show up in the list in the order they're defined in the file, so I suppose, technically, they would be in the order you specify them under the parent object. That would be good to verify (though scary to me to depend on).

jaynabonne wrote:... You have to be careful if you want the children ordered, though. In my experience, child objects show up in the list in the order they're defined in the file, so I suppose, technically, they would be in the order you specify them under the parent object. That would be good to verify (though scary to me to depend on).

Now I come to think about it, I think this was why I abandoned the idea. You could do it with a linked list (which is how it is done in Elder Scrolls), but it adds another complication to the code and, more signifucantly, adds complexity for the author to create and track.

I didn't really understand the DataTest and how to work with it, but I'm still a beginner ^^' I just hope you continue to explore the possibilites of this way of conversation.

I had a thought about the room descriptions though. I'm just reading about the text processor and some of the commands you can use for all text output. Especially this {if object.attribute>value:text} (Display text only if an object attribute is greater than a certain value.) and this {if object.attribute:text} (Display text only if object attribute is true) (plus all the variations of those two commands). Wouldn't those commands be a way to have a dynamic room description (or even a dynamic nsc/object response)?
For instance, just give a chair that can be dragged around different values (if thats possible) depending in which room the chair is. And then the rooms could display an extra text if their specific value is matched.
I'm sorry, if this is totally obvious for all coders or if it was already mentioned and I just missed it due to the lack of my code understanding (and the english language..). I just thought that those text processors could be very handy and would avoid a lot of scripting in the room description.

That was what I had meant when I said this:

unless you're really masochistic and don't mind duplcating code and/or text all over the place.

You could certainly go to each room and put in text in each room for each object that could possibly be in there. As a trite and possibly extreme example, If you have, say, ten such possible objects and maybe twenty rooms to work through, then that's only a couple of hundred "ifs" to put in your code. There are ways around that (you might be able to mitigate it slightly with a room base class), and perhaps my short example there doesn't apply or is a bit contrived. It's more the principle for me, I think, than anything. For sure, you can take advantage of the text processing facilities, and I have often contemplated some extensions to them which would be useful, like fully eval-able conditions and expressions for the text. It all comes down to what you want to do - and how scalable you want your code to be.

I think I just tend to prefer data-driven code that you set up and then "works like magic", doing things you possibly didn't even aniticipate (hopefully in a positive way), rather than code that is brute-force and does only what you explicitly tell it to do. That might sound like nonsense - how could it be any other way? - but I've been pleasantly surprised at times by code I've written in the past that was flexible enough such that, in situations I hadn't even envisioned, it did the right thing. I don't know if I can explain it better, since it's not even clear to me how something like that works. But it's wondrous when it does.

I really like this thread. I just started with Quest so I don't understand most of the details , but having a foot also in the world of MUDs I'm familiar with the core ideas.

If you want an example I recommend playing the mud God Wars II. It has fully dynamic descriptions in a roomless world. It does use a tag-based markup (what jaynabonne is talking about with 'ifs') because as Liam315 noted generating well-written descriptions is quite difficult, but since it doesn't use rooms the problems of repeating 'ifs' everywhere are mitigated somewhat . I should warn you that this mud can be quite overwhelming for a first-timer so be prepared for that .

jaynabonne wrote:What I have come to is that we want to somehow utilize both schemes, “binary” and “fuzzy”. The “binary” part would be used for phrase eligibility, based on world state; the “fuzzy” part would be used for selecting from among the eligible phrases, based on topic or other fuzzy considerations. This is the next area of thought for me, so I don’t have any ready answers yet. Perhaps some sort of uniform notation could be adopted.

Maybe applying a binary filter to a fuzzy search is the way to go. That way you catch all the interesting possibilities in the search but you can easily modify/combine filters depending on the state.

An update on this (and I'm doing this mainly because I just discovered today that my "work in progress" test game which was supposed to be unlisted/private was actually public... I need to be more careful.)

I'm in the process of working on a general "response" library, which I'm using in a fledgling game. The game is forcing me to actually use it in a real-world way, and it's helping to point out where the design has flaws or can be expanded. Lots of uses cases being folded in...

To back up, I had a bit of turn of thought, based on (what else?) terminology. I came to realize that the word "phrase" was not very good, as it just didn't fit with what it actually was, since a phrase is a piece of a sentence. So I went in search of a better word. I came across "response" and it stuck. But that word opened up new directions in thought. A response need not be verbal. It could be a reply, but it could also be a shrug, a smile, or even a punch in the face.

That new direction has now been incorporated into this new "response library" that is a work in progress. Since it is a WIP and it's changing almost daily, I don't want to post it yet, but I will as soon as it seems stable. Also, while it's being designed for (I hope) novices to use, it has some depth to it with a bit of a ramp up to get the concepts, and I don't want to document it until is, again, more stable. Only so many hours in the day.

If anyone is *really* curious, they could contact me privately. But I wouldn't be able to promise much support, if any, at the moment. Just a sneak peek and a shove off.

Fascinating material here.

The "response library" mentioned above is now available here:

viewtopic.php?f=18&t=3909

Yea I am kind of bumping this up, being late to the party as it were and to be perfectly honest I am lost in most of what was said, except for the realistic conversations and more fluid room descriptions. But two games come to mind off the top of my head that are realistic in my mind. Grand Theft Auto 3 and up and also Shenmue. Both games brought you into their world in different ways.

The core of GTA was a game world that felt alive. You could be anything you wanted just about. But the story itself did not really change on your actions, it just kept going. It was just the world that felt alive, albeit I think most was randomized people and cars on the street. I have noticed sadly, that if you go to far ahead and come back, most things that were once there are now gone, but replaced by new people and new cars and accidents. In other words it was an illusion, but a pretty good one. (I have not played GTA4 and above, so I have no idea what has changed or was implemented, last I played was San Andres, although I have a love for Vice City. )

The other game Shenmue was much more dynamic in terms of the over all feel of the world. It had a time since you had a year or two to complete the game and the game day itself had a timer. You could virtually do anything in that game world- open draws and cupboards to search for random objects and also clues, go to the arcade and play the games there, you could even virtually follow a person from their home, to their work or to the shops they frequented and then back home again. There was a gap as it were when the time changed or if you got on and off buses or when the game loaded to the next area, but I had more than once followed someone home. Sadly I was not allowed in. Hahaha!

You could stop at a store and buy food for your cat (Although it would not starve if you did not, I will chalk that up to the girl who was with you feeding it...), buy raffle tickets as I recall, cassette tapes to listen to music or what have you. You could even use the phone at home or a pay phone and call people and get interesting responses or even the weather forecast for the following day, maybe two, although I did not bother much with that. Then of course you could buy those little toy capsule with all the SEGA mascots on them. Buy a soda and drink it, blah blah blah.

A lot of non-essential stuff could be done, but it was in there to make it feel more real. And it would rain or snow and people would use an umbrella or dress appropriately. I am not sure if the weather was truly random or on set days like the Tuesday the 14th of this year on every game play it will rain and of course it was seasonal as well so when it was winter it snowed. Descriptions were not needed because it showed the snow falling and on the ground. It had people coming and going either walking, riding a bike, going by bus, etc. You could see it all, hear it all, touch it all (People would actually stop because they could not pass, yet go quickly when they could.) and I could swear I could even smell and taste it all, it felt that real. People would stand out side their markets to usher people in before closing up shop and going home for the night. Or you could see the shop owner walking towards you to open their shop in the early morning hours. Or some shops like bars or other seedy places would not be open until late at night.

In fact the one down fall it had was it's conversations. I thought they were decent, but as other people have mentioned, you basically were just asking people you saw about this or that. Did you see a man with a special tattoo? What nationality was he? Did you see a car? What color was the car? Did you see a black car? Did you get the license plate? What organization were they from? What businesses do they own? Etc. You would ask that of every person you met, who for all intensive purposes, were just filler. But they were psychically in the game world. You knew by face, height, clothing, if they stooped over because they were elderly, etc., who was who, even by their voices. (Although I think some were reused actors, you literally had hundreds of people in this game after all.) And to be perfectly honest, it felt good to me.

But the questions you asked (You just pressed a single button most times as I recall.) differed with what clues you already had, along with the answers they gave. But it was not just, “It was a black car.” and that was the end of it. You would get answers like “Well no, sorry. It was raining that day and I remember I had to get my cat who was out side. I only saw the black car skid across the road and hit a fruit stand. Go and talk to Nami San. I am sorry I could not be of much help. Tell your mother I said hi. Bye Ryu.” I mean it feels like the game makers put some effort into it. And this was for the majority of the characters in the game. Some times you would get a simple “I am busy.” or a “Um, sorry.”, but most were thought out answers. And those that gave those quick answers usually looked the part too, like stuffy and stck up or trying to catch the bus type of thing. And the game world, because of how the characters treated you made you feel like you had lived in that town all your life. Because that same old woman from before might comment and call you “Little Ryu” because that is what she use to call you as a child. Or the hot dog vendor who listens to the boom box all day will chat it up with you like he knows you, because for all intensive purposes, he does know your character. But again, the questions and answers constantly changed due to the game conditions at the present moment.

Anyway, I know this does not help with any of the coding if this project is still being worked on, I was just citing examples of good interactive games and what made them good to me. And with Shenmue I would just stand there and watch the crowd flow realistically through the streets if I happened to be bored. Or I would grab a bowl of Ramen or Chinese Take Out in real life and be inside the Asian restaurant in the game and have my lunch when they did... I mean I was that drawn into it's world.