# DlgSystem: an open source dialogue plugin for Unreal Engine

> DlgSystem is a dialogue and branching system for Unreal Engine, free with source included, with Blueprint and C++ support, a graph editor and a dialogue browser. It grew out of the developer's own game and is now sold on the Unreal marketplace to fund the binary builds, which is the commercial wrinkle worth understanding before you adopt it.

**NotYetGames/DlgSystem** — Dialogue Plugin System for Unreal Engine

- Repository: https://github.com/NotYetGames/DlgSystem
- Website: https://bit.ly/DlgMarketplace
- Stars: 646 · Forks: 105
- Language: C++
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/notyetgames-dlgsystem

## A dialogue system that came out of a shipped game

DlgSystem is the Not Yet: Dialogue Plugin System for Unreal Engine, and the README is direct about its origins. The plugin is primarily developed and used for the developer's own game, WarriOrb, a souls-like platformer metroidvania. The stated reason for open sourcing it is that the team put significant effort into it and decided to make it open source to help out other teams facing similar challenges, and that contribution, feedback and constructive criticism are welcome.

That origin story matters for how you read the feature list. Every capability in it came out of a shipping game rather than out of a design document, which is the usual reason a dialogue plugin has the specific shape it has.

The supported Unreal versions are listed plainly: 5.6, 5.7 and 5.8. The plugin is written in C++ with full Blueprint and C++ support, and the licence is MIT with a LICENSE.txt at the repository root. The last push to the repository was on 2026-06-22, the repository is not archived, and the project has no GitHub releases.

The audience is an Unreal team that needs branching dialogue with a visual authoring tool and does not want to build one, and that can accept the support arrangement described later in this article.

The homepage link in the project metadata points at a marketplace listing rather than a documentation site, which is a small hint about how this project is distributed.

## What the plugin gives you at runtime and in the editor

The feature list is split into the core mechanics and the editor tooling, and the editor side is the larger half.

On the runtime side there are events and conditions, branching based on different node types and conditions, and well structured runtime and editor modules. Events and conditions are the vocabulary a dialogue graph needs to react to game state, and the branching support means a conversation can fork on those conditions rather than being a linear script.

The editor side is more substantial. There is a Graph Editor, which is the visual authoring surface. There is a search window, and a Dialogue Browser that gives an overview of all the dialogues in the project. There are customized blueprint nodes, so certain events and conditions can be handled in Blueprint easily rather than requiring a C++ subclass. There is a settings panel in Project Settings to modify the layout. There is an option to import from and export to plain text formats such as JSON. And there is real time display and edit functionality for the dialogue runtime data.

Two of those are worth singling out. The plain text import and export is what makes dialogue reviewable in a diff and scriptable in a pipeline, which is a genuine advantage over a purely in-editor format. The real time display and edit of runtime data is the debugging feature, letting a designer see and change the live dialogue state rather than replaying the conversation from the start.

The documentation lives in a wiki with a manual and tutorials, there is a changelog under Docs, and an example project is published in its own repository. The README also points at a feature gallery page on the wiki.

## Free source, paid binaries: the support arrangement stated plainly

The support section is where this project differs from most free plugins, and the README does not bury it.

The note says the plugin was initially free on the marketplace, but the team later switched to a small fee because maintaining all of the binary versions for different engine targets took a lot of time, and it asks buyers to consider the purchase a donation. The marketplace listing is where you buy the plugin or the team's other plugins, and buying it always gets binary support for the latest three engine versions.

So the arrangement is: the source code is free and MIT licensed, and the compiled binaries that save you a build step are behind a paid listing. Whether that is acceptable depends on your build pipeline. If your team already compiles plugins from source for every target, the free source is genuinely enough. If you want to pull a binary into an existing project, the purchase is what funds the work that makes the binaries exist at all.

This is an unusual and arguably better arrangement than most, because the licence permits you to build and ship the plugin yourself with no obligation, and the money buys maintenance rather than access. It also means the project is not fully self-sustaining from the open source side, and a team that wants to guarantee long-term availability has to accept that continued maintenance depends on marketplace revenue.

The README also asks for word of mouth, and the list of games on the page names titles that use the plugin, including Backbone, Revolution: Path of a Weaponsmith, The Ascent and Echoes of the End, alongside the team's own WarriOrb, and says hundreds of other games decided to remain anonymous.

## Branch layout tied to engine version, and a commit convention you must read

The conventions section of the README is short but it contains the two rules that will affect your day if you ignore them.

The first is branching. The supported Unreal versions have their own branches, and the outdated version branches are kept but not updated anymore. That is a sane policy for a plugin that has to compile against three engine versions at once, and it also means the branch you want is chosen by your engine version, not by a feature flag.

The second is the commit message convention, and it is unusually well specified. Every commit message that has [C] means that after updating to that commit a recompile is required, with the example given as [C] Added awesome Dialogue feature. Every commit message that has [G] means the solution files should be regenerated and recompiled, and the README is blunt about the recompile being obvious. The action is to right click on the project file and choose Generate Visual Studio project files, or to regenerate from the command line, with the example [G] New Dialogue Editor mode.

For a team pulling this in as a dependency, the [G] marker is the important one. A commit that changes the module layout invalidates your generated project files, and if your build regenerates them it does not matter, and if it does not, your build breaks on a commit that looks like a feature change.

Code style follows the UE Coding Standard, with the additional changes located in the .editorconfig file at the repository root. The repository also carries a .gitattributes file, a .gitconfig file, a DlgSystem.uplugin descriptor, Config, Content, Docs, Resources, Source and Tools directories, so the plugin ships its own content and resources rather than being code only.

## Where DlgSystem is the wrong tool

The first wrong-tool case is a project on an Unreal version outside the supported three. The plugin compiles against specific engine versions, and the branch structure means an older engine is served by a frozen branch. A studio standardised on a version outside 5.6 to 5.8 is looking at a fork or an upgrade, and neither is free.

The second is a team that wants a fully self-supported open source dependency. The source is MIT and the binaries are behind a purchase, and the README states plainly that the fee exists because maintaining the binary versions for different engine targets took a lot of time. A team whose policy is that critical tooling must have a maintained upstream with no commercial dependency has to weigh that.

The third is a project that needs a dialogue feature set this plugin does not have. The list covers events, conditions, branching, a graph editor, a browser, blueprint nodes, JSON import and export and runtime inspection, and that is a coherent set. What it does not describe is localisation workflow, voice handling, subtitles, or a quest system, and there is no indication in the README that those are in scope. A project that treats dialogue as one part of a larger narrative pipeline will need to check the edges carefully.

The fourth is a team that does not want a plugin with its own editor mode. The plugin adds a Dialogue Editor mode to the engine, custom blueprint nodes and a settings panel, and the [G] convention exists because those additions change the project structure. For a team with a strict policy on engine extensions, that is a cost to evaluate rather than a given.

The alternative to weigh is building dialogue in-house or using a different tool. The difference in approach is that DlgSystem arrives with an editor and a runtime that a studio has to live with, whereas in-house work gives you exactly the graph semantics your game needs and nothing else, at the cost of a year of engine integration and ongoing maintenance of the editor. The wiki documentation and the example project lower the second cost considerably, and the MIT licence means the in-house path can start from this code and diverge.

## Conclusion

DlgSystem fits an Unreal team that needs a branching dialogue system with a visual editor and Blueprint access, and that is comfortable with a plugin whose support is funded by marketplace purchases. It is the wrong choice for a team wanting a fully self-supported open source dependency, since the binary builds come from a paid listing even though the source is free, and it is the wrong choice on an Unreal version outside 5.6 to 5.8. Before adopting it, check which branch matches your engine version, read the branch convention where the supported versions have their own branches and outdated ones are frozen, and confirm that the graph editor and blueprint node set cover the dialogue patterns your game actually uses.

## FAQ

### Which Unreal Engine versions does DlgSystem support?

The README lists Unreal versions 5.6, 5.7 and 5.8, with the supported versions having their own branches and outdated version branches kept but no longer updated.

### Is DlgSystem free?

The source code is free and MIT licensed, and the README says the plugin was initially free on the marketplace before a small fee was introduced, because maintaining binary versions for different engine targets took a lot of time.

### What does the [C] and [G] commit message convention mean in DlgSystem?

A commit marked [C] requires a recompile after updating, and a commit marked [G] requires the solution files to be regenerated and recompiled, by right clicking the project file and choosing Generate Visual Studio project files.

### What editor tools does DlgSystem provide for authoring dialogue?

A Graph Editor, a search window, a Dialogue Browser for an overview of all dialogues, customized blueprint nodes for events and conditions, a Project Settings panel for the layout, plain text import and export such as JSON, and real time display and edit of the dialogue runtime data.

## Sources

- [Issues](https://github.com/NotYetGames/DlgSystem/issues)
- [License: MIT](https://github.com/NotYetGames/DlgSystem/blob/master/LICENSE)
- [NotYetGames/DlgSystem on GitHub](https://github.com/NotYetGames/DlgSystem)
- [Project website](https://bit.ly/DlgMarketplace)
- [README](https://github.com/NotYetGames/DlgSystem/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/notyetgames-dlgsystem