SUDS (Steve’s Unreal Dialogue System) is a free, open-source dialogue plugin for Unreal Engine by Steve Streeting — the same person behind SUQS, the quest system I use alongside it. The idea is simple: you write dialogue in plain text .sud files, drop them into your Content folder, and Unreal imports them as assets you can run at runtime.
Again — huge thanks to Steve and the UE community for sharing tools like this. Building a dialogue system from scratch is a deep rabbit hole (parsing, branching, state, localization, voice), and having a solid open-source solution means I can focus on writing actual dialogue instead of building infrastructure.
Why Text-Based Dialogue
Most dialogue systems in Unreal use node graphs — visual scripting where you connect dialogue nodes with wires. It works, but for a solo developer it’s slow. Every line of dialogue requires clicking through menus, placing nodes, dragging connections. And version control is painful — binary assets don’t diff well in git.
SUDS takes the opposite approach. Dialogue lives in .sud text files. You write them in any editor (there’s a VSCode extension with syntax highlighting). They diff cleanly in git. You can write dialogue as fast as you can type.
Script Format
A .sud file is line-based. Each line does one thing. Here’s what a simple conversation looks like:
NPC: Welcome to the station. Haven't seen you around before.
* I just arrived.
NPC: Fresh off the shuttle? Watch your step around here.
* I've been here longer than you think.
NPC: Sure you have. Everyone says that.
NPC: Either way, stay out of the restricted areas.
Speaker lines (prefixed with the character name) pause execution and display text. Choice lines (prefixed with *) create player options. Everything indented under a choice only runs if the player picks that option.
It gets more powerful from there:
- Variables —
{PlayerName},{global.NumKeys}substitute values into text - Conditionals —
[if HasKeycard]/[else]/[endif]branch based on state - Events —
[event DoorOpened]fires delegates that C++ or Blueprints can listen to - Goto/labels —
[goto end]or[goto :checkpoint]for flow control - Two variable scopes — dialogue-local and global, persisted across conversations
How It Runs
At runtime, you create a dialogue instance from a script asset. The dialogue starts executing lines from the top and pauses whenever it hits a speaker line — that’s when your UI displays the text and waits for the player to continue or pick a choice.
Dialogue participants are objects (usually characters) that provide variables and receive events. When an NPC says {PlayerName}, the system asks the participant for that variable’s value. When a [event DoorOpened] line fires, participants that subscribe to it get the callback.
The plugin handles the state machine — tracking which line you’re on, which choices are available, which variables are set. Your game code just needs to create the dialogue, display text when it pauses, and forward player choices back.
Integration in The Break of Day
I use SUDS together with SUQS (the quest system). The bridge between them is a data asset — UASQuestsToDialogueDataAsset — that maps (QuestId, TaskId) pairs to SUDS scripts. When a quest task triggers, the game looks up whether there’s dialogue associated with it:
USUDSScript* Script = QuestDialogueAsset->GetDialogueScript(QuestId, TaskId);This keeps quests and dialogue loosely coupled. The quest system doesn’t know about dialogue, and dialogue scripts don’t know about quests. The data asset is just a lookup table connecting them — easy to edit, validates in the editor, and catches duplicate entries before they become runtime bugs.
The dialogue scripts themselves live as .sud files in the project — plain text, version controlled, diffable. When I need to change what an NPC says after completing a task, I edit a text file instead of navigating a node graph.
SUDS vs Node-Based Systems
The main alternative in UE5 is visual dialogue — node-based editors like Dialogue System for UE or custom Blueprint graphs. Both approaches work, but they optimize for different things:
- Node graphs are great when designers need visual overview of complex branching trees, and when you have a team where not everyone is comfortable with text files
- Text scripts are great for solo developers or small teams who want fast iteration, clean version control, and the ability to write dialogue at the speed of typing
For me, working alone, SUDS is the clear winner. I can write and iterate on dialogue faster in a text file than I ever could clicking through nodes. And when I need to review changes, git diff shows me exactly what changed in plain English.