Keeping narrative runtime and editor tools in separate modules
A concrete look at NarrativeFact and NarrativeFactEditor: where story state lives, where authoring tools live, and how the dependencies are arranged.
NarrativeFramework contains both gameplay systems and the tools used to configure them. In the fact system, I keep those responsibilities in two modules: NarrativeFact and NarrativeFactEditor.
What belongs to the runtime
NarrativeFact owns the fact store, condition types, settings, and presets. Its build dependencies include Core, CoreUObject, Engine, GameplayTags, and DeveloperSettings.
These are the pieces the game needs when it evaluates or changes narrative state. They do not need an editor window or an asset-authoring panel to perform that work.
What belongs to the editor
NarrativeFactEditor depends on the runtime module. It also brings in editor dependencies such as AssetTools, Slate, SlateCore, UnrealEd, and WorkspaceMenuStructure, plus my shared NarrativeEditorFramework.
The plugin descriptor declares NarrativeFact as a Runtime module and NarrativeFactEditor as an Editor module. The separation is therefore expressed in both the source structure and the module definitions.
A dependency direction you can read
The editor layer knows about the runtime types it helps configure. The runtime module’s build definition does not depend on NarrativeFactEditor or UnrealEd.
That is a concrete boundary, not just a naming convention. When an editor feature needs access to a gameplay type, the dependency points toward the runtime. The reverse dependency is absent from this pair.
Flow as the integration layer
Fact-related Flow nodes live in NarrativeFlow. The fact store itself has no Flow dependency in its build definition.
This lets me discuss two separate responsibilities: the fact system represents and queries state; the Flow nodes connect that state to an authored sequence. The waiting node described in my previous note is one example.
What this note does—and does not—demonstrate
The module definitions show how I organize the current implementation. They are not a claim that every framework module is finished, nor a benchmark or a packaged-build certification.
For a project I’m still developing, this kind of small, inspectable boundary is useful portfolio evidence: it shows where responsibilities live and how I’m structuring the code behind Coldwater Hollow.
Coldwater Hollow brings the runtime and authoring work together.