The Daunting Dialogue System, Part 2: Event Dialogue & Idle Dialogue

Time for round two! This continues where the first post left off, discussing the design for the dialogue system in Lifelike.

This second half discusses the two different large categories of dialogue: Event Dialogue and Idle Dialogue.

Event Dialogue

Event Dialogue is dialogue that is triggered by a specific thing happening in the game.

Here are some examples of things that could trigger Event Dialogue:

• hit by an attack
• hit by a certain ability
• lands an attack/ability
• crit/get crit
• brought below a certain % health
• get a kill
• get killed
• reach new floor
• find item
• get close to certain set piece
• investigate set piece
• level up
• literal Events (if we put in event system)
• encountering new player character
• encountering new enemy
• etc...

We will create a spreadsheet dedicated to triggers, as these should operate separately from the dialogue lines themselves. QUESTION: does this make sense, or should the triggers be tied to the dialogue data?

Conversations (Event)

Conversations are dialogue sequences with more than one line of dialogue from one or more characters. These will be used mainly to progress the story and shed light on the characters.

Since we won’t know the character layout of the part in most cases, there will be a fair amount of conversations that have potential responses from every character. There will also be conversations that are specific to certain characters, which will only be triggerable if all required characters are present.

Conversation Rules

1. Conversations will be written in spreadsheet form
2. All conversations have a unique code (NOTE: please let me know if you have a better idea for how to organize this code):
1. The first four characters of the code are a reference to the conversation’s description (in table 1 example, “ne” stands for “new enemy”, “03” stands for the third enemy)
2. The number after the point “.” in the code is the step in the conversation (the order)
3. The numbers after the underscore “_” indicate the priority and the urgency of the conversation, in that order
4. Conversation codes are unique, as conversations are not tied to specific characters
3. A conversation works by picking one line/character from each step of the conversation at random and displaying it at the step’s start time for the step’s length.
4. If possible, a conversation will not pick a line from the same character as the previous line.
1. If the same character is picked twice in a row, the new line will interrupt the previous line.
5. A conversation is only valid if the minimum amount of required characters are present; there must be at least one line on each step that belongs to one of the characters present on the map.
1. an invalid conversation cannot be triggered.
2. a character does not count as present if it is within the fog of war.

Event Conversation Trigger Parameters

1. The event that causes the trigger
2. The % chance that the event will cause the trigger (will be 100% in most cases)
3. The base conversation code (without the step, priority, or urgency. ex: “ne03”)

Conversation Example

It will easiest to explain the conversation system using an example. All conversations will be laid out in table/spreadsheet format, like the following:

Code	Start	Length	Char 1	Char 2	Char 3	Char 4	Char 5
ne03.0_22	0	2.5	What the hell is that??	Oh shit, what is that?	What the hell is that??	That is... new.	Oh god, not him.
ne03.1_22	2	3	Can it see us?	Can it see us?	Maybe if we don't move, it won't see us.
ne03.2_22	5	4	He's looking right at...everything.	Is it looking at me?		I'm fairly certain that it can see us.	He sees EVERYTHING.
ne03.3_22	8	4	I feel like I've seen him before...

Table 1: “meet the supervisor” conversation table

So, in this scenario, we have a conversation triggered by the the first discovery of the Supervisor enemy.

Let’s start with the code. The code, “ne03”, stands for “new enemy 3”. “ne03” is what will be set to trigger in game when the Supervisor enemy is encountered for the first time in a playthrough. The numbers after the point stand for the order of the conversation. The numbers after the underscore represent the priority of the conversation followed by the urgency of the conversation.

When the “ne03” is triggered, the dialogue system first checks to see if there are enough viable characters in the party. In this case, the only required character is “Char 1” (The main character). This can be determined by making sure there is at least one dialogue line in each of the rows of the conversation. Since the last row only has one line, from “Char 1”, “Char 1” is required to complete this conversation.

If the conversation is possible, it begins by selecting one of the lines from ne03.1 at random. As we can see in the Length column, this text bubble should last 2.5 seconds. In the Start column, we see that the next line is supposed to start 2 seconds after the conversation begins. So, when two seconds have passed (before the first line has faded), a viable line from ne03.2 is chosen and displayed. This continues for every line.

As we can see here, some dialogue lines overlap with the trigger for the next line. So, yes, it is possible for dialogue lines to overlap. The potential issues with this are dealt with by the fact that the conversation system will always choose a different character from the last to speak if possible. If it’s not possible and an overlapping line from the same character is picked, the new line simply interrupts the old line.

Comments (Event)

Comments are one-liners that can be caused by a variety of actions. Event comments are very character-specific. Each character will have a spreadsheet of comments related to various events.

Unlike conversations, comments will often have an element of chance. Many actions will only have a chance to trigger a comment. For example, each character will have a selection of comments for getting hit by an attack. On the “getting hit” event, we will put a 30% chance to trigger a “getting hit” comment from the character getting hit. If that triggers, it will then randomly select one of the character’s “getting hit” comments.

Comments should also have a flag for whether or not they have already been played in the current playthrough. Some triggers will have a parameter that will only will only allow it to pick a comment that has not been played already (this will mainly be used for observational comments).

Comments will have the same codes as conversational dialogue, but will be organized slightly differently and will not be unique; since comments are organized individually by character, characters will each have comments that share the same code. For example, each character will have an “ow” comment code.

Event Comment Trigger Parameters

1. The event that causes the trigger
1. EX: character is hit by an attack that deals 1-10 damage
2. The % chance that the event will cause the trigger
3. Target: the target character of the trigger. This can be one of the following:
1. The event target (the one that caused the event, e.g., the character that got hit with the attack)
2. A specific character (trigger will fail if character is not present)
3. A random ally
4. All allies
4. The code of the comment
5. Whether or not this can trigger comments that have been played already in this playthrough.

Comments Example

Description	Code	Length	Comment1	Comment2	Comment3	Comment4	Comment5
hit by an attack 1-10 dmg	ow01_42	1	Jeez!	Ugh.	Alright...	Really?	Tsk.
hit by an attack 11-20 dmg	ow02_42	1	Ow.	Ow.	Not cool!

Table 2: Intern Comments Table

This is an example except of a character’s comment spreadsheet. Note: The “Description” column is purely for organizational purposes, and will be ignored by the dialogue system.

In this example, the following would be the relevant Event Comment Triggers:

Event	Chance	Target	Comment	Allow Repeats?
character hit for 1-10 damage	30	event target	ow01	1
character hit for 11-20 damage	30	event target	ow02	1

Table 3: Event Comment Triggers

So, the first event has a 30% chance to trigger when a character gets hit for 1-10 damage, triggers a comment from the character that got hit (the event target), uses comment code “ow01”, and allows comments that have already been said to be used again.

When “ow01” is triggered--in this case on our main character, The Intern--the dialogue system picks one of the non-empty “Comment” fields for “ow01” at random and displays it for the comment’s length in seconds.

Death Reactions

Death Reactions can be either conversations or comments, but are important to note because they are the highest priority dialogue.

When an enemy dies, it will most likely be a simple comment from the dying enemy (a groan or “noooooo”). Though it’s the highest priority and urgency, it will in most cases not cause conflicts with any dialogue other than its own (the death trigger would interrupt the taking damage trigger).

When an ally dies, it will likely cause comments from all party members, followed by a conversation. This is where it is important to differentiate death reactions, as they are one of the few cases where we will need to trigger multiple urgency 2 comments followed by an urgency 1 conversation.

Idle Dialogue

Idle Dialogue is dialogue that is triggered randomly within certain parameters.

Idle Dialogue is meant to be mainly flavor dialogue, triggering when nothing else is going on. It follows the same rules that event conversations and comments do, but its main difference lies in its triggers.

Unlike event dialogue, idle dialogue is not triggered by individual events. Instead, there is a constantly working system that will attempt to trigger idle dialogue at a varied interval of time.

Idle Dialogue Rules (Preliminary)

1. There are two Idle Dialogue systems running simultaneously: one for allies and one for enemies. Each of these follows the following steps separately.
2. Every 5-30 seconds, an attempt is made to trigger idle dialogue. When this happens:
1. A decision is made between an idle conversation and an idle comment (enemies do not have idle conversations, so their Idle Dialogue is always comments)
1. 70% chance for a comment, 30% chance for a conversation
2. If it’s a comment:
1. a random present character is chosen
2. a viable comment is chosen from that character’s Idle Comments spreadsheet (see below for viability details)
3. that comment is triggered
4. whether the comment is successful or not, start the timer over again
3. If it’s a conversation:
1. a viable conversation is chosen from the Idle Conversations spreadsheet (see below for viability details)
2. that conversation is triggered
3. If the trigger is prevented by active dialogue, start the timer over again
4. If the trigger is successful, start the timer over again at the end of the conversation, and prevent a conversation from being chosen in step i. for the next 90 seconds.

Dialogue Viability

The main distinguishing feature on Idle Dialogue that differs from Event Dialogue is that all Idle Dialogue has viability parameters. Essentially, these parameters determine what conditions must be met in order for the dialogue to be valid for triggering.

For now, the only viability parameter on Idle Dialogue will be a floor requirement. This determines the minimum floor level that the player must be on in order for that dialogue to be viable.

Note: character presence is still required for viability as well.

Conversations (Idle)

Organized almost identical to Event Conversations, with an added parameter to its code with the floor requirement.

Like Event Conversations, Idle Conversations can only be triggered if enough characters are present to complete the conversation.

Comments (Idle)

Idle Comments are almost identical to Event Comments, with an added parameter to its code with the floor requirement.

Phew. Well, now that that's finished, I guess I have to start actually writing the dialogue, huh?