Favorisieren 0
Fork 0

Zuletzt aktiv 1781220123

Änderung cfce9b3a68275770638aaac95b9c0854a4b2677c

Gemma4-DSL-Spec.md Orginalformat

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.Generate block 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 a Saga.Compensate path 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) or Timeout logic.

3. The "Compiler" Pipeline

The relationship between the Designer and the DSL is a Compilation Pipeline:

  1. Visual Layer (UI): Designer draws a graph > JSON representation.
  2. Translation Layer (Compiler): The JSON is converted into the Universal DSL text.
  3. 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.

Gemma4-DSL-Spec2.md Orginalformat

This is the complete specification for the Universal Orchestration DSL (v1.0). This language is designed to be compiled into an execution plan that can be routed between a Fast-Path Engine (Eventual Consistency/Combat) and a Safe-Path Engine (Strong Consistency/Trade).

1. Core Flow & Orchestration

These operators define the movement of the workflow through the state machine.

Operator Keyword / Syntax Description Example Consistency
Sequence -> Linear transition from one node to the next. NodeA -> NodeB Variable
Fork F-> [A, B, C] Splits the flow into parallel paths; all paths start simultaneously. Start F-> [Task1, Task2] Eventual
Join [A, B, C] J-> Synchronization barrier; waits for all listed paths to complete before proceeding. [T1, T2] J-> Complete Eventual
Branch ? [ condition -> X ] Conditional logic based on the output of the previous node. ? [ available -> Create ] Variable
Loop Loop { condition } Repeats a block of logic until a specific condition is met. Loop AI.Refine { valid } Variable
Timeout T [duration] Sets a maximum wait time before triggering a failure path. T [5m] -> TimeoutHandler Variable
Module Module Name { ... } A logical grouping of nodes that can be called as a single unit. Module ProfileSetup { ... } Variable

2. AI & Agentic Logic

Operators specifically designed for non-deterministic LLM interactions and verification.

Operator Keyword / Syntax Description Example Consistency
Generation AI.Generate [model] Calls an LLM to produce a result based on a prompt and context. AI.Generate {prompt: "..."} Eventual
Evaluation AI.Evaluate Uses an AI to judge if a previous output meets specific criteria. AI.Evaluate {criteria: "..."} Eventual
Analysis AI.Analyze Performs pattern recognition or anomaly detection across a dataset. AI.Analyze {metric: "SD"} Eventual
Human-In-Loop Approval.Wait Pauses the workflow until a human provides a digital signature/approval. Approval.Wait /require /sig Strong
Refinement AI.Refine An iterative loop to improve AI output based on feedback. Loop AI.Refine { valid } Eventual

3. Infrastructure & Reliability

The "Safe Path" operators used to ensure data integrity and system stability.

Operator Keyword / Syntax Description Example Consistency
Distributed Lock Lock (resource) { ... } Ensures exclusive access to a resource; prevents race conditions. Lock ($user_id) { ... } Strong
Atomic Saga Saga.Atomic { ... } A transaction that must either complete entirely or not at all. Saga.Atomic { Add, Sub } Strong
Compensation Saga.Compensate { ... } An "Undo" path triggered when a distributed transaction fails. Saga.Compensate { Refund } Strong
Circuit Breaker circuit_break [args] Stops calling a failing external service to prevent system collapse. EXT:API /circuit_break Variable
Bulk Sink Bulk.Save /insert Groups thousands of updates into a single database transaction. Bulk.Save { data: list } Strong

4. Real-Time & Game Logic

Operators designed for high-frequency updates and reactive event-driven environments.

Operator Keyword / Syntax Description Example Consistency
Event Listener ON (Event) -> X Triggers a workflow when a specific system event occurs. ON (Player.Death) -> X Eventual
Heartbeat Tick [interval] Executes a block of logic at a fixed time frequency. Tick [100ms] { ... } Eventual
State Snapshot State.Snapshot Serializes current global state for save/load or recovery. State.Snapshot /save Strong
Delta Update Value -= Delta Updates a value by a relative amount rather than an absolute. Boss.HP -= {damage} Eventual
Resource Lock SortedIds(A, B) A helper to lock multiple resources in order to prevent deadlocks. Lock (SortedIds(A, B)) Strong

5. Web & External Integration

Operators for connecting the workflow to the outside world and third-party services.

Operator Keyword / Syntax Description Example Consistency
External Call EXT:Service.Method Executes a call to an external API or microservice. EXT:AuthService.Create Variable
Webhook Webhook.Emit /post Sends data to an external URL and optionally waits for a response. Webhook.Emit /post {url} Eventual
Middleware Module.Middleware Logic that intercepts every call into a module (Auth, Logging). Module.Middleware { Auth } Variable
Wait Condition WAIT (Event) Pauses execution until a specific external signal is received. WAIT (Payment_Success) Variable

6. Global State & Variables

Definition of how data is stored and modified across the workflow.

Element Syntax Description Example Scope
Global Variable $var_name = value A state variable shared across all nodes in the workflow. $user_id = null Global
Local Variable {var_name} A temporary variable passed between nodes as a payload. {email} Node-local
Resource Map Resource > Level Mapping of a game object to its required consistency level. Wallet > Strong System
Identity Crypto.Sign(key) Attaches a cryptographic signature to a request for validation. sig: Crypto.Sign($key) Security

Powered by Opengist ⋅ Load: 56ms⋅

Deutsch