Hi, hoping this is quite a noddy question.

I'd like to write some dialogue where the player can choose from two options, and their choice result in different response from an npc.

I.e.

"What is your favorite colour?
1 - Blue
2 - Red
(Press 1 or 2 accordingly)"

Then if the user types "1" into the search bar they get a response "Blue like the sky", but if they type 2 then they get a response "Red like fire".

Seems like it should be simple, but I can't see an obvious way of doing it.

Thanks,

1. I used a Get input script. Then I added a switch script.
2. In the Switch script box, type in 'LCase(result)'. This makes all responses typed by the player lower case and recognized in your cases! Very useful!
3. I added in the print message script when you entered the room, the key words you could use when you answer the angry man.
   4A. I added each word as a case for the switch script. Make sure you type it inside quotes - "mother" and if you have more than one word per case separate with commas - "mother',"mom","ma"
   4B. For these cases, you then are prompted to enter other scripts that you want to run. In your example, it would be a print message script.
4. Make sure you add a default for any comment you do not want him to recognize.

This was from my library of solutions I have built so the angry man in my example is your NPC.

Is it a gamebook or a text adventure?

If it's a text adventure, it has ShowMenu built-in, so you can do:

// VERSION 2
ShowMenu("What is your favorite color?", Split("Red;Blue", ";"), false){
  if (result = "Red"){
    msg ("You chose 'Red'.")
  }
  else if (result = "Blue"){
    msg ("You chose 'Blue'.")
  }
  else {
    msg ("Due to a series of unfortunate events, you are reading this message.  (If I were you, I'd contact the author.  This game is buggy!)")
  }
}

If you are creating a gamebook, you can add ShowMenu by like this:

http://textadventures.co.uk/forum/quest/topic/phlhxhlrak_j3qns2icxbg/can-gamebooks-use-showmenu#3d7982e9-e206-4ac4-af3d-a83cf24d50cd

EDIT

I just now saw XanMag's solution, which should also work, but ShowMenu allows entering '1' or '2' to make a choice (or the player can click the choice).

XanMag's and K.V's solutions is a good way to go.

If you want lots of conversations that branches out into several conversation "paths" I'd recommend taking a look at Pix's conversation library (convlib).

It's super easy to set up and use and gives you a lot of control as to what conversation topics/paths will be shown after one has been chosen.
Read more (and download if you want to) here:

The Pixie's ConvLib on github

@KV:

// There are only two choices, so the player chose blue.

In a simple case like this, a fair assumption. But a bad habit to get into.

There are a few situations where result can be something that wasn't one of the provided options. So it's good to get into the habit of always checking. I usually prefer a switch statement for this, with the defaultbeing error ("Can't happen! In pick-a-colour question, result was: "+result).

When it doesn't cost you anything, it's really good to get into the habit of checking to make sure that the variables you get are what you expect. It's just like a function that displays an error if you give it a string instead of an object; even if you know you're passing it strings every time it's used. Because when you edit the game later, you don't know if you're going to make a typo and send the wrong value. One mantra I try to live by is "fail early". If I make a typo in the code, or mis-remember how something worked when making changes, then it should fail immediately, with an error message that tells me what is wrong.

In this case, for example, if you'd made a typo when coding and put Split("Red;Bl ue"), clicking 'Bl ue' would give the right response message and you might not notice (extra spaces can be almost invisible in some fonts), but later in the game when some NPC checks to see if the character's favourite colour is Blue, it wouldn't match. An extra 'if' statement would result in an error right away, and could save you a lot of headaches.

Everything mrangel says is true.

In my example, though, the boolean is set to false, which will prevent the player from ignoring the menu, which means the player cannot succesfully enter anything besides the two choices.

this can be scaled up in complexity/dynamic-ness... but Apiooo probably doesn't need that headache... whereas, I'm still trying to code in such a scale-up-ness of this functionality for my game... lol. There's a lot of handling that can be done/needed with menu (input selections) functionality

P.S.

I don't think quest has a built-in 'error and exception handling' ("try-catch") system for a person's own game/code/content to use (I'm not talking about the system that exists for quest itself / its underlying code)... which I just realized yesterday... as I was working on part of my game, and needed/realized an error and exception handling system/functionality would be very useful instead of individual error messages (which isn't a good design for editing/scaling/dynamic-ness/etc).

I'll at some point try to create a 'error and exception handling' ("try-catch") library for everyone... but not right away... though it probably won't be as good as what Pixie/Mrangel/KV could do... but this is something that I think I can do, at least the basic stuff of it anyways (some stuff might get a bit more complicated for me, not sure), so, no need to create such a library yourselves, unless you want to and/or need to (can't wait for me to get around to it at some point in the hopefully not too distant future, lol).

In my example, though, the boolean is set to false, which will prevent the player from ignoring the menu, which means the player cannot succesfully enter anything besides the two choices.

If the boolean was true, typing anything else wouldn't call that script anyway, so you wouldn't need to check for that case.

But there are a few edge cases where a menu might fail to be hidden (for example, if a menu is terminated by a timeout event rather than by the player choosing something). In these cases, when you display your menu, the player could scroll back and click a link on a menu in a previous room. Your callback is triggered, with the result variable being one of the options from a previous call to ShowMenu.

Even if you're sure your game isn't prone to any weird edge-case bugs, it's better to explicitly check for your options. It means that if you typo in the list of options, you find out as soon as you click that option rather than getting a hard-to-diagnose bug at some later point.

True.

I should not teach aspiring coders to script lazily.

I have edited my code.

I disagree a bit... getting into good practice of handling human errors/inputs/code/etc... is for those interested in learning code to this greater degree, as if someone just wants some simple code functionality and doesn't know coding... there's no reason to do thorough/dynamic/scalable/good-practice-input-handling-etc code designs, you don't do a super code design, when all you want/need is something simple. Razor's Edge, and all that... don't use/make a nuke to kill a fly when a simple fly-swatter (or even more cool and effective: a salt shooting gun, hehe -- it really does work: the salt grains are like shotgun wide-burst shrapnel for the fly, which it can't avoid, hehe) will do, lol.

now, if someone is doing complex/large-scale coding/game-making like a massive RPG... then it matters... and saves you time (if you're capable of that level of code designing, lol) and from a lot of headaches/hair-pulling... as you try to trouble-shoot stuff and/or add/build onto your game/etc