NPCs: Conversations - ThePix/QuestJS GitHub Wiki
NPCs are characters in your story. Getting NPCs to act in a realistic way is very difficult, and we are just going to skim the surface here. This page looks gives an overview of conversations.
QuestJS has five conversation mechanisms built-in.
These are all about the player striking up a conversation with the NPC. If you want the NPC to say something first, you might want to look at agendas and reactions. Indeed "action-driven conversation, where NPCs talk as a reaction to what the player does is valid approach, and could be used instead of all the above.
You need to decide what is right for your game. You can have more than one, but my view is that consistency is best - the user will feel more comfortable if, having established how to talk to one character, she knows how to talk to all the rest.
Simple TALK TO is, as you might imagine, the simplest to implement and the simplest for the player too, but it gives the user no choice in what the player character will say. If NPCs are a minor part of your game, this is probably the best choice.
The dynamic conversations system presents the user with a list of options as dictated by the current situation. This is good for games about relationships, when the NPC changes his or her attitude to the player based on choices made. I think this works well with games with no text input; it feels like the same type of input.
ASK and TELL work well with text input but not at all with hyperlinks and buttons/menus. They are open-ended, so help maintain the illusion the user can type anything... but that means more work for the author to ensure all the options are covered. I suggest ASK and TELL work well for games where the player is investigating something or solving puzzles. They fit well with games based on text input as they are all about typing input.
Using SAY is perhaps the most flexible. Effectively the player character is broadcasting to all NPCs in range, and could say literally anything, so this will be most work to get right. A good use of SAY - and a relatively easy one to implement - would be when saying a magic word has a special effect.
TALK/DISCUSS is experimental. The player first nominates an NPC as a conversation target, and then can discuss any number of topic with her. This is complimentary to ASK and TELL; you could have both systems in the same game. The player could ASK KYLE ABOUT THE WEATHER, or could TALK TO KYLE, and the DISCUSS THE WEATHER.
An important design decision is whether a conversation will irrevocably change the world. In a sense this is general issue for a game, but it seems more significant here. Suppose we have a dynamic conversation system, with the user choosing from a menu. Perhaps one choice is to accuse the NPC of murder. Does that change how the NPC regards the player, and shut off other options? If this is a game about relationships, it would perhaps be best to have this cause the NPC not to like the player, preventing the opportunity for love later in the game. If this is a murder mystery, with a specific goal, you would probably not want a wrong accusation to make that goal unachievable.
A fairly trivial decision is whether the response text will include the words of the player, but it is a decision I suggest is made consciously and early on to ensure you are consistent across the game.
Compare these two. In the first, the words the player speaks are omitted; they are implicit in the command.
> ASK KYLE ABOUT THE GARDEN 'The garden is doing good,' Kyle says after a moments thought, 'but we could do with some rain.'
> ASK KYLE ABOUT THE GARDEN 'How is the garden doing these days, you ask Kyle. 'Good,' he says after a moments thought, 'but we could do with some rain.'
An advantage of the latter is it ensures the user knows what the author understands the question to be. The user may have wanted to know where the garden is, but was limited by nature of the parser. In both cases the game responds to the wrong question, but the second version makes clear what that question was.
Personally, I prefer the latter; I like the output text to form a coherent narrative if the input text is ignored. If the player types W, I want to see text that says the player has gone west, not just a description of the room that way, but that is just me!
Note that you can allow the player to talk to one NPC who is not present by setting player.onPhoneTo attribute to the name of the NPC. This is useful for phone conversations, etc.
By default, TALK TO and ASK/TELL ABOUT are turned off. This is so Quest can tell the user that these are not part of the game, and not to waste time trying different variations. To turn them on, you just have to set the respective attribute in setting to false.
If you are using TALK TO, but not ASK/TELL ABOUT, it is a good idea to change settings.noTalkTo to make that clear:
settings.noAskTell = "Use TALK TO <character> to talk to people."
settings.noTalkTo = false
Conversely, if you are using ASK/TELL ABOUT, but not TALK TO, update NO_TALK_TO. For example:
settings.noAskTell = false
settings.noTalkTo = "Use ASK/TELL <character> ABOUT/TO <subject> to talk to people."
Though Quest offers no built in support you should consider whether you want to track the mood of the NPC and his attitude to the player. Doing so will give a more alive character, and give the impression that what the player says and does is having an impact.
This ties into an earlier point. If the character gets annoyed with the player, will he refuse to reveal a vital clue or help in a vital way, making that game unwinnable?
Bear in mind that mood and attitude can magnify the amount of typing considerably; now you need a response if the character is: sad and likes the player; angry and mistrusts the player; happy and in love with the player; and numerous other combinations too. To some degree you can combine some of these but working out which can be combined brings its own complications.
NPCs are complicated.
You could also allow the user to control the player's mood or the tone of her voice.
>MOOD HAPPY >TONE CORDIAL
By default this is turned off. You need to tell Quest what tones you want to include in your game. Here we allow the player to pick between three different tones. You should also set a default in the player object (eg `tone:'indifferent').
settings.tones=['hostile', 'cordial', 'indifferent']You can allow alternatives and abbreviations by including them in an array. Note that the tone will be identified by the first member of the array. In this version typing TONE C or TYPE POLITE will both set the tone to "cordial".
settings.tones=['hostile', ['cordial', 'c', 'polite'], 'indifferent']You can use the "tone" and "toneNot" text processor commands to modify output.
'You say{tone:hostile:, angrily}.'
You can add an "afterChangeTone" function attribute to settings; this will be called whenever the tone is changed and could be used to update the UI.
There is a real danger that the user will forget about setting the tone, and will only remember when the player address an NPC in the wrong one, so you need to think carefully about whether this is a good idea or not. It could work well in a game about relationships, not so much in a mystery game.
You might like to look at this page; although from the TADS documentation, it is platform neutral, and gives another perspective. Another interesting page here.