The other use for nextscene is in the Branching Dialogue part of the system. That is, you can allow the player to pick an option, and different lines are displayed depending on what was chosen. This example doesn’t go very far with this idea, but it does allow an NPC to ask a question and then gives different responses depending on what option the player chooses.
The scene in the JSON file that starts this process is ID 2. You’ll see that the final line in that scene has a lot of extra stuff:
The final line is tagged with a question type, and then the next several keys are all to do with the answer system. Firstly, nbanswers is how many answers there are to the given question, in this case 3. Then, each answer is laid out, with its own nextscene tag.
But how do these questions fit into the events?
Well, when the player presses the Z key and the dialogue system finds a question key, the DialogueQuestion function is called.
This function shares many of the same actions as the DialogueLine function – showing the dialogue layer, setting text etc. But it also switches the Question Boolean to true, creates an array to store the ID numbers of our answers’ next scenes and displays the answer box. It will then loop through the number of answers listed in the JSON file, creating text objects for each of them, assigning them an AnswerID and setting their text accordingly. Each answers’ nextscene ID from the JSON file is then loaded into the array (NxtScenes).
Now that the question Boolean is true, some extra controls are enabled, and a new selection arrow will appear in the answer box.
Every tick when Question is true, the position of this new selection arrow is set to align with the answer currently selected by the player. It does this by checking the AnswerID instance variable assigned to each answer box and comparing it to the ChosenAnswer global variable. If the variables match, the arrow is set to that specific box’s position.
The player obviously needs a way to change their selection, and they can do this using the up/down arrow keys. When the question Boolean is set to true, the up/down arrows change the value of ChosenAnswer. Pressing up subtracts 1 from the variable, while pressing down adds one to it. This is great, but limits need to be added to stop the player going beyond the available answer values.
To do this, we simply check the ChosenAnswer variable and if it meets certain criteria, we reset it:
Condition
System ▶︎ ChosenAnswer = -1
Action
System ▶︎ Set ChosenAnswer to JSONDialoge.Get(“scene.” & CurScene & “.dialogs.” & CurDialogue & “.nbanswers”) - 1
This event says that as soon as ChosenAnswer hits -1, then it needs to be reset to the value of (.nbanswers – 1) – so one less than the number of available answers to account for the zero-based index.
The same thing needs to be done for the other end as well, so if ChosenAnswer] equals .nbanswers then set ChosenAnswer back to zero. This will allow the player to keep scrolling through all the answerboxes and just continually loop back to the top or bottom.
The next time our player hits the Z key, our Else event kicks in and calls the PickAnswer function. This function simply hides the answer boxes and destroys the text instances, then sets the dialogue according to the player’s chosen answer. Thus, allowing the dialogue to continue:
By assigning each answer its own ‘nextscene’ you can change the way the dialogue progresses according to the player’s choices. As your dialogue gets larger, it may be worth storing it in something like a spreadsheet or if you’re more visual, a flowchart so you can see how all your dialogue scenes interact with one another. But, that’s down to personal preference!
So that’s one way of implementing branching dialogue in your games using JSON. Thanks to Kyatric for figuring out most of the logic in this so I could then go and tweak it slightly for my own needs. I hope you folks find it useful!