View Categories

Dialogue System

31 min read

Dialogue System #

The Dialogue System is a flexible, data-driven framework designed to manage all narrative and conversational interactions within the game.
It provides tools for creating dynamic conversations, branching dialogue trees, and reactive NPC interactions that respond to player actions, quest progress, and world state.

Each dialogue is built from structured data, making it easy to create, modify, and expand conversations without requiring additional scripting. The system supports everything from simple NPC greetings to complex, multi-stage story conversations with conditional logic and gameplay integration.

This system is super strong. With a system like this you have the backbone for AAA games. If you are making games like Zelda, Mario Odesey, one of the elder scrolls games, final fantasy, Hogwards or something simular. This could be perfect for you. We do not have a link yet to tools like Articy, but we think it could be fairly easy.There are already community tools available to have visual dialogue editors that you could use to fill in the datatable with the structures used.

Videos #

This is an extensive video on how to add dialogues, subtitles, world dialogues and more and explains how the core of the system works.

Play

And if you are intrested in how we progressed during the time and check out devlogs check those:

First devlog:

Play

Second devlog:

Play

Adding dialogues to your char #

Adding fixed dialogies to chars #

Add AC_DialogueManager_NPC to the actors or classes you would like to have dialogue interactions with. In the details panel you will see some variables and parameters that can be adjusted.

In this example, the dialogue to be triggered is Dialogue.Example.BasicSentences which matches with this row in DT_Dialogue

Adding world dialogies to actors #

Add AC_WorldIalogue_Manger to the actors or classes you would like to have world dialogue.

In the details panel you will be able to define some of the parameters. To understand the parameters go to proximity based dialogue.

Structures #

Structs_dialogue #

This struct defines a single block of dialogue data within the dialogue system.
Each entry represents a specific dialogue sequence, containing an identifier, delivery style, and the actual sentences spoken during the interaction.

Dialogue Identifier
 Type: Gameplay Tag
Purpose: A unique tag used to identify this dialogue sequence.
Usage:

  • Acts as the primary reference for triggering dialogue (e.g., through quests, NPCs, or cutscenes).
  • Example: Dialogue.Main.TheAwakening.Intro or Dialogue.Side.Blacksmith.Greeting.
  • Used to quickly locate and play a dialogue from a DataTable or dialogue manager.

Style
 Type: PDA Dialogue (Data Asset Reference)
Purpose: Defines the tone, mood, or presentation style of the dialogue.
Usage:

  • Controls how the dialogue is displayed or performed (voice tone, animation, or UI theme).
  • Example styles might include:
    • Cinematic: Used for story cutscenes.
    • Casual: Everyday conversations.
    • Urgent: Time-sensitive or combat-related lines.
  • Helps differentiate between narrative delivery types across different NPCs or contexts.

Sentences
 Type: Struct Dialogue Sentence (Array)
Purpose: Contains the list of individual sentences or lines that make up the full dialogue exchange.
Usage:

  • Each element represents a single line of dialogue, usually with its own speaker, text, and optional audio.
  • Allows complex dialogues to include multiple speakers in sequence.
  • Example:
    • NPC: “You finally woke up. We thought you were dead.”
    • Player: “Where am I?”
    • NPC: “Somewhere safe… for now.”
  • Enables branching dialogue systems or dynamic conversations by chaining sentences together.

Struct_dialogue_sentence #

This struct defines a single line or segment of dialogue within a conversation.
Each sentence can contain text, predefined or custom content, optional branching choices, and event triggers — allowing flexible control over how dialogue flows and interacts with gameplay systems.

Sentence Identifier
 Type: Gameplay Tag
Purpose: A unique tag used to identify this specific sentence within a dialogue sequence.
Usage:

  • Acts as a reference point for dialogue flow and branching.
  • Example: Dialogue.TheAwakening.Intro.Line01
  • Enables other systems or Blueprints to jump directly to a specific line when needed (e.g., from quests or triggers).

Next Sentence Identifier
 Type: Gameplay Tag
Purpose: Defines which sentence should play next after this one finishes.
Usage:

  • Used to chain dialogue lines together or create conditional branches.
  • Example:
    • Sentence_01 → leads to Sentence_02
    • Useful for non-linear dialogue trees and responses based on player choices.

Sentence Settings
 Type: Struct Dialogue Sentence Settings
Purpose: Controls the delivery and presentation of this sentence.
Usage:

  • Typically contains visual, timing, or speaker-related options such as:
    • Speaker Name or Actor Reference
    • Display Duration
    • Voice line reference
    • Cinematic camera settings
  • Ensures consistent control over how each sentence is presented to the player.

Predefined Sentence
 Type: PDA Predefined Sentence (Data Asset or Enum)
Purpose: References a stored, reusable sentence from a library of common lines.
Usage:

  • Ideal for frequently used phrases like “Thank you,” “Goodbye,” or “Be careful out there.”
  • Reduces repetition in data entry and ensures consistency across NPCs.
  • Used when the dialogue line is generic rather than unique to a specific character.

Custom Sentence
 Type: Struct Sentence Text
Purpose: Allows defining a unique, one-off sentence directly within this dialogue entry.
Usage:

  • Used for story-specific or character-specific lines that don’t exist in the predefined library.
  • Typically includes the dialogue text and possibly localization or emotion data.
  • Example: “You finally woke up. We thought you were dead.”

Options
 Type: Struct Dialogue Options
Purpose: Contains player choice options available at this point in the dialogue.
Usage:

  • Defines multiple response buttons or dialogue branches the player can choose from.
  • Example:
    • “Who are you?” → leads to sentence tag Line_03
    • “Where am I?” → leads to sentence tag Line_04
  • Supports interactive or branching conversations based on player selection.

Trigger Events After Sentence
 Type: Struct Dialogue Trigger Events (Array)
Purpose: Defines actions or events that occur after this sentence finishes playing.
Usage:

  • Can trigger gameplay effects, quest updates, or scene transitions.
  • Example uses:
    • Start a quest or stage.
    • Unlock a door or spawn an NPC.
    • Play a cutscene or sound effect.
  • Adds interactivity and consequence to dialogue.

Struct_dialogue_eventtriggers #

This struct defines actions or events that are automatically executed after a dialogue sentence finishes.
It allows dialogue lines to influence gameplay by triggering external systems such as quests, cinematics, or world interactions.

Event to Trigger
 Type: Gameplay Tag
Purpose: Identifies which event should be fired when the dialogue line completes.
Usage:

  • Acts as a link between dialogue and other gameplay systems.
  • Common examples:
    • Event.Quest.Start → Begins a quest.
    • Event.Scene.PlayCinematic → Plays a cutscene.
    • Event.World.UnlockDoor → Unlocks or spawns something in the world.
  • Used by the dialogue manager to locate and broadcast the correct event handler.

Target
 Type: Gameplay Tag
Purpose: Specifies the target actor, component, or system affected by the triggered event.
Usage:

  • Defines who or what receives the event.
  • Example:
    • Target.Player – affects the player character.
    • Target.NPC.Blacksmith – affects a specific NPC.
    • Target.WorldObject.Gate01 – affects an interactive world object.
  • Ensures events are directed to the correct recipient in the game world.

Value
 Type: Struct Generic Value
Purpose: Provides additional data or parameters needed for the triggered event.
Usage:

  • Used to pass context-specific information such as:
    • Numerical values (e.g., XP amount, delay time).
    • String values (e.g., dialogue tag, cinematic name).
    • Boolean toggles (e.g., “enable/disable object”).
  • Makes the event system flexible and data-driven for different event types.

Trigger Sequence
 Type: Struct Dialogue Trigger Sequence
Purpose: Defines the order and timing of multiple events triggered by this dialogue.
Usage:

  • Controls whether events trigger immediately, after delays, or in a specific sequence.
  • Example:
  1. 0s → Play sound effect
  2. 0s → Fade screen to black
  3. 0s → Start quest or cutscene
  • Allows cinematic or story-driven pacing between dialogue and gameplay transitions.

Struct_dialogue_sequence #

This struct defines cinematic or scripted sequences that can be triggered during dialogue.
It allows dialogue lines to play Level Sequences (cutscenes) and control player visibility, timing, and interaction while the sequence runs.

Should Trigger Sequence
 Type: Boolean
Purpose: Determines whether a Level Sequence should be played when this dialogue event occurs.
Usage:

  • If enabled (true), the dialogue manager will trigger the Level Sequence assigned below.
  • If disabled (false), the dialogue will skip any sequence-related actions.
  • Useful for toggling between cinematic and non-cinematic versions of dialogue.

Level Sequence to Trigger
 Type: Level Sequence (Asset Reference)
Purpose: Specifies which Level Sequence asset to play when triggered.
Usage:

  • Points to a cinematic or scripted scene (e.g., camera pans, animations, or environment actions).
  • Example: Seq_TheAwakening_Cutscene or Seq_BanditCampIntro.
  • Can be used to add immersive transitions or story-driven camera sequences during dialogue.

Freeze On Sequence End
 Type: Boolean
Purpose: Determines whether gameplay should remain paused or frozen after the sequence finishes.
Usage:

  • When enabled, the player and world remain paused at the end of the cinematic until resumed by another event.
  • Ideal for sequences that transition directly into another event or require player input to continue.
  • When disabled, gameplay resumes immediately after the sequence ends.

Hide Player
 Type: Boolean
Purpose: Controls whether the player character should be hidden during the sequence.
Usage:

  • Useful for cutscenes that use custom camera work, cinematic characters, or pre-rendered scenes.
  • When enabled, the player mesh is hidden from view for the duration of the sequence.
  • Often combined with freeze or camera-driven cinematics to avoid duplicate visuals.

Wait For Sequence End Before Next Sentence
 Type: Boolean
Purpose: Determines whether the dialogue system should wait until the Level Sequence finishes before continuing to the next sentence.
Usage:

  • Ensures dialogue and cinematics remain synchronized.
  • When enabled, the dialogue will pause until the sequence’s playback is complete.
  • When disabled, the next line of dialogue can begin while the sequence is still running (useful for overlapping speech).

Struct_dialogue_option #

This struct defines an interactive dialogue choice presented to the player during a conversation.
Each option contains the text displayed on-screen, conditions for visibility, what happens when selected, and where the dialogue should continue afterward.

Text
 Type: Text
Purpose: The visible dialogue choice shown to the player in the conversation UI.
Usage:

  • Represents what the player can say or choose in response to an NPC.
  • Example:
    • “Who are you?”
    • “Tell me about this place.”
    • “Goodbye.”
  • Appears as a selectable button or text line during dialogue interactions.

Spoken By Player
 Type: Struct IsSpokenByPlayer
Purpose: Determines if this line should be voiced or attributed to the player rather than an NPC.
Usage:

  • Helps control presentation (camera focus, subtitle color, etc.).
  • May include additional metadata such as the player’s voice line, emotion, or tone.
  • When false, the system treats it as a narrative or NPC-delivered response.

Condition
 Type: Struct DialogueCondition
Purpose: Defines any requirements or checks that must be met before this option becomes available.
Usage:

  • Used for branching dialogue or conditional responses.
  • Examples:
    • Requires completing a quest stage.
    • Requires a minimum reputation or skill level.
    • Requires a specific dialogue variable to be true.
  • If the condition fails, the option will be hidden or greyed out.

Next Sentence
 Type: Gameplay Tag
Purpose: Identifies the next sentence or dialogue branch to play when this option is selected.
Usage:

  • Directs the dialogue flow based on the player’s choice.
  • Example:
    • “Tell me more.” → DialogueTag.Next.Info
    • “Goodbye.” → DialogueTag.End.Conversation
  • Enables branching narrative structures.

Trigger Events On Select
 Type: Struct Dialogue_EventTriggers (Array)
Purpose: Defines events or gameplay actions that should occur when the player chooses this option.
Usage:

  • Allows player dialogue choices to have immediate consequences.
  • Examples:
    • Start or update a quest.
    • Change relationship values.
    • Play a sound or animation.
  • Multiple events can be triggered in sequence for complex responses.

Sentence Resolver
 Type: Struct DialogueSentenceResolver
Purpose: Handles any dynamic or runtime text resolution for this dialogue option.
Usage:

  • Used when the text includes variable data (e.g., player name, faction, or dynamic values).
  • Example:
    • “I brought you [ItemName].” → resolves to “I brought you Iron Ore.”
  • Ensures dialogue remains flexible and context-aware during gameplay.

Struct_option_dialogue_condition #

This struct defines the requirements and rules that determine whether a dialogue option or sentence can be shown, selected, or executed.
It allows dialogue to dynamically respond to the player’s progress, choices, quests, or memory variables — enabling reactive and branching conversations.

Has Condition
 Type: Boolean
Purpose: Determines whether this dialogue option uses any conditional checks.
Usage:

  • If true, the system evaluates all defined conditions before displaying or enabling the dialogue option.
  • If false, the dialogue is always available and unconditional.
  • Used as a simple toggle to activate or disable condition-based logic.

Hide When Not Met
 Type: Boolean
Purpose: Controls what happens when the condition fails.
Usage:

  • If true, the dialogue option will be hidden completely when the player doesn’t meet the condition.
  • If false, the option remains visible but may be greyed out or unselectable.
  • Allows designers to choose between transparent and subtle branching.

Consume Requirements
 Type: Boolean
Purpose: Defines whether the required items, progress flags, or conditions are consumed after use.
Usage:

  • If enabled, once the condition is met, it consumes its requirement (e.g., removes an item, flag, or variable).
  • Example: “Give the gem to the guard” consumes the gem after the dialogue completes.
  • Useful for trade, quest, or progression-based conversations.

Requirements
 Type: Struct Dialogue Requirements (Array)
Purpose: A list of general requirements that must be satisfied before this dialogue can be accessed.
Usage:

  • Defines simple conditional checks, such as:
    • Has Item
    • Has Attribute Value
    • Has Completed Quest
  • Each entry can represent a unique condition that must evaluate as true.

Quests Requirement
 Type: Struct Quest Requirement
Purpose: Specifies any quest-related conditions required for this dialogue to appear.
Usage:

  • Allows dialogue to unlock or change based on quest progress.
  • Examples:
    • “Only available during Stage 2 of Quest X.”
    • “Only visible after Quest Y is completed.”
  • Ideal for integrating quest-driven storytelling.

Speaking NPC Memory Requirement
 Type: Struct Memory Requirement
Purpose: Checks the current NPC’s memory or state for specific flags or stored variables.
Usage:

  • Useful for ensuring dialogue continuity or emotional memory.
  • Examples:
    • NPC remembers the player insulted them earlier.
    • NPC knows the player already bought an item.
  • Enables more natural, context-aware responses from recurring NPCs.

Player Memory Requirement
 Type: Struct Memory Requirement
Purpose: Checks the player’s memory or dialogue history for stored data or past interactions.
Usage:

  • Allows dialogue to react to what the player has done or learned previously.
  • Examples:
    • The player remembers a password.
    • The player already spoke to another character about this topic.
  • Supports branching dialogue based on player knowledge or choices.

Struct_dialogue_options_requirements #

This struct defines a single conditional requirement used within dialogue conditions.
Each entry specifies what tag (condition) to check and what value it must hold to allow the dialogue option or sentence to proceed.

Tag
 Type: Gameplay Tag
Purpose: Identifies the condition key or variable that must be checked.
Usage:

  • Represents the logical “name” of the condition.
  • Used to determine what part of the system or memory the condition refers to.
  • Examples:
    • Quest.Stage.Completed – checks if a specific quest stage is done.
    • Reputation.Village.Friendly – checks if player reputation is high enough.
    • Dialogue.Memory.KnowsPassword – checks if the player has learned certain information.
  • Used across systems for consistent and easily searchable condition identifiers.

Value
 Type: Struct Generic Value
Purpose: Defines the expected value or threshold associated with the tag being checked.
Usage:

  • Determines what must be true for the condition to pass.
  • Can represent different data types such as:
    • Boolean: True/False conditions (e.g., “HasKey = True”).
    • Integer/Float: Numerical thresholds (e.g., “Reputation ≥ 50”).
    • String: Text-based values (e.g., “Faction = Rebels”).
  • Allows highly flexible, data-driven condition checks across multiple dialogue contexts.

Struct_dialogue_sentence_resolver #

This struct controls dynamic dialogue resolution, allowing sentences or dialogue branches to adapt at runtime based on in-game conditions.
It is used when a dialogue line or option requires real-time logic — for example, resolving variables in text, triggering alternate follow-ups, or calculating the next valid sentence automatically.

Use Sentence Resolver
 Type: Boolean
Purpose: Determines whether this dialogue sentence uses a resolver for dynamic evaluation.
Usage:

  • When true, the dialogue manager calls the resolver logic to determine what happens next (text changes, next line, etc.).
  • When false, the sentence proceeds normally using predefined values.
  • Useful for special cases like conditional responses, adaptive conversations, or branching dialogue logic.

Resolver Class to Use
 Type: BP Sentence Resolver (Blueprint Class Reference)
Purpose: Specifies the Blueprint class that contains the resolver logic.
Usage:

  • Points to a Blueprint implementing custom logic for sentence evaluation.
  • Examples:
    • BP_Resolver_ReputationCheck – chooses a response based on faction reputation.
    • BP_Resolver_QuestStatus – picks a follow-up line depending on quest stage.
  • Enables designers to plug in modular, reusable resolution behaviors without modifying core systems.

Resolver Next Sentences
 Type: Gameplay Tag Array
Purpose: Lists the potential next dialogue sentences that the resolver can choose from.
Usage:

  • Acts as a pool of possible branches for the resolver to select at runtime.
  • Example:
    • DialogueTag.Response.Positive
    • DialogueTag.Response.Neutral
    • DialogueTag.Response.Negative
  • The resolver’s internal logic evaluates conditions and selects one of these tags to continue the conversation dynamically.
Example Use Case:
When the player greets an NPC, the resolver can check their relationship level and automatically choose one of several responses:
  • Friendly → “Good to see you again!”
  • Neutral → “Can I help you?”
  • Hostile → “You’re not welcome here.”

Struct_isspokenbyplayer #

This struct defines who delivers a specific line of dialogue — the player or an NPC — and determines how the system should handle the spoken sentence.
It allows customization of voice source, camera focus, and dialogue text depending on who is speaking.

Is Spoken By Player
 Type: Boolean
Purpose: Determines whether this line is spoken by the player character or by an NPC.
Usage:

  • When true, the line is attributed to the player.
    • May change UI color, camera position, or subtitle placement.
    • Can trigger the player’s voice-over (if one exists).
  • When false, the line is considered to be spoken by the NPC or world narrator.
  • Used by the dialogue manager to correctly handle presentation and logic.

Predefined Sentence
 Type: PDA Predefined Sentence
Purpose: References a standardized or reusable sentence for the speaker.
Usage:

  • Used when the player or NPC delivers a commonly repeated line.
  • Examples:
    • Player: “I’ll take a look.”
    • NPC: “Stay safe out there.”
  • Ensures consistency and avoids re-entering identical text multiple times.

Custom Sentence
 Type: Struct SentenceText
Purpose: Provides a unique line of dialogue specifically written for this interaction.
Usage:

  • Used for one-off or story-specific dialogue moments.
  • Contains the text that appears in the dialogue box (and may include localization data).
  • Example:
    • Player: “You’re hiding something. Tell me the truth.”
    • NPC: “I don’t know what you’re talking about!”
  • Takes priority over predefined lines when both are set.

Data assets #

Dialogue style #

This data asset defines the presentation and cinematic behavior of dialogue in the game.
It controls how dialogue appears on screen — including UI layout, text effects, speaker display, and camera handling — ensuring consistent tone and polish across different dialogue types (e.g., casual NPC chats vs. cinematic cutscenes).

Dialogue UI Style
 Type: Enum Dialogue UI Style
Purpose: Determines which visual layout or theme the dialogue uses.
Usage:

  • Allows switching between predefined styles such as:
    • Cinematic: Full-screen, immersive dialogue for story moments.
    • Minimal: Small dialogue box for casual conversations.
    • Subtitle-Only: For background or overheard dialogue.
  • Used to maintain consistency across different dialogue contexts.

Use Typewriter Effect
 Type: Boolean
Purpose: Enables or disables the typewriter text animation effect.
Usage:

  • When enabled, dialogue text appears one letter at a time for a cinematic feel.
  • When disabled, full sentences appear instantly.
  • Commonly enabled for slow-paced story scenes or emotional conversations.

Show Speaker Name
 Type: Boolean
Purpose: Determines whether the speaker’s name is displayed above or alongside the dialogue text.
Usage:

  • Enabled for standard conversations or quest dialogue.
  • Disabled for ambient background chatter or narrator text.
  • Example: “Elder Thalos: The forest whispers again…”

Prefix Sentences With Speaker
 Type: Boolean
Purpose: Automatically prefixes each sentence with the speaker’s name inside the text box.
Usage:

  • Useful when the same dialogue box is shared between multiple speakers.
  • Example:
    • With Prefix: “Thalos: We must hurry.”
    • Without Prefix: “We must hurry.”
  • Helps clarify speaker identity during group conversations.

Show Portrait
 Type: Boolean
Purpose: Determines whether to display a character portrait or image beside the dialogue text.
Usage:

  • Enabled for stylized dialogue UI (e.g., visual novel or RPG-style).
  • Disabled for fully cinematic scenes using 3D cameras instead of portraits.
  • The portrait is typically defined per character or per sentence.

Camera Mode
 Type: Enum Camera Mode
Purpose: Defines how the camera behaves during dialogue playback.
Usage:

  • Controls cinematic framing and focus transitions between speakers.
  • Common modes include:
    • Auto Move Camera: Automatically pans between speakers.
    • Static Camera: Keeps the camera fixed.
    • Cinematic Sequence: Uses predefined Level Sequence cameras.
  • Allows designers to fine-tune how immersive or cinematic a dialogue interaction feels.

Dialogue transition #

This struct controls how dialogue advances between sentences, including automatic continuation, manual player input, and skip behavior.
It ensures smooth pacing and player control across both cinematic and interactive dialogue sequences.

Auto Continue
 Type: Boolean
Purpose: Determines whether the dialogue should automatically proceed to the next sentence after a set delay.
Usage:

  • When true, the system moves to the next line automatically once the timer expires.
  • When false, the dialogue waits for player input or a trigger event before continuing.
  • Ideal for cutscenes or non-interactive conversations where pacing is predetermined.

Auto Continue Timer
 Type: Float
Purpose: Defines how long (in seconds) to wait before advancing automatically when Auto Continue is enabled.
Usage:

  • Controls the timing between lines for cinematic pacing.
  • Example:
  1. 0 seconds → next sentence plays after a 2-second pause.
  • Can be adjusted per scene to match voice-over length or animation timing.

Manual Continue
 Type: Boolean
Purpose: Allows the player to manually advance dialogue by pressing a key or clicking.
Usage:

  • When enabled, the player controls pacing by confirming when to continue.
  • When disabled, dialogue proceeds automatically.
  • Commonly used for gameplay-integrated dialogue or branching conversations with player choices.

Skip Mode
 Type: Enum Dialogue Skip Mode
Purpose: Defines how the dialogue behaves when the player chooses to skip or fast-forward.
Usage:

  • Allows developers to choose how skipping affects pacing or animations.
  • Typical options include:
    • Instant: Skips immediately to the next sentence or dialogue end.
    • Speed Up: Increases the text speed and reduces delays for faster reading.
    • Disabled: Prevents skipping entirely (useful for critical story moments).
  • Helps balance accessibility and narrative integrity.

Auto gibberish Profile #

The Auto Gibberish Profile defines how a character’s nonsensical voice sounds (e.g., mumbling, alien speech, creature noises, or stylized “Simlish”-like effects) are generated and synchronized with dialogue text.
It controls which sound cues play during dialogue, how fast they play, and allows custom overrides for specific situations or predefined dialogue tags.

This feature helps bring characters to life even without recorded voice acting, giving unique vocal personality to each speaker.

Sound To Loop
 Type: Sound Cue
Purpose: The base looping sound played when a character “speaks.”
Usage:

  • Loops continuously while text is being displayed on-screen.
  • Typically a subtle vocalization, such as murmuring, growling, or gibberish speech.
  • Can be tailored per character for personality (e.g., deep growl for monsters, cheerful chatter for merchants).

Words Per Minute
 Type: Integer / Float
Purpose: Defines the speech speed of the gibberish playback.
Usage:

  • Controls pacing of the looping sound or timing between syllabic noises.
  • Higher values produce faster, more energetic delivery.
  • Example:
    • 120 → normal conversational pace.
    • 180+ → fast talkers or panicked dialogue.
    • 80 → calm or sleepy delivery.

Override on Predefined Dialogue
 Type: Map (Gameplay Tag → Sound Cue)
Purpose: Allows specific predefined dialogue lines (identified by tags) to use custom sound cues instead of the default loop.
Usage:

  • Provides fine control over sound playback per emotion, state, or situation.
  • Example Overrides:
    • PredefinedDialogues.Movement.EffortLight → SC_Gideon_Effort_Attack
    • PredefinedDialogues.Movement.EffortHeavy → SC_Gideon_Effort_HeavyAttack
  • Common use cases:
    • Unique vocalizations for laughter, pain, surprise, or combat grunts.
    • Distinct vocal sets for different moods or animation contexts.

Predefined Voices #

The Predefined Voices Data Asset defines the voice profiles available in the game and the corresponding audio lines, subtitles, and animations used for specific dialogue sentences.
Each voice profile represents a speaker type (e.g., Player_Masculine, Player_Feminine, Merchant, Creature) and stores the unique assets tied to that character’s speech delivery.

This data asset allows designers to reuse standardized voice sets across multiple dialogues, ensuring consistent tone, pacing, and presentation.

Voice To Sentence
 Type: Map (Voice Tag → Voice Sentence List Struct)
Purpose: Maps a voice profile (e.g., Player_Masculine) to an array of sentences that contain voice data, subtitles, and optional animation triggers.
Usage:

  • Each key represents a voice profile, typically defined by a Gameplay Tag.
  • Each value is a list of sentences, allowing multiple lines per voice (e.g., grunts, exclamations, one-liners).
  • Example key: Player.Masculine
  • Example value: one or more voice lines, such as “I’m carrying too much!” or “Let’s move out.”

Sentences
 Type: Array of Structs
Purpose: Defines the audio and contextual data for each individual line of dialogue.
Usage:
 Each entry contains the following variables:

Audio
 Type: Sound Base (Sound Cue or Wave)
Purpose: The audio file to play when the sentence is spoken.
Usage:

  • Assign the actual voice recording or sound cue that represents the spoken line.
  • Example: SC_Player_Grunt, SC_Player_OverEncumbered.
  • Leave empty if using text-only or auto-generated gibberish dialogue.

Spoken Text
 Type: Text
Purpose: The subtitle text or written version of the spoken line.
Usage:

  • Appears on the dialogue UI or subtitle system.
  • Should match the recorded audio for consistency.
  • Example: “I’m carrying too much!”

Should Play Animation While Saying Sentence
 Type: Boolean
Purpose: Determines whether the speaker should play a talking or reaction animation during this line.
Usage:

  • When enabled, the system triggers the assigned Montage (see below).
  • Useful for voiced dialogue where the actor should move or emote while speaking.

Montage To Play On Sentence Start
 Type: Animation Montage
Purpose: Defines an animation montage to play when the sentence begins.
Usage:

  • Optional. Used to sync facial animations, gestures, or body movements to dialogue.
  • Example: AM_Talk_Normal, AM_Shout_Angry, AM_React_Pain.

Memory Context
 Type: Struct MemoryContext
Purpose: (Optional) Provides contextual memory or emotional state data for the line.
Usage:

  • Used by advanced systems that track NPC memory or emotional tone.
  • Allows dynamic responses based on relationships, past events, or player actions.
  • Example: the same line “You again?” may sound friendly or irritated depending on memory context.
Example Use Case:
Voice Profile: Player_Masculine
  • Audio: SC_Player_TooHeavy
  • Spoken Text: “I’m carrying too much!”
  • Animation: AM_Player_Exertion
  • Memory Context: Frustrated / Low Stamina

Voice Profile: Player_Feminine

  • Audio: SC_Player_Female_TooHeavy
  • Spoken Text: “Ugh, this pack is so heavy…”

Data Tables #

Dt_dialogues #

Adding your own sentence to the dialogue #

Add a new Dialogue row (step-by-step)

  • Open the Data Asset / Table
    • In Content Browser, open your DT_Dialogue that holds dialogues.
  • Create a new row/entry
  • Click + (Add) to insert a new dialogue entry.
  • Rename the row (if it’s a DataTable) to the dialogue identifier you select
  • Dialogue Identifier
  • Field: Dialogue Identifier (Gameplay Tag)
  • Example: Dialogue.Blacksmith.Intro
  • This tag is how Blueprints/quests trigger this dialogue.
  • Style
  • Field: Style (Dialogue Style DA)
  • Choose a style asset (e.g. DA_DialogueStyle_Generic, DA_DialogueStyle_Cinematic).
  • This controls UI (name/portrait, typewriter, camera mode, etc.).
  • Add the first sentence
  • Expand Sentences → click + to add Index [0].

    a) Sentence Identifier (Gameplay Tag)

    • Example: Dialogue.Blacksmith.Intro.Line01.
  • Next Sentence Identifier
  • Leave None if this is the only line, or set the tag of your next line (e.g. …Line02).
  • Sentence_Settings
  • Set speaker (NPC vs Player), portrait/camera if your settings struct supports it, and any VO reference.
  • Choose one content source:
    • Predefined_Sentence: pick a reusable line from your predefined library (e.g. PDA_PredefinedSentence.Greeting_Generic), or
    • Custom_Sentence: expand and enter your unique text (e.g. “Welcome! Need your blade mended?”).
  • Options
  • Click + to add an option:
    • Text: e.g. “Can you repair my gear?”
    • Condition (optional): require a quest/memory/reputation.
    • Next Sentence: tag to branch to (e.g. …RepairInfo).
    • Trigger Events On Select (optional): start quest, open shop, etc.
  • Trigger Events After Sentence
  • Add events that fire when this sentence finishes (e.g. start quest, play sequence).

  • Add more sentences (if needed)
  • Click + again inside Sentences for Index [1], Index [2], etc.
  • Give each a Sentence Identifier, content (Predefined or Custom), and set the previous line’s Next Sentence Identifier to this new line’s tag.
  • (Optional) Use a Resolver for dynamic flow
  • If a line should auto-choose the next sentence based on conditions (reputation/quest):
    • In that sentence’s Sentence Resolver:
      Use Sentence Resolver = ☑
    • Resolver Class to use = your BP_SentenceResolver_*
    • Resolver Next Sentences = list the candidate sentence tags.
  • Save
    • Press Save on the asset/DataTable.
  • Hook it up in game
    • From your NPC, trigger the dialogue by tag (e.g., via your Dialogue Manager):
      • PlayDialogueByTag( Dialogue.Blacksmith.Intro )
    • Or start it from a quest stage / interaction.

Predefined Voices #

Overview #

The Predefined Voices system provides a streamlined way to manage consistent voice delivery across multiple characters and dialogue lines.
Rather than assigning audio and subtitles manually for every individual dialogue, predefined voices allow designers to define reusable voice profiles — such as Player_Masculine, Player_Feminine, or Merchant_OldMan — each with their own set of recorded lines, subtitles, and animations.

This ensures that:

  • The same voice tone and delivery style is used across different dialogues.
  • Voice assets can be quickly referenced by tag (e.g., for generic responses, combat grunts, or emotional outbursts).
  • Designers can easily update or replace voice sets without editing individual dialogues.
  • Optional animation and memory data keeps voice playback visually and contextually believable.

In short, Predefined Voices serve as the central library of reusable vocal assets for all characters, helping maintain quality, consistency, and efficiency across the entire dialogue system.

Adding your own predefined voice #

Navigate to this file location.

Right click in your content browser and locate “Dialogue Voice” then rename the file. Choose the options you desire for gender and plurality.

Next, open up a predefined data assetthat you wish to add the new voice to.

Add a new element, scroll to the bottom of the list and add the new dialogue voice to the empty element you just added.

When to use predefined sentences #

Predefined dialogues are used for lines of dialogue that remain consistent across multiple interactions or characters — such as greetings, farewells, acknowledgements, or other commonly repeated phrases.

By storing these fixed lines separately, you can:

  • Ensure consistency in tone and phrasing throughout the game.
  • Save time when creating conversations, since you can easily reuse existing responses.
  • Maintain cohesive personality or speech style for different characters using shared dialogue sets.

In short, predefined dialogues handle all the standard, frequently used conversational elements — freeing up the main dialogue system for more dynamic or story-specific lines.

Sentence Types #

The dialogue system supports two main interaction types — Fixed Dialogue and World Dialogue — each serving a distinct gameplay purpose and presentation style.

Fixed Dialogues #

Description:
 Fixed dialogue refers to direct, face-to-face interactions between the player and an NPC.
It is typically initiated through an interaction prompt (e.g., “Talk” or “Speak”) and is presented using the full dialogue UI.

Characteristics:

  • Player and NPC are locked into a focused conversation state.
  • The camera may switch to a cinematic or conversational view.
  • UI elements such as speaker names, portraits, and choices are displayed.
  • Often used for story, quests, trading, or recruitment interactions.
Example:
The player speaks to a blacksmith:

Blacksmith: “Your blade looks worn. Shall I repair it for you?”
Player Option 1: “Yes, please.”
Player Option 2: “Not right now.”

World Dialogue #

Description:
 World dialogue is ambient or situational speech that occurs dynamically during gameplay without opening the dialogue UI.
It plays automatically based on conditions such as stamina, damage, carrying weight, or events happening nearby.

Characteristics:

  • Triggered automatically by gameplay events.
  • Does not lock the player in place or interrupt control.
  • Typically uses predefined voices or auto gibberish instead of full dialogue sequences.
  • Often used for immersion, feedback, or flavor dialogue.
Example:
While exploring, the player becomes over-encumbered:

Player (shouts): “Ugh, I’m carrying too much!”

Fixed Dialogue sentences #

Basic sentences in a dialogue #

Purpose:
 A standard line of dialogue with no additional conditions or branching logic.

Behavior:

  • Displays a line of text or plays a predefined voice/audio line.
  • May automatically transition to the next sentence or wait for player input.
  • Used for most static lines of dialogue or simple interactions.

Here we have a very rude NPC telling us that they don’t like us. This is a basic sentence.

Random sentences in a dialogue #

Purpose:
 Allows the system to randomly select from a list of possible sentences.

Behavior:

  • When triggered, one sentence from a predefined array is chosen at random.
  • Often used to make conversations feel less repetitive or predictable.
  • Can be influenced by tags such as mood, relationship, or memory context.
Example:

NPC might say one of the following:

  • “Lovely weather today!”
  • “Rain again, huh?”
  • “Feels like a storm’s coming…”

For my random reaction, I am using the Data Asset Taunt. Which includes an array of combat taunts in reaction the the basic sentence from the NPC saying “I don’t like you”

My character will now randomly select one of these indices. Ensure that the predefined voice is correct with the character you are using.

Choices and memory in a dialogue #

Purpose:
 Enables branching dialogue and long-term NPC reactivity by combining player choices with the memory system. This allows NPCs to remember previous interactions and adjust future conversations dynamically.

Behavior:

  • When the player selects a dialogue option, the system can record that choice as a memory.
  • Each memory is stored using a Gameplay Tag identifier (e.g. Memory.Blacksmith.Trusted, Memory.Guard.BribeAttempted).
  • These tags can later be checked as conditions for other dialogue sentences or responses, allowing NPCs to “remember” what the player has said or done.
  • Future dialogue can reference these tags to unlock new lines, change tone, or block access to certain options.

Gameplay Tags as Identifiers:

  • Every memory is saved with a Gameplay Tag, ensuring a simple, modular, and data-driven way to track dialogue history.
  • Example memory tags:
    • Memory.Villager.PlayerWasRude
    • Memory.BanditPlayerBribed
    • Memory.Merchant.DebtUnpaid
  • These tags are read by the dialogue condition system to alter future responses.
  • Because they’re tag-based, designers can easily add new memories without extra code — simply reference the tag in future dialogue conditions.
Example Flow:
  • Initial Dialogue:


     Player: “You can trust me.”
    → Stores tag: Memory.Blacksmith.PlayerPromisedTrust
  • Later Dialogue:
     NPC checks for that tag before choosing their line:
    • If Memory.Blacksmith.PlayerPromisedTrust exists →

      Blacksmith: “You again… I remember your promises.”

    • If not →

      Blacksmith: “Need something forged?”

Triggering events in a dialogue #

Purpose:
 Links dialogue lines to gameplay events such as quests, animations, or world actions.

Behavior:

  • When the sentence is spoken or completed, an event is fired.
  • Used to trigger quests, cinematic sequences, world changes, or AI behaviors.
  • Controlled through the Trigger Events After Sentence or Trigger Events On Select structs.
Example:

Guard: “I’ll open the gate for you now.”
→ Event: Gate unlock animation plays.

Conditional dialogue and requirements #

Purpose:
 Allows dialogue to appear only when specific conditions or requirements are met.

Behavior:

  • Checks predefined conditions before showing a sentence or choice.
  • Conditions can include:
    • Active or completed quests.
    • Relationship or morale levels.
    • Inventory items or skills.
    • Memory or reputation states.
  • If unmet, the dialogue may hide or show an alternate line.
Example:

Blacksmith only says: “I can forge that sword for you.”
→ If the player owns Iron Ore x3 and has *Smithing Level 2+.

Timed dialogue choices #

Purpose:
 Adds time-limited player responses for fast-paced or emotional interactions.

Behavior:

  • Displays multiple player options but includes a countdown timer.
  • If the timer expires, a default or “silent” response is automatically chosen.
  • Creates urgency and realism in tense or dramatic scenes.
Example:

NPC: “Will you save him?”
(Choices: “Yes!” / “No.” / “Stay silent”)
→ Timer: 5 seconds.
→ If no input, defaults to silence.

Chance based outcomes (resolver system) #

Purpose:
 Adds probabilistic results or skill checks to dialogue choices.

Behavior:

  • When the player makes a certain choice (like “Bribe” or “Convince”), a resolver Blueprint runs to determine success or failure.
  • The resolver can factor in:
    • Player stats (charisma, skill, etc.)
    • Random chance (e.g., 60% success)
    • Relationship or reputation modifiers.
  • Each outcome can lead to different sentences or events.
Example:

Player: “Take this gold and look the other way.”
→ Resolver checks: Bribe success chance = 65%.
→ If success: “Fine… I didn’t see anything.”
→ If fail: “You think you can buy me?”

Force dialogue in proximity #

Purpose:
 Automatically triggers a dialogue sequence when the player enters a specific area or approaches an NPC.

Behavior:

  • Uses a trigger box, sphere, or event volume to detect proximity.
  • Starts dialogue without player interaction (useful for ambient or cinematic dialogue).
  • Can optionally restrict player movement during the event.
  • Often used for story introductions, warnings, or environmental reactions.
Example:

As the player walks near a burning village:
NPC shouts: “The bandits are attacking! Help us!”

World dialogues #

World dialogue manager – core #

The World Dialogue Manager is responsible for controlling how predefined and custom world dialogues are played throughout the game.
Unlike fixed (face-to-face) conversations, world dialogue occurs dynamically — allowing characters to speak or react naturally during gameplay without interrupting player control.

System Overview

The World Dialogue Manager coordinates between several key components to deliver seamless, reactive in-world speech:

  • Voice Component
     Ensures the correct voice profile or gibberish system is used for each character.
    This guarantees that the right tone, gender, and sound set are selected dynamically (e.g., Player_Masculine, Creature_VocalSet).
  • World Dialogue Component
     Handles the injection of sentences into the system at runtime.
    It selects which predefined or custom line should be spoken, applies conditions (such as encumbrance, injury, or combat state), and passes the line to the correct voice channel for playback.
  • Trigger System
     World Dialogue can be initiated in multiple ways:
    • Automatic: Triggered by proximity, state changes, or events (e.g., entering a zone, being hit, running out of stamina).
    • Manual: Triggered by scripted or designer-placed events (e.g., event pads, cutscene nodes, or Blueprint calls).

Purpose

The World Dialogue Manager brings life and personality to the world by allowing characters to speak contextually —
reacting to what’s happening around them without the need for full dialogue UI.
It’s ideal for:

  • Combat reactions
  • Environmental comments
  • Emotional exclamations
  • Player fatigue or status lines
  • Ambient chatter between AI survivors

Proximity based dialogue #

The Proximity-Based Dialogue system allows NPCs to naturally greet the player as they approach and say goodbye as they move away.
It’s designed to make the world feel more alive by giving characters ambient awareness and reactive voice lines without needing full conversation sequences.

System Overview

  • Proximity Sphere Trigger
     Each NPC is equipped with a proximity sphere that detects when the player enters or exits a defined range.
    When the player crosses this boundary, the NPC automatically triggers a predefined dialogue — such as a greeting or farewell.
  • Predefined Dialogue Sets
     NPCs use voice or text lines defined in the Predefined Dialogue Data Assets.
    These can be simple single-line responses or randomized lists, allowing each greeting to feel slightly different.
    Example:
    • “Hey there, stranger!”
    • “Good to see you again!”
    • “Stay safe out there.”
  • Chance of Dialogue in Proximity
     The variable ChanceOfDialogueInProximity determines how often proximity-based dialogue occurs.
    • Value 1.0 (100%) = Dialogue always triggers when in range.
    • Value <1.0 = Dialogue may only trigger occasionally, giving a more natural, varied feel.
  • Sequencing and Flow Control
     The system prevents interruptions and overlapping lines:
    • The Goodbye only triggers once the Greeting has fully finished playing.
    • This ensures a smooth, believable exchange rather than two lines colliding.

Example Behavior

  • Player enters NPC’s proximity:
     NPC detects overlap → Random greeting plays (100% chance).

    “Welcome back, traveler!”

  • Player remains nearby:
     No further proximity lines trigger until cooldown expires.
  • Player exits range:
     After the greeting has completed, the goodbye is triggered.

    “Take care out there!”

In this example, if you walk within 300 radius of the character, they will play the predefined dialogue greeting. When leaving the proximity they will say a predefined goodbye. It is set to happen 100% of the time.

Predefined sentence mapping #

The Predefined Sentence Mapping system ensures NPCs speak appropriate and context-driven dialogue by linking sentence types directly to specific voice profiles and conditions.
This system combines data-driven mapping, memory checks, and randomization to produce natural, varied, and personality-aware speech.

System Overview

  • Voice-Linked Sentences
     Each predefined sentence type (such as Greeting, Combat, Vendor, or Follower) is tied to a specific voice profile.
    This ensures that every NPC or character type uses the correct vocal tone and delivery — for example, a Guard sounds different from a Merchant, even when using similar dialogue categories.
  • Automatic Sentence Mapping
     When a dialogue event (e.g., greeting, combat start, trade) is triggered, the system automatically looks up the matching sentence for that NPC’s Voice Profile.
    It retrieves the correct line from the Predefined Voices Data Asset, based on tags such as:
    • PredefinedDialogue.Greeting
    • PredefinedDialogue.CombatAlert
    • PredefinedDialogue.VendorFarewell
  • Randomization for Variety
     If multiple valid sentences exist for the same tag or dialogue type, the system selects one at random.
    This prevents repetition and adds realism — NPCs don’t repeat the same line every time.
    Randomization can be influenced by:
    • NPC mood or morale
    • Relationship with the player
    • Gameplay context (e.g., health, fatigue, danger level)
  • Memory-Aware Responses
     Some predefined dialogues include memory-based conditions, allowing NPCs to tailor their speech based on prior interactions.
    Using Gameplay Tags as memory identifiers, NPCs can recall past events and choose different predefined responses accordingly.
    Example:
    • If Memory.Merchant.PlayerHaggled exists → “No discounts today, you took advantage last time.”
    • Otherwise → “Always a fair price for a friend.”

Audio handling #

The World Dialogue Manager supports two distinct audio systems for delivering NPC speech:

  • Recorded Voice Lines — pre-made, fully voiced dialogue.
  • Auto Gibberish Generation — procedurally generated “simulated speech” that adapts dynamically to sentence timing and tone.

This dual setup gives developers complete flexibility between high-quality voice acting and scalable, data-driven audio simulation.

System Overview

  • Recorded Audio (Predefined Sentences)
     When Auto Gibberish is disabled, each predefined or custom sentence must include a manually assigned Sound Cue.
    This method is ideal for cinematic or story-critical dialogue where emotional nuance and delivery are important.

    Example:

    NPC: “You shouldn’t have come here…”
    → Uses SC_GuardThreat_VO_Male01 sound cue.

  • Auto Gibberish (Dynamic Speech Generation)
     When Auto Gibberish is enabled, the system automatically produces simulated speech sounds that match the timing and pacing of the sentence text.
    • Works with any dialogue line — no pre-recorded audio required.
    • Can use different gibberish profiles (e.g. Deep Male, Soft Female, Creature Growls) to vary tone and character type.
    • Automatically syncs to the dialogue duration, producing consistent “speech-like” patterns.
  • Example:

    NPC “speaks” using synthesized mumbles in rhythm with text speed.

  • Hybrid Handling (Overrides)
    Auto Gibberish can be selectively overridden for specific sentences:
    • If a recorded voice line is assigned to a sentence, it automatically replaces gibberish playback.
    • This allows mixing systems seamlessly — for example, using gibberish for ambient chatter but recorded lines for main story moments.

Configuration Notes

  • Auto Gibberish settings are defined in the Auto Gibberish Profile Data Asset.
  • Each profile includes:
    • Default looping sound
    • Words-per-minute pacing
    • Optional tag-based sound overrides (e.g. EffortLight, EffortHeavy, Laugh, Grunt)
  • Designers can easily adjust these parameters per voice type to achieve unique vocal styles.

Interactive world reactions #

The Interactive World Reactions system brings NPCs and the player to life by allowing predefined dialogue to be triggered directly from gameplay events.
This makes NPCs context-aware — reacting naturally to what’s happening in the world, whether that’s combat, interaction, or environmental events.

System Overview

  • Event-Driven Dialogue Triggers
     Dialogue lines can be fired from almost any in-game event or interaction.
    Common examples include:
    • Interacting with an object (e.g., looting a chest, harvesting resources).
    • Picking up or crafting an item.
    • Entering combat or dealing damage.
    • Using a skill, ability, or weapon.
    • World interactions, such as lighting a campfire or opening a door.
  • These events send a dialogue request to the World Dialogue Manager, which selects and plays the appropriate predefined sentence.
  • Predefined Dialogue Categories
     To keep dialogue organized and scalable, different categories exist within the system:
    • PredefinedDialogue.WorldInteraction – Used for general world actions (e.g., “Got it.” / “That should do it.”).
    • PredefinedDialogue.VendorResponse – Plays when trading or selling items (e.g., “Pleasure doing business.”).
    • PredefinedDialogue.CombatReaction – For combat feedback or reactions (e.g., “I’m hit!” / “They’re retreating!”).
    • PredefinedDialogue.SkillUse – For dialogue triggered when using a specific ability or performing a task.
  • Dynamic Event Hooks
     Any gameplay Blueprint or component can trigger dialogue by calling the Play Predefined Sentence function and passing in:
    • The event type (Gameplay Tag).
    • The target actor or NPC who should speak.
    • Optional context (e.g., location, target, or condition).

Custom sentences in world dialogues #

The World Dialogue Manager doesn’t just rely on predefined data — it also supports Custom Sentences, allowing designers or gameplay systems to inject unique dialogue at runtime.
This enables highly specific or story-driven lines without needing a dedicated predefined entry.

System Overview

  • Per-Instance Dialogue Lines
     Custom sentences can be created for any dialogue instance, bypassing predefined tags entirely.
    This is ideal for:
    • Scripted story events
    • Dynamic AI reactions
    • Procedurally generated conversations
    • Temporary or one-off dialogue that doesn’t justify a DataTable entry
  • Example:

    During a horde event, a survivor could say:
    “They’re coming through the walls!” — generated on the spot, not stored as predefined dialogue.

  • Dynamic Injection
     Custom sentences are injected directly into the subtitle system and can be played at runtime.
    • The system automatically handles timing, audio playback, and subtitle display.
    • Designers can pass in custom text, speaker, and optional sound or animation references.
  • Audio Handling Options
     Like predefined lines, custom sentences can:
    • Use Auto Gibberish, generating speech dynamically.
    • Be linked to a specific audio file (e.g., a one-off voice recording or SFX cue).
    • Be completely text-only, useful for debugging or silent communication.
What are your Feelings