Yes, list of choices is what I’m thinking about. But they will have consequences, so a player won’t be able to lawnmower them. And my reason for the thread is that I can’t think of a good option - they all have their drawbacks: ASK [NPC] about [topic] risks becoming guess the topic, revealing all information the NPC has in response to a TALK command doesn’t provide the player with much agency, and dialogue options are a bit railroady. I think dialogue options are the best of a bad bunch, but I’m open to ideas/suggestions.
3 Likes
Interesting. I was planning to use my tracked data in the dialogue tree, but it could work in the TALK responses, too. I’ll give this some thought, thank you.
1 Like
I don’t like going through lots of trial and error to figure out which conversation topics will be understood. I don’t especially like “ask about,” but sometimes a game that uses “ask about” suggests lots of topics you can ask about, and also understands a lot of topics you might ask about, as in Lost Pig, and that helps.
“Talk to” with no specific topics can work, but it’s nice if the response is set up to be helpful (such as the NPC changing what they say based on what has happened already).
Aside from that, having listed dialogue options, or having highlighted keywords in the NPC’s dialogue (so you know those are available topics you can type in) can help get rid of the frustration of guess-the-topic.
4 Likes
I really struggled with this in the only game I wrote that focussed largely on conversation with NPCs-- The Spectators. I used a shorthand for TALK/ASK ABOUT, which was T, and you could T any topic, so the game picked up on keywords after T. I only had one NPC you could interact with at any time, so the game automatically directs T HAT to the only NPC you can talk to. It was challenging, because players might T every single object in the game, so I had to work very hard on making lots of responses to lots of objects and people, and on making it very obvious what was important and what wasn’t. Additionally, I had to deal with players who are very used to including an NPC’s name: ASK MARY ABOUT LAMB. They would type T MARY ABOUT LAMB even after being told to limit their T topics to one word, because they’re trained to include names. So I had to program it so that if they had more than one word after T, the game would say something like “Limit your queries to one word, like T LAMB. The game will automatically direct your inquiry to the nearest NPC.”
I don’t know how successful it was for others, and it was a beast to code, but I personally felt like it was player-friendly and I generally liked the result.
6 Likes
Since the topic of complex vs verb-noun parsers came up in the thread, I’ll offer my perspective on that.
In general, I prefer a complex parser. It only adds a (potential) second noun, so the complication is not too much, but it opens up more possibilities for puzzles and a more natural way of phrasing things, IMO.
Some examples:
We might like to parse “CUT sth. WITH sth.”, because it’s a small puzzle that, say, the spidersilk rope must be cut with the obsidian shard. So we wouldn’t just want to allow “CUT ROPE” and let the game choose the shard automatically as the appropriate tool.
Similar reasoning could apply to any sort of puzzle which involves using something unobvious as a tool or weapon, or in general to situations where you combine things with other things.
It might be a puzzle that among our many keys, only the humble “rusty key” unlocks the Door of Wisdom. UNLOCK DOOR shouldn’t reveal that.
POUR ACID could mean pouring it on the floor, or on a treasure chest’s lock to dissolve it, or into the king’s stew… an important difference! 
FILL FLASK could mean from the fountain of youth or from the pool of doom. 
ATTACK WEREWOLF might succeed with a silver weapon, and fail with a normal one.
Additional cases where it seems good to allow a second noun (or number or direction): ATTACH sth. TO sth., SET DIAL TO 7, or more rarely but not unheard of: PUSH sth. <direction>.
One can probably rephrase or work around these issues in a verb-noun parser, but I think it is, at least prima facie, a point where complex parsing has an advantage.
PUT is another example; there might be various receptacles, containers, and surfaces around, and I think it’s best to let the players say what they want to do. Of course, the author can set up the game so that a complex situation doesn’t arise, but it feels a bit limiting to me.
A complex parser can add to the sense of freedom, and to the sense of inhabiting a carefully modeled world, when the players can causally affect the environment in specific ways, and (for example) can make a difference between putting something in or on something else as they wish.
Depending on the development system, it’s also feasible in a complex-parser game to have some default rules if the author wants to allow the player to just PUT <object>.
I agree that in cases where it’s absolutely clear and unambiguous what the player wants, the game should simplify some tedious intermediate steps. But complex systems usually do allow such “shortcuts” by having implicit actions. EATing sth. might cause an automatic TAKE; GOing NORTH will cause an implicit OPEN DOOR if there’s a door in the way, and so on.
Having said all that, I want to add that I don’t dislike games with a simpler verb-noun parser at all! They can of course be as much fun to play as games with a more complex parser. A well-written and well-implemented game will be fun regardless of the system, and I’m looking forward to what you’ve got cooking.
9 Likes
Sorry for the double post, but I also wanted to say something about the main topic, NPC conversation.
What you said here hits the nail pretty much on the head, I think:
Some authors try to avoid the problems by having an ASK/TELL-system with topic suggestions:
>ASK JIM ABOUT ALIBI
“Where were you at 6 o’clock?”Jim starts to sweat. “Uh, I was in the library, spending some time with Goethe. Alice was there, too.”
(You could: ask him about Goethe, ask him about Alice, tell him about Alice’s statement)
Ideally, when it works, it gives the player a sense of freedom, but alleviates the guess-the-topic problems.
Some links with helpful material on conversation systems:
9 Likes
I think the choice of conversation system has a lot to do with your story’s/game’s needs. For my current project, I’m going with this style, inspired by Counterfeit Monkey and the Threaded Conversation extension. I’ve written my own extension, Simple Conversation, to do much the same thing, but the margin is too small to contain it.
One thing that’s essential is to make the choice of topics contingent on other actions the user has taken in the game. Once you’ve seen that you need to join the orchestra to steal the conductor’s baton, then you can ask the kindly old codger to teach you to play the tympani.
3 Likes
I think it also depends on the UI. If I was doing a parser game - strictly typed input and no clicking, I would not want to use TALK TO with options to select, I would tend to go with ASK/ABOUT. If the game already has clicking options, then the former fits better.
ETA: Thinking further, I guess this can be extended to the two-word issue too. You could keep it all two-words and if there is ambiguity, present a menu to pick from. As far as I know, that is pretty rare, and yet it is the same in principle.
2 Likes
Some approaches that would be easy for the player:
-
ask x about all
-
ask all about x
-
ask all about all
-
NPC automatically talks to you without prompting
3 Likes
One thing I’ve been working on is a graph-based, goal-oriented dialog system (in TADS3).
Normally, most dialog system are predicated on the idea that the player makes active choices (picking a option from a list, typing >ASK ABOUT some subject, or whatever) and different options might get added or removed from specific dialog nodes and things like that but otherwise it’s mostly static. The thing I’m working on is that at any given point in a conversation there’s an “active” dialog node (a vertex in a graph), but just as the player is choosing a “move” by selecting a dialog option, so is the NPC. So instead of being a simple tree the player can lawnmower through, conversations are an isomorphism of a two-player (or more!) board game, in which both players are trying to move things in a direction of their choosing.
It’s worth pointing out that this doesn’t work well for expository dialog, which is what a lot of game dialog often is. This can be kludged together by designing the graph appropriately (making a bunch of “dialog corridors” that have to be traversed to reach any “goals”), but it’s a lot more messy that just handling things using a more conventional dialog system.
It also dovetails well if you have other NPC goal-seeking behaviors, like the specific situation you’re talking about here (having an NPC comment on a change in the game world).
3 Likes
Very interesting approach, never considered that as an option. What technique do you use to liberate the tree from its static nature? Stochastic walk, like Markov or non-Markov chain?
I can see that hand-designing a tree like that can become a puzzle in itself.
NPC decisionmaking is handled by a simple regret minimization algorithm adapted from decision logic that I was putting together for an in-game poker-playing AI. One of the provably optimal approaches to poker AI (in the sense that it’ll approach the Nash equilibrium in a finite number of steps) is called “counterfactual regret minimization”. I was already thinking of the story vaguely in terms of a bunch of characters trying to deal with their regrets and the phrase seemed oddly compelling, so I’ve tentatively made “A story of counterfactual regret” the subtitle of the game and really leaned into regret minimization as a gameplay element.
Decision process aside, the dialog “map” (the set of all currently reachable dialog states) is a graph into which vertices and edges can be added and removed by in-game events.
Currently the way I’m handling static/bookeeping/whatever stuff (like having an explicit option to end the conversation, special topics that the player should always be able to ask about, and so on) is by having the dialog-handling logic look up the available options in the dialog graph (usually just the player-available edges of the current vertex) and then append/prepend additional stuff onto the results before formatting everything for output.
What I think I’m going to end up doing is having two dialog “maps”: a “this conversation” map and a “overall interactions with this NPC” map, if that makes sense. So building the dialog output/available inputs based on “conversational process” bits from the state of the current conversation (so adding greeting messages, increasing or decreasing NPC “interest”/“attentiveness” based on how long the conversation has been going on, and so on) and the “global” state of the interaction between the player and the NPC…the position of the ongoing board game they’re playing.
The individual vertices in the graph work more or less the way they do in most dialog systems: they’re a list of options and the next state they lead to. The gimmick or whatever is that the next state isn’t a single, deterministic state but instead a decision node for the NPC to evaluate themselves. You could do this by, for example, just implementing a bunch of conditional spaghetti in the individual “PC” dialog results, but I think the graph-based idiom (or whatever you want to call it) makes it easier to work with.
3 Likes
I see, so you leave the dynamic nature to the author to implement as they wish, makes sense.
I have read a lot of papers on UCT but none on CFR, time to surf I guess.
I’m a bit curious as I did at some point make a strict VERB-NOUN parser in a game for the very first TALP Jam (had stricter rules than now) but later changed the game (for another comp instead) to accept slightly more advanced input, but it would then tell the player it wasn’t necessary if they typed more than two words. The main problem was that sometimes a noun contains a space such as “car key” and the parser regarded “car key” as two words. Another example could be if you had e.g. a blue and a red pill. If you don’t allow adjectives, the game cannot tell the difference. You can of course avoid such situations but I ended up feeling that it limited that game quite a lot.
1 Like
Like in Glass? Pretty cool. There’s so much potential in making dialog more gamelike, goal-directed like exchanges in a real conversation.
I don’t know how dialog is handled internally in In Glass and I haven’t played it so I can’t comment on that. But yeah, it’s definitely to make conversations more goal-oriented. That fell more or less naturally out of trying to make everything more dynamic and goal/narrative focused.
Basically the “hook” for the game design, for me, was thinking about how when you’re playing a game with someone you can tell a lot about how they’re feeling by how they’re playing. My spouse and I played a lot of Gloomhaven early in the pandemic, and it was obvious that when she was angry about something she’d play more impulsively, when worried more cautiously and slowly, and so on. This isn’t exactly a revolutionary observation (and she communicates her emotions in less subtle ways as well!). But it occurred to me that this isn’t something that I’ve really seen used in gameplay design. When you want to have the NPC convey an emotion, it’s usually just scripted. And frequently (in higher-budget games) performed by an actor and then played back, so the emotional component (or whatever you want to call it) is literally just a recorded human emotion being kinda cut and pasted into the gameplay…instead of being something you get from the gameplay. If that distinction makes sense.
That started a chain of thinking that got me, several internal conversations later…mostly about how feasible various designs would be and how likely they’d be to get literally any players…to playing poker in an IF game. And then that got me to applying (or at least trying to apply) the same sorts of “tricks” to other kinds of NPC behavior.
It absolutely remains to be seen how well it works in general. Like one of the things I specifically wanted to model was that befriending someone and gaining their trust isn’t just monotonically accumulating musical notes or hearts or whatever…or to have it be a simple boolean flag that’s toggled by a specific event or item. Which seem to be the predominant ways of handling this sort of thing in games. But I don’t know how much it’ll turn out to be just annoying if things don’t work “deterministically” that way.
1 Like
See, this is exactly what I am doing (though not every TALK leads to options). Because I personally gripe to be made to type things I don’t need to type when they could be one-keyed. So when dialogue options appear, I don’t ask for a 1 and RETURN, you just press 1. When I ask a yes or no question, you just press Y or N, not Y and return. To repeat a command, you just hit RETURN, not type G and return.
In one dimension, this is very small stuff, but it’s an element of the game I make in my own excess-keying averse image. And in years when my game comes out, you won’t remember I told you it would be pretty smooth, but I’m going to say now that I think it’s pretty smooth.
I do understand the basic inclination to not mix modes at all. But where we are now is we have all these choice trees appearing in parser games and you still have to type numbers or whole words that are already presented completely discretely and hit RETURN. It always felt clunky to me, rather than holding me in the same UI for a really good reason.
-Wade
3 Likes
This is sort of off-topic, but since we’re all here: what are some games making good use of vanilla Threaded Conversation? I’m not looking for brilliant mechanical enhancements. Just a game using the extension straight from the can?
I’d like to get a feel for what a strong implementation of it looks like.
1 Like
An earlier version was used in Counterfeit Monkey.
My game Flattened London had a topic-based system - the player could first TALK TO an NPC to get something like “I last saw him in the salt mine”, and then ASK THEM ABOUT SALT MINE (or A SALT MINE for short) to be told “The salt mine is five hundred feet to the west, near the old well.” It was not very narratively complex, but worked well for exposition and clues, which was what my game was about.
4 Likes