How the Modules Work Together
How the Modules Work Together
DSL Forge has a layered, modular architecture. Here’s the full pipeline from text input to real in-game execution.
Text → Tokenizer → Tokens
First, designers or level authors write plain-text scripts.
The Tokenizer reads this text and breaks it into structured tokens:
Identifies command names and arguments
Handles parentheses and nested levels
Preserves argument order
The output is a "flattened" but structured sequence of Tokens, ready for parsing.
Tokens → Parser → AST
Next, the Parser consumes the Tokens and builds an Abstract Syntax Tree (AST).
In the AST, each command is a node with its arguments as child nodes.
Key features:
Clearly expresses parent–child call relationships
Supports deep nesting
Easy to visualize and edit in the editor
The AST is DSL Forge’s core intermediate representation.
AST → Flow
AST is an editor-friendly format, ideal for saving, version control, and visual editing.
When it’s time to run in-game, the AST is "compiled" into a Flow:
Flow is the executable format
Strips away extra metadata
Retains command sequences and parameters
Can be serialized as assets or distributed over the network
Supports runtime loading, hot updates, DLC
Flow is the format the Interpreter can directly execute.
Flow → Interpreter
At runtime, the Interpreter reads and executes the Flow step by step asynchronously.
Interpreter features:
Supports sequential execution and branching
Manages local and global variables
Handles flow jumps and sub-flow calls
Supports async waits and cross-frame execution
This is the key step that turns data-defined flows into real in-game behavior.
Command System
During execution, each command call is dispatched to the Command System.
Command System features:
Rich built-in modules (control flow, math, collections, events, statistics)
Plugin architecture for custom command libraries
Central registration mechanism for all commands
It’s the "brain and hands" of DSL Forge, actually performing command functionality.
Last updated