ASK [NPC] about [topic]

Authoring General Design Discussions
1

I’ve been playing more parser-based IF recently. I like two-word VERB-NOUN parsers, rather than the more complex parsers that I’ve seen in other games I play, and I’ve been struggling to think about why I prefer them.

Then I hit the ASK [NPC] about [topic] problem. Consider a game with, say, 5 NPCs, 20-30 nouns (scenery nouns or inventory nouns), and maybe 3-5 abstract concepts (e.g., ‘mystery’ or ‘adventure’). Then give each NPC 2-3 clues that they can reveal to the player. As a player, I can’t just talk to the NPC and get them to help me, or give them something, or help them in some way. I might have to type 25-40 ASK ABOUT commands 5 times to go through all the things I could ask each NPC about. To a lesser degree, this problem also exists with verbs like PUT.

So if I just have TALK [NPC] (or TALK TO [NPC]) and expect the protagonist to intelligently direct the conversation with that NPC towards topics of interest, thereby only revealing the clue(s) that NPC held, is that easier for the player? I don’t care about coding complexity for the purposes of this discussion (that’s an author problem, not a player experience problem).

The reason I ask is that I’m thinking about incorporating NPCs/dialogue in my parser-based text adventure that is strictly VERB-NOUN. My plan is to create a short dialogue tree for each NPC that gives the player an opportunity to learn some clues or other information, provide a modicum of agency for the player, and without exhausting them by making them type hundreds of commands. There will be some randomness built into the tree so that the responses don’t seem formulaic and there will be some memory of previous conversations, which again should help with verisimilitude.

I have found this article helpful, too: Puppy Power – Realistic Parser NPCs - Sibyl Moon Games

So my question to the collective is what approach do people prefer and what advice do other authors have for implementing polished NPC interactions?

9 Likes
2

I prefer TALK and dialogue trees too, and generally use them in my games. Partly because I grew up with point ‘n’ clicks and so that’s where the nostalgia is for me, partly because like you I get frustrated by guess-the-topic, partly because players will always ASK CHARACTER ABOUT (something you didn’t account for) and it’s hard to craft a satisfying response that covers all bases.

I like dialogue systems to be dynamic in the way you’ve described, with changing responses based on progress and sometimes randomness. The only issue I sometimes run into is that players sometimes don’t realise they need to go back and talk to the character again after doing something else, kind of like how people assume that if you’ve examined something once, that should be it.

I also like a good VERB NOUN game so interested to see where you go with yours.

7 Likes
3

A bit too easy, in my opinion. You have to have a reason for asking a certain person about a certain topic, both of which should be obvious (or close) by the time you get round to asking the NPC the question.

3 Likes
4

This problem I was going to address the same way as I was going to address the ‘PUT’ problem. If I’m at the church altar and I wanted to put the candles I’m carring into the scones on the altar, I would type put candles. But if I haven’t examined the altar and seen the candle sconces fixed to the wall above the altar, it doesn’t do much (actually, it gives you a clue that you need to look for somewhere to put them…). You have to EXAMINE ALTAR and then PUT CANDLES. As a player, if I have to do PUT [thing] [preposition] [thing] but type PUT CANDLES ON ALTAR, that could be confusing for the player thinking they’ve done the right thing when they actually need to PUT CANDLES IN SCONCES. Or you fudge it and change the response to PUT CANDLES ON ALTAR such that it works the same. It’s easier just to PUT CANDLES and let the engine work out where the best place to put them is.

Same with the dialogue tree - because my game tracks what you’ve found, where you’ve been, etc., you’ll only be able to ask about (or be told about) those things. It doesn’t mean to say some NPCs won’t volunteer information about something you’ve not yet found, but you won’t be able to ask about it.

Does that make sense?

3 Likes
5

That’s something I didn’t signpost well enough in my last adventure, so definitely something I need to signpost better in my next game. Do you have any suggestions about how to approach this?

2 Likes
6

I think it depends on the game, as long as it is clear to the player what commands are important. It is perfectly fine with an ASK ABOUT TOPIC as it adds an extra challenge to come up with topics rather than choosing them. This is the same advantage that parser games often have over choice based games: The puzzles can be harder as we don’t have to give away the answer somewhere.

In a strict two word parser just tell the player they should type ASK “topic” and perhaps even allow abbreviations such as A “topic”.

If you don’t want such “find information”-puzzles you can just stick to TALK (TO) “npc”.

5 Likes
7

Thanks for the suggestion. I’m going for something that avoids the guess-the-verb or guess-the-topic puzzle. And I want the protagonist to interpret commands more intelligently. For example, the player examines a desk and finds a drawer:

EXAMINE DRAWER
The drawer is closed.

OPEN DRAWER
The drawer is locked.

UNLOCK DRAWER
You unlock the drawer.

EXAMINE DRAWER
The drawer is closed.

OPEN DRAWER
You open the drawer.

EXAMINE DRAWER
Inside the drawer, you find .

LOCK DRAWER
The drawer is open.

CLOSE DRAWER
You close the drawer.

LOCK DRAWER
The drawer is locked.

I’d like the game engine to know that the player probably wants to open the drawer when he examines it (especially if the game doesn’t have any consequences for doing so - like a trap, for example). I want to create a game in which the intent behind a command is inferred from the command and react accordingly (e.g., when trying to lock the drawer, the protagonist automatically closes it first without complaining that it can’t be locked because it is still open). That is, your agent in the game is themselves an intelligent person, not a dumb robot. If the player wanted to put something in the drawer and still had the key with him, PUT<item> should automatically unlock and open the drawer, put the thing inside it, then close and lock the drawer again (i.e., leave it as it was found - if was just closed and unlocked, it would only close, not lock, the drawer after putting the item in it).

That’s the behaviour for which I’m going, anyway. Simple commands with an intelligent agent. And I want dialogue with NPCs to work the same.

4 Likes
8

It’s not something I’ve fully cracked yet and I tend to be a bit sledgehammer about it - perhaps have the NPC give you an interested look if you’ve found a new inventory item, for example!

2 Likes
9

Now that’s something I hadn’t considered…

“You go to talk to Archibald the Squinty, and as you approach, he takes one look at your fishing rod and says, ‘you’ll not catch any fish in the river, not unless you make an offering to the nymphs first. I hear they like blueberry wine.’”

And the good thing about that is that you could approach any of teh townsfolk whilst carrying your fishing rod and get the same clue. You could even just be in the same location as an NPC and have teh dialogue tree open up automatically (they could approach you, seeing your rod, rather than the other way around, especially if you had a good reputation with that NPC - maybe the in-game punishment for acting aggressively towards NPCs is that they don’t do this?).

Lots of options - thank you for the inspitation.

3 Likes
10

You mention a dialog tree. Does that mean the player will get a list of choices when she talks to an NPC? If so are any bad choices? Or can the player just lawnmower them? I do not think either is great, which puts me off this approach. And no choices is even worse; the player just tries TALK TO with each PC in turn until she gets something.

4 Likes
11

I only use TALK, and then choices that come up as a result if I want or need, based on game state. I personally dislike ASK/TELL, and tend not to persist with games that focus on it hard. This is no doubt influenced a lot by me having RSI troubles: during ASK/TELL, the ratio of commands you type that fail to achieve something to ones that don’t fail can go up massively, for all the reasons @dee_cooke mentioned. Inevitably, I also only make games where my preferred system will be suitable.

I think something that can boost TALK is: make maximum use of your tracked info. The more the conversation reflects what the player’s said before, or even done on their own in parser mode, the more they sense, ‘Hey, this game’s really paying attention to what I do.’ Because it is.

-Wade

6 Likes
12

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
13

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
14

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
15

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
16

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! :slight_smile: :stew:

FILL FLASK could mean from the fountain of youth or from the pool of doom. :potable_water: :non-potable_water:

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
17

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
18

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
19

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
20

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