Because the DSL is structured as a Directed Graph (nodes and edges), it is perfectly suited for Visual Authoring.
While the text version is what a developer uses to debug or version-control the logic, a non-technical game designer would never be expected to write code like J-> or Saga.Compensate. Instead, they would use a Visual Node-Based Editor (similar to Unreal Engine's Blueprints or Unity's Visual Scripting).
Here is how the translation from Code > Visual and Designer > DSL would work.
1. The Visual Mapping (The "Quest Graph")
The DSL concepts map directly to visual elements in a GUI:
| DSL Syntax | Visual Element | Designer's Perspective |
|---|---|---|
Module { ... } |
Container / Group | A labeled box grouping a specific part of the quest. |
Node A -> Node B |
Arrow (Edge) | The flow of the story. |
F-> (Fork) |
Split Arrow | "The player can do these things in any order." |
J-> (Join) |
Merge Point | "Once all these are done, move to the next step." |
AI.Generate |
AI Node | A text box where the designer writes a prompt. |
? [ branch ] |
Decision Diamond | A choice point (e.g., "Is the player honorable?"). |
Lock / Undo |
Safety Wrapper | A "critical zone" that ensures the quest doesn't glitch. |
2. How a Game Designer Interacts with it
A designer would use a "Quest Orchestrator" tool. Their workflow would look like this:
A. Drag-and-Drop Composition
Instead of writing code, the designer drags a "Fetch Item" node and a "Slay Monster" node onto a canvas. They connect these to a "Merge" node. The tool automatically generates the F-> and J-> logic in the background.
B. Natural Language Prompting
For the AI nodes, the designer doesn't deal with model parameters. They see a field called "NPC Personality/Goal" and write:
"The Elder is grumpy and wants the player to clean the forest, but he should be subtly hinting that he actually misses his lost locket." The tool wraps this into the
AI.Generateblock with the correct system prompts.
C. The "Safety" Layer (Abstraction)
Non-technical designers shouldn't have to worry about "Sagas" or "Distributed Locks." The tool abstracts these as High-Level Templates:
- The "Secure Transaction" Template: When a designer drops a "Reward" node, the tool automatically wraps it in a
Lock()and adds aSaga.Compensatepath by default. - The "Failure Path" Template: The designer simply draws a line from a node to a "Failure" state, and the tool implements the
ON (Player.Death)orTimeoutlogic.
3. The "Compiler" Pipeline
The relationship between the Designer and the DSL is a Compilation Pipeline:
- Visual Layer (UI): Designer draws a graph > JSON representation.
- Translation Layer (Compiler): The JSON is converted into the Universal DSL text.
- Execution Layer (Engine): The DSL is parsed by the orchestrator and executed as a state machine.
Why do it this way? Why not just go from Visual > Execution?
- Version Control: Git cannot "diff" a visual graph easily, but it can diff the DSL text. Developers can see exactly what changed in a quest.
- Auditability: A lead designer can review the DSL text to ensure no "infinite loops" or "broken joins" were created visually.
- Hot-Reloading: A developer can tweak a prompt in the DSL text and push it to the live game without the designer having to reopen the visual editor.
Example: Visual > DSL
Designer Action:
- Drags an AI Node > Drags a Splitter > Drags two Tasks > Drags a Merge Node.
The Generated DSL:
Module DynamicQuest {
AI.Generate { ... } -> Quest.Split
Quest.Split F-> [Task.One, Task.Two]
[Task.One, Task.Two] J-> Quest.Finish
}
This separation of concerns allows the Creative (Designer) to focus on the experience and the Engineer to focus on the stability and scaling of the underlying DSL.