Better than Random? Randomize without Replacement

The problem with a purely random system is that you may, by random chance, get the same dialogue line repeated twice in succession, something that will definitely sound unnatural to the player. The randomize without replacement option provided in the -Random- node of the Sound Cue is a particularly useful one. This will keep track of which sounds have been played and randomly choose between only the sounds that have not been played recently. This is useful not only for avoiding the distraction of the same sound being played twice in succession, but also in spacing out the repetition of sounds.

For example:

1. The Sound Cue is triggered and sound 3 (out of a possible 0, 1, 2, and 3) is chosen and plays.
2. The Sound Cue is triggered again, but this time the -Random- node will only choose from sounds 0, 1, and 2. Sound 1 is chosen and plays.
3. The Sound Cue is triggered again. This time the -Random- node will only choose from sounds 0 and 2. Sound 2 is chosen and plays.
4. The Sound Cue is triggered again, and sound 0 is chosen to play. The -Random- node then resets itself so that all sounds are once again available.

This system is sometimes referred to as random cycle down in other engines to describe the random choice cycling down each time through the samples left available.

Timed Help Advice

As well as giving direct feedback on a player’s actions, dialogue can often be used to offer advice or hints should a player become stuck. In *Chamber 01* (Bookmark 1) the player needs to interact with the handle on the wall before they can light the way to the back half of the chamber. As what is required is not necessarily that obvious, we’ve set up a hint system. (See the “Hint Timer” section of the Level Blueprint.)

On entry to the room, a <Delay> is started. This checks whether the room has actually been completed or the task (switching on the lights) completed using <Branch> nodes (which we’ll be looking at shortly). If neither of them has, it plays the clue dialogue, “Hmm, I wonder what that lever over there is for?” (and some variations thereof).

There is a similar hint system in *Chamber Two* that gives some slightly more enigmatic clues suggesting that the player should investigate the well at the center of the room (“Well, well, well,” “Oh, well,” etc.) Given the specific environment and approach of your game, you’ll need to consider carefully the frequency of such hints so that they don’t become irritating.

Triggered Advice

Another typical use for dialogue is to set up simple triggers on the entry to an area to give the player instructions or clues when they enter. Once the player lights the torches at the back of *Chamber 01*, there’s a [Box Trigger] as they pass through the gate to warn them that they “need to be careful about the broken tiles.”

It’s often more immersive if these only play once using the <DoOnce> node.

Bad/Better/Better-er

Bad

In *Chamber 01* (Bookmark 1) you can click on various items to get some more, not very useful, information about them, like “It’s a wooden crate,” “It’s a metal grate on the floor,” and “It’s a burning torch.”

If you click rapidly on these, you’ll hear that they repeat the new line while the old one is still playing. This obviously sounds very silly since people are not typically polyphonic (i.e., we can only say one thing at a time!)

Better

When clicking in the darkened back half of the chamber, you’ll hear that these dialogue lines do not play over each other, since we’ve now set the already playing line to be faded out should a new line be called. Although it is still not that satisfactory, you might choose to do this when it’s important that the new dialogue line is heard.

Better-er

In *Chamber 02* (Bookmark 2) you can see a different approach where you can simply block any interruptions, not allowing the new file to be played if there is one ongoing. Click on either door to get a “door locked” message. If you click again while the line is still playing, you will not get the new line.

Presuming the player does not already have the key (<Branch> is False), the dialogue line “It’s locked!” is played and the <Gate> node is closed, blocking any further input to the <Play Sound Attached>. The <Gate> will not open to allow another line of dialogue through until we receive the <Custom Event> LockedDoor1_Finished, telling us that the currently playing line is finished and opening the <Gate>.

It’s always important to not only acknowledge a player’s actions, but to also point out if a command is not possible right now. In this case we’ve used a <MultiGate>. This node increments the output each time it receives an input. So when the player first clicks on the door, it plays the dialogue, but if it’s clicked again it will play a negative input sound. When the dialogue has finished, the <MultiGate> is reset, allowing for the next dialogue line if clicked on again. (See the “Chamber 02”/“Door01” section of the Level Blueprint.)

Exercise 06_02: Don’t Interrupt!

The Character 03 in the *City Streets* section of the map offers some advice as to where to find the dates. Set up a system so the player cannot interrupt them while they are talking.

<Assign on Audio Finished>

1. Find Character 03 in the *City Streets* and set up a use system like you just did for Character 01 (see Appendix A: Core Concepts/Events and Triggers/Trigger “Use”).
2. Create some dialogue such as “You want a date? Try the back alley over there behind me,” “I haven’t had a date in ages, but I think the delivery boy might have dropped some in the alley behind me,” etc.
3. Attach the <Play Sound Attached> to the in-game character as you did in Exercise 06_01.
4. Put a <Gate> between the use system and the <Play Sound Attached>.
5. Create an <Assign OnAudio Finished> node by dragging out from the Return Value of the <Play Sound Attached> and searching for “Finish”. Use the output of the <Bind Event to OnAudioFinished> to close the <Gate> then the output of the <OnAudioFinished> to reopen it. This means that the player won’t be able to retrigger the dialogue while the previous line is still playing. (Don’t forget the exercise screenshots from the website for more help)
6. See if you can extend this system to use the negative click response discussed above.

Global Interrupt

It is hard to keep track of every possible piece of dialogue that might be playing if you need to stop them for some global event such as a player death, so instead of a complicated tracking system, we’ve used a {SoundMix} that ducks all dialogue if the player falls to their death through a cracked floor tile in *Chamber 01*.

All dialogue in the level is assigned to the {RPG_Dialogue} Sound Class, so when we instigate (or push) a Sound Mix ({DuckforScream}) this is set to duck this Sound Class.

The Sound Mix is set to last for 4 seconds (long enough for the game to reset) and so will automatically switch off(or pop) when complete. (See the “Collapsing Floor” section of the Level Blueprint.)

If you have several of these sorts of global dialogue events that need to mute any other dialogue that may be playing, you could assign them to a Sound Class that automatically calls a specific mix when they are played. This is called a passive Sound Mix. This, together with general mixing approaches, is dealt with in Chapter 08.

Simple Conditions and Dialogue Choices

Clicking once on the rat in *Chamber 01* results in the insightful observation “It’s a rat.” Click again, and you kill the rat—“I’ve killed a rat, I feel powerful.” If you click on the rat again after this, you will observe that “It’s a dead rat.”

The rat’s condition (alive or dead) is held in a Boolean variable, sometimes called a Bool. As we have previously discussed, a Boolean is a type of variable that is either True (alive) or False (dead), and this determines which line of dialogue is played. Storing conditions using Booleans allows you to start to more intelligently choose which lines of dialogue to play. In this case we use a <Branch> node to test the condition of the Rat_01_State variable. If True then “It’s a rat,” if False then “It’s a dead rat.” (See the “Chamber 01”/“Rat01” section of the Level Blueprint.)

You can see that the use of Boolean variables to track conditions in the game is widespread. Another example is used to see whether the player has completed the first task (using the lever to switch the lights on). If the lights are on, then the player can move to the back of the chamber, if not, then the hint about turning the lights on is given.

Counts to Dialogue Choices

In some cases we might want to respond to a numerical value, such as how many times something has happened or how many objects a player has picked up. In *Chamber 02* (Bookmark 2) there is a character who has strong feelings about animal welfare. If you leave the rats in Chamber 01 and 02 unharmed, then he is pleased, however kill one rat (“Ratkiller!”) or both (“Rat Genocide!”), and he’s less impressed.

Each time a rat is killed, the integer variable Rats_Killed is added to and then when you come to interact with the character, this variable is used to decide on the selection of a <Switch on Int> node that will choose a corresponding dialogue line. (See the “Rat Friend” section of the Level Blueprint.)

This use of a <Switch> index makes the process transparent, but you could equally use a variable that directly affects a -Switch- inside a Sound Cue. We avoided these earlier when looking at music since if the cue is playing any change in the switch parameter will make the new sound automatically start playing, something we didn’t want in the music system. However since our dialogue is not continuous like music but more of a one-shot event, these can now be utilized. See the exercise below.

Tracking Multiple Actions or Inventory for Dialogue Choice

Once you start dealing with more than a few game conditions or variables, it starts to become harder to organize and remember what is what. For the player’s inventory, we’ve stored the multiple conditions in a single place—an array. We could of course do this with a series of separate Boolean variables, but an array keeps things neater, and we can interrogate the content of the array to inform the decision of which sound is played.

In the *Forest* area of the level (Bookmark 3), the player can interact with a tradesman (on the left). This character will respond in a variety of ways depending on what items you took from the chests in *Chamber 02*.

Vial and Chalice

“Hmm, I see you have everything. Remember (son/lass), nobody likes a smartass.” (See the Character, Contexts, and Dialogue Choices section below for more on this gender switch.)

A Boolean array variable called Inventory stores each item’s condition. Index 0 stores the chalice condition, and index 1 the vial. We don’t need an index for the scroll wheel mouse since we don’t allow the player to pick that up. As each item is picked up, an <Insert> node is applied to the array to put the condition True into the appropriate index. (See the “Forest”/“NPC Tradesman Inventory” section of the Level Blueprint.”)

When the player comes to interact with the trader, we <Get> the contents of these indexes and use a bit of logic to determine which line to play. UE4 has a number of logic gates available to help us with these sorts of comparisons. Their exact operation can be found in the tooltip text when floating the mouse over the nodes.

• Has the player picked up just one item (<XOR> will only answer True if inputs are different)?
• It they have just one item, is it the chalice?
• If yes—play chalice line
• If no—play vial line

• Do they have both items or no items (i.e., the <XOR> was False)?
• If the <AND> is True they have both—play both line
• If the <AND> is False they have none—play none line

Exercise 06_05: Arrays for Tracking Dialogue Conditions

Godfrey the guard is very particular about his menu. Only if you collect all the correct items will he let you through the gate into the *Inner Sanctum*.

{Array}

1. We have set up the system to add items to an array as the player collects them. An array is a container for a number of variables (see Appendix A: Core Concepts/Variables, Parameters, Numbers, and Arrays).
2. This is stored in the array variable City_Inventory. Whether the player has the items or not is stored as Boolean variables: in index 0—apples, index 1—bananas, and index 2—dates.
3. Record the following lines (or brilliant equivalents) and set them up in separate <Play Sound Attached> nodes.
   1. “Apples and dates? That’s greats—but you ain’t coming in!”
   2. “Apples and bananas? I’ll feed them to my llamas. Not enough to fill me!”
   3. “Bananas and Dates? This combo I hates! I need some apples too for the right mix.”
   4. “Well, well! That’s a good feast that will fill this beast. I guess you could just slip in while I’m not looking.”

4. <Get> this Boolean array by dragging and dropping it into the Event Graph.
5. Create three <Get> objects to get the contents of each index of the array.
6. Set up and attach the logic system illustrated below. This tests each of the conditions and gives you a True output to connect to the appropriate dialogue line.
   

7. Connect a trigger use system around Godfrey (Character 06) and use it to trigger the top <Branch> node.
8. Link the output of the <Play Sound> you have created for when the player successfully bribes Godfrey and link it to the “Inner Sanctum Door Open” section of the Blueprint.
9. You could also set up additional <Branch> nodes for separate responses if the player only has one of the items.
10. Instead of having separate <Play Sound Attached> nodes, you could set this all up in a single Sound Cue that has a -Switch- node and is controlled through attaching a <Set Int>. The value of your int could be set to corresponding switch values by the True outputs. Try this.

Conditions to Sound Cue Branching Choices

You’ll note that for each of the conditions, apart from vial only, the lines can be said in any order. For the vial we want the first line to acknowledge that the player has the vial, and then subsequent lines to be randomly picked from a selection. In order to do this, we set an additional Boolean variable that tracks whether this line has been played. The Vial_Played variable is used to set a -Branch- node within the Sound Cue itself via the <Set Bool Parameter> node. This works under the same principles as the conditions to dialogue choices above, only this time we are setting a -Branch- within the Sound Cue instead of using a <Branch> to choose between two Sound Cues. All of the above systems could be done like this. We kept them as separate <Play Sound Attached> nodes just to make it clearer as to what was going on.

Branching Dialogue

Summary: Branching dialogue systems

From the exercise above, you might perhaps begin to see how you might apply these ideas of conditions and branches to form a branching dialogue system. A branching dialogue system is where you might be able to have a continued conversation with an NPC, with the character responding differently depending on your choice of line during each interaction. Branching dialogue is typically deeply integrated with the game’s database and character systems in order to keep track of the multiple conditions that might arise.

One of the essential tools for a branching dialogue system (and indeed any dialogue) is the spreadsheet, where you can easily track the route that the interactions might take.

You import spreadsheets to Unreal to form data tables from which you query the contents of the rows and columns in order to populate variables for your system. Double-click on the data table {Dialogue_Branching_05} to see the data table that results from importing the spreadsheet above.

In the *Forest* area, the character on the right is an old crone—who has something you want! Play the game to see if you can persuade her to hand it over.

When the player first interacts with the crone, we play a short movement animation and then get the contents of the data table, first looking at the row defined by the variable Crone Dialogue Line. The default value of this variable is 10001, so we get the values stored in the row whose name column matches.

The <Break DialogueTableRow> separates out all the column data on that row so we can access the different variables. Not shown above is the internal name column. This defines the name of the row that allows the <Get Data Table Row> node to find the row to extract data from.

• Wav: This is the name of the Sound Wave to be played.
• Text: This is the abbreviated text used to populate the HUD buttons.
• UI_Index: These point to the rows that contain the text for each HUD button.
• Next_Line: This defines the next line for the NPC, depending on which line (HUD button) the player chooses.

The Wav column contains the name for the dialogue Sound Wave, and this is passed to the <Play Sound Attached> to play the crone’s first dialogue line. The UI_Index columns define the row values where the possible player responses are stored. We look at these rows and get the string (text) to populate the HUD. At the same time we store the Next Line value from the row. If the Next Line column contains the string “END”, then this means that this particular branch has come to an end, so we <Branch> off (True) to play an ending animation. (See the “Forest”/“Old Crone Branching” section of the Level Blueprint.)

When the player clicks on the HUD, it gets and plays the wave file from the appropriate row and sends the next line value to set the next line for the crone. Then the system goes around again. This is a fairly simple branching dialogue system but should be pretty extendable to your needs once you get your head around it.

Note that in order for the data table to correctly populate, the Sound Waves must be loaded into memory or it won’t find the references to them. In the *Forest* area, you’ll see an ambient sound [AllDialogueSounds-ForLoading]. This references a Sound Cue that contains all of our dialogue Sound Waves. Although it’s set not to Auto Activate, and so never actually plays them, this serves the function of ensuring that the data table can correctly find the references.