Skip to content

Dialogue Template ProOnly¶

The Dialogue template gives you a working conversation system built on Logic Driver. Out of the box it handles speaker tracking, player choices, DataTable-driven text, and a simple UI, so you can focus on writing your dialogue content rather than plumbing.

It is not meant to be production ready as-is. Think of it as a well-structured starting point that you can reshape to fit your game.

Prerequisites

Before diving in, it helps to be familiar with Custom Node Classes, Text Graph Properties, and the basics of State Machine Instances. The Designing a Dialogue System guide covers the general concepts this template is built on.

Installation¶

Install the template from the Logic Driver utility launcher in the level toolbar under Content Samples. See Content Samples for details.

Once installed, the template creates two directories:

  • Template/ contains core reusable files: components, node classes, a base state machine, data structures, and UI widgets. These are designed to be used directly in your project and do not depend on any shared plugin content.
  • Samples/ contains working examples that demonstrate various dialogue patterns using the template files. These include Blueprints, a sample map, input actions, a DataTable, and six dialogue state machines.

Architecture Overview¶

The dialogue system is organized into four layers. Each layer builds on the one below it, so the whole system stays modular. You can swap out the UI without touching the node classes, or replace the components without changing your state machines.

  • Components

    Two actor components manage the dialogue lifecycle. One goes on each character that can talk; the other goes on the GameMode to own the UI.

  • Base State Machine

    A shared SMInstance subclass that all dialogue state machines inherit from. It resolves the speakers automatically so your individual dialogues do not need boilerplate setup.

  • Node Classes

    Four Blueprint node classes handle displaying text, presenting choices, and controlling transitions. They extend Logic Driver's state and transition base classes.

  • UI Widgets

    A dialogue widget and a choice-button widget. The system creates and manages these at runtime. You just need to style them.

Components¶

Two actor components handle the runtime side of conversations. They take care of starting, advancing, and finishing dialogue so that your state machines can focus purely on content.

AC_LogicDriverDialogue¶

Attach this to any character that can participate in conversations. It extends SMStateMachineComponent, which means it directly owns and runs a dialogue state machine.

This component owns and runs the dialogue state machine for its character.

You will typically configure two things on each character:

  • Character Name (Text): The display name shown in the dialogue UI when this character is speaking.
  • Talk Distance (Float): How close another character must be to start a conversation. Defaults to 150.

There is also a Draw Trace Debug toggle that visualizes the interaction range, which is handy while tuning Talk Distance in the editor.

AC_LogicDriverDialogueManager¶

Attach this to your GameMode. Its job is simple: on begin play, it creates the dialogue UI widget and provides a central reference point for the dialogue system to display text and choices.

You do not need to configure anything on this component. It creates the WBP_Dialogue widget automatically.

Base State Machine¶

FSM_DialogueBase is the parent class for all dialogue state machines in the template. It extends SMInstance and handles the one piece of setup that every conversation needs: figuring out who is talking.

When the state machine starts, it grabs the AC_LogicDriverDialogue component from its context actor and stores references to both participants: "this speaker" and "other speaker." Every node in the conversation can then access these without any manual wiring.

All six sample state machines inherit from this base class. When you create your own dialogue state machines, inherit from it too.

Node Classes¶

The template defines four Blueprint node classes. Together, they form a small vocabulary for building conversations: a node that displays a line of dialogue, a node that represents a player choice, a transition that controls the flow between them, and a shared base class.

These are self-contained Blueprint classes that extend Logic Driver's built-in base classes (SMStateInstance and SMTransitionInstance) directly. No C++ or additional plugins are required. See Designing a Dialogue System for the underlying concepts.

FSMN_DialogueBase¶

The shared base class for dialogue state nodes, extending SMStateInstance. Most of the reusable dialogue logic lives here so that FSMN_Dialogue and FSMN_DialogueChoice can stay focused on their specific jobs.

It handles:

  • Text display. Each node has a Dialogue Text property using SMTextGraphProperty. This lets you write text directly in the node, or bind it to variables and expressions for dynamic content.
  • Speaker tracking. Maintains a reference to the previous speaker so the system knows when the speaker changes between lines.
  • DataTable support. Can load dialogue data from a DataTable using a row name, enabling data-driven dialogue. Configure the Data Table and row name in the class defaults when you want a node to pull its text from a table instead of the text graph property.
  • End state detection. Checks whether a conversation should close based on the node's end state configuration.

The node handles delegate binding and cleanup on state begin and end.

FSMN_Dialogue¶

The primary dialogue node, extending FSMN_DialogueBase. This is the node you place for each line of dialogue. It displays its text through the widget system and handles presenting choices to the player when choice nodes are connected.

Each node has a Speaker property that you set per node in the graph. This is how you assign different characters to different lines.

Note

FSMN_Dialogue has bRegisterWithContextMenu set to True, so it appears directly in the graph's right-click context menu for quick placement.

FSMN_DialogueChoice¶

Represents a player choice, extending FSMN_DialogueBase. When the player selects a choice, the state machine transitions into this node. The node's Dialogue Text serves as the choice label shown in the UI.

Choice nodes use two class default settings to keep the graph tidy:

  • bRegisterWithContextMenu = True, so choice nodes appear in the context menu.
  • bHideFromContextMenuIfRulesFail = True, so they only appear when placement rules allow it (for example, only from dialogue nodes), preventing accidental placement in invalid locations.

FSMN_DialogueTransition¶

The custom transition class for dialogue flow, extending SMTransitionInstance. It manages several behaviors that would otherwise require manual setup on every transition:

  • Skip Already Selected Choices. A configurable property that prevents the player from picking the same choice twice. Set it to false on choices that should remain available.

Dialogue transitions display with custom coloring in the graph editor (bUseCustomColors = True), making them visually distinct from other transition types.

UI Widgets¶

The template includes two widgets that handle the visual presentation of conversations.

WBP_Dialogue is the main dialogue widget. It displays the speaker name, dialogue text, and any choice buttons. The dialogue manager creates this widget on begin play, so you do not instantiate it yourself.

WBP_DialogueOption is a single choice button. The dialogue widget creates one of these for each available choice. When clicked, it triggers the dialogue system to transition to the selected choice node.

Both widgets are intentionally minimal. They are meant to be restyled or replaced entirely to match your game's look.

Data Structure¶

F_DialogueData is a simple struct used in the DataTable sample. It contains dialogue content fields that the node classes read at runtime. You can extend it with additional fields (audio cues, animation references, speaker overrides) for your project.

Sample State Machines¶

The template includes six sample state machines, each demonstrating a different dialogue pattern. Open the sample map (Dialogue_ExampleMap) to interact with all of them.

Getting Started¶

FSM_Dialogue_GettingStarted is the simplest possible dialogue: just two nodes connected by a transition. The first node displays a line, the player presses continue, and the second node displays another line. That is the entire conversation.

This is a good place to start reading. It shows the fundamental pattern: dialogue nodes hold text, transitions wait for player input, and the conversation flows forward one node at a time.

Behavior¶

FSM_Dialogue_Behavior demonstrates how Node Behavior rules can streamline the editing experience. It is a simple linear sequence of dialogue nodes, but with behavior rules configured on the node classes.

This sample shows three patterns:

  1. Auto-placed transitions. Any transition leading out of a dialogue node is automatically converted to FSMN_DialogueTransition. Designers do not need to remember to set the transition class; the behavior rule handles it.
  2. Restricted placement. Dialogue choice nodes can only be placed from dialogue nodes, preventing invalid graph structures.
  3. Editor-only enforcement. Behavior rules exist purely to help with editing. They are not enforced at compile time and have no runtime cost.

Tip

Behavior rules are one of the most useful quality-of-life features when building a dialogue system with multiple designers. They enforce conventions automatically so nobody can accidentally wire things up wrong.

Choices¶

FSM_Dialogue_Choices demonstrates branching dialogue with player choices. This is where the system starts to get interesting.

A dialogue node branches to five choice nodes:

  • First Choice transitions to Dialogue Node 1, which loops back to the main Dialogue Node.
  • Second Choice and Third Choice loop back to the main Dialogue Node directly. The transition's Skip Already Selected Choices property is set to true, so once selected they disappear from the list.
  • Always Available Choice has Skip Already Selected Choices set to false, so it stays available no matter how many times the player picks it.
  • Exit transitions to an end state, closing the conversation.

DataTable¶

FSM_Dialogue_DataTable shows how to load dialogue text from a DataTable instead of writing it directly in each node. It is a simple linear sequence of nodes, but each one references DT_DialogueSample and specifies a row name. The FSMN_DialogueBase class loads the matching row data when the state begins.

Why use a DataTable?

DataTables are useful when you want to manage dialogue content outside the state machine graph (for example, in a spreadsheet that a writer maintains). They also make it easier to swap in different content (different languages, different versions of a conversation) without touching the graph.

This sample also demonstrates two other features:

  • Construction scripts. Nodes can run logic at editor time. The DataTable sample uses this to preview dialogue text in the graph without playing. Make sure your project's "Editor Node Construction Script Setting" is set to "Standard" to use this. Check IsEditorExecution when a construction script should only run in the editor.
  • Localization. Text Graph Properties support localization through string tables and the localization dashboard. Note that text loaded from a DataTable does not support automatic localization gathering, so you will need to handle that through the DataTable's own localization workflow.

Object Parsing¶

FSM_Dialogue_ObjectParsing demonstrates custom text conversion with SMTextGraphProperty. By default, when you drag an object into a text graph property, it uses standard text conversion (typically the object's name). This sample shows how to override that with a custom function.

To set up custom object-to-text conversion:

  1. Open the class defaults of the node class that uses the SMTextGraphProperty.
  2. Under the property's TextSerializer section, set a ToTextFunctionName.
  3. The function you point to must be Blueprint Pure with a Text return type.

This is useful when you want objects to display as something more meaningful than their asset name. For example, you could show a character's display name, an item's description, or a formatted stat block.

Select Color¶

FSM_Dialogue_SelectColor is an interactive example where the player's dialogue choice affects the game world. It demonstrates that dialogue choices are not limited to text. They can trigger any gameplay action.

The conversation starts with a dialogue node asking the player to pick a color. Three choice nodes (Red, Green, and Blue) each transition to a "Color Selected" state. This state uses FSMN_Color, a custom state class specific to this sample, which sets the color of a cube character (BP_LogicDriverDialogueCubeCharacter).

FSMN_Color has one property you configure per node: Color (Linear Color), the color to apply when that state is reached.

The state machine has bStopOnEndState set to true, so the conversation ends as soon as the Color Selected state is reached.

Integrating Into Your Project¶

Here is how to get the dialogue template running in your own game, step by step.

1. Add the components

Attach AC_LogicDriverDialogue to every character that can participate in conversations. Set their Character Name so the UI knows what to display. Attach AC_LogicDriverDialogueManager to your GameMode, which creates the dialogue widget.

2. Create dialogue state machines

Create new state machine Blueprints that inherit from FSM_DialogueBase. Use FSMN_Dialogue for lines of dialogue, FSMN_DialogueChoice for player choices, and FSMN_DialogueTransition for the connections between them.

3. Assign state machines to characters

On each character's AC_LogicDriverDialogue component, set the State Machine Class to your dialogue state machine. Since the component is an SMStateMachineComponent, this works the same way as any other state machine component setup.

4. Set up input

The template includes an IA_Talk input action and IMC_Dialogue input mapping context. Configure these for your project's input setup, or replace them with your own. The dialogue system just needs a way to trigger "talk" and "continue."

5. Customize the UI

Modify WBP_Dialogue and WBP_DialogueOption to match your game's visual style, or replace them entirely. The dialogue manager creates the widget on begin play, so make sure your replacement widget has the same interface.

Entirely Blueprint

This template is built entirely in Blueprints. The node classes extend Logic Driver's base classes (SMStateInstance, SMTransitionInstance) directly without any C++ code. See Designing a Dialogue System for the underlying concepts.