Z revidoval tento gist . Přejít na revizi
1 file changed, 2 insertions, 2 deletions
Gemma4-UIUX.md
| @@ -42,11 +42,11 @@ Non-technical designers shouldn't have to worry about "Sagas" or "Distributed Lo | |||
| 42 | 42 | ### 3. The "Compiler" Pipeline | |
| 43 | 43 | The relationship between the Designer and the DSL is a **Compilation Pipeline**: | |
| 44 | 44 | ||
| 45 | - | 1. **Visual Layer (UI):** Designer draws a graph $\rightarrow$ **JSON representation**. | |
| 45 | + | 1. **Visual Layer (UI):** Designer draws a graph > **JSON representation**. | |
| 46 | 46 | 2. **Translation Layer (Compiler):** The JSON is converted into the **Universal DSL** text. | |
| 47 | 47 | 3. **Execution Layer (Engine):** The DSL is parsed by the orchestrator and executed as a state machine. | |
| 48 | 48 | ||
| 49 | - | **Why do it this way? Why not just go from Visual $\rightarrow$ Execution?** | |
| 49 | + | **Why do it this way? Why not just go from Visual > Execution?** | |
| 50 | 50 | * **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. | |
| 51 | 51 | * **Auditability:** A lead designer can review the DSL text to ensure no "infinite loops" or "broken joins" were created visually. | |
| 52 | 52 | * **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. | |
Z revidoval tento gist . Přejít na revizi
1 file changed, 2 insertions, 2 deletions
Gemma4-UIUX.md
| @@ -51,9 +51,9 @@ The relationship between the Designer and the DSL is a **Compilation Pipeline**: | |||
| 51 | 51 | * **Auditability:** A lead designer can review the DSL text to ensure no "infinite loops" or "broken joins" were created visually. | |
| 52 | 52 | * **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. | |
| 53 | 53 | ||
| 54 | - | ### Example: Visual $\rightarrow$ DSL | |
| 54 | + | ### Example: Visual > DSL | |
| 55 | 55 | **Designer Action:** | |
| 56 | - | * Drags an **AI Node** $\rightarrow$ Drags a **Splitter** $\rightarrow$ Drags two **Tasks** $\rightarrow$ Drags a **Merge Node**. | |
| 56 | + | * Drags an **AI Node** > Drags a **Splitter** > Drags two **Tasks** > Drags a **Merge Node**. | |
| 57 | 57 | ||
| 58 | 58 | **The Generated DSL:** | |
| 59 | 59 | ```python | |
Z revidoval tento gist . Přejít na revizi
1 file changed, 1 insertion, 1 deletion
Gemma4-UIUX.md
| @@ -2,7 +2,7 @@ Because the DSL is structured as a **Directed Graph** (nodes and edges), it is p | |||
| 2 | 2 | ||
| 3 | 3 | 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). | |
| 4 | 4 | ||
| 5 | - | Here is how the translation from **Code $\rightarrow$ Visual** and **Designer $\rightarrow$ DSL** would work. | |
| 5 | + | Here is how the translation from **Code > Visual** and **Designer > DSL** would work. | |
| 6 | 6 | ||
| 7 | 7 | --- | |
| 8 | 8 | ||
Z revidoval tento gist . Přejít na revizi
1 file changed, 67 insertions
Gemma4-UIUX.md(vytvořil soubor)
| @@ -0,0 +1,67 @@ | |||
| 1 | + | Because the DSL is structured as a **Directed Graph** (nodes and edges), it is perfectly suited for **Visual Authoring**. | |
| 2 | + | ||
| 3 | + | 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). | |
| 4 | + | ||
| 5 | + | Here is how the translation from **Code $\rightarrow$ Visual** and **Designer $\rightarrow$ DSL** would work. | |
| 6 | + | ||
| 7 | + | --- | |
| 8 | + | ||
| 9 | + | ### 1. The Visual Mapping (The "Quest Graph") | |
| 10 | + | The DSL concepts map directly to visual elements in a GUI: | |
| 11 | + | ||
| 12 | + | | DSL Syntax | Visual Element | Designer's Perspective | | |
| 13 | + | | :--- | :--- | :--- | | |
| 14 | + | | `Module { ... }` | **Container / Group** | A labeled box grouping a specific part of the quest. | | |
| 15 | + | | `Node A -> Node B` | **Arrow (Edge)** | The flow of the story. | | |
| 16 | + | | `F->` (Fork) | **Split Arrow** | "The player can do these things in any order." | | |
| 17 | + | | `J->` (Join) | **Merge Point** | "Once all these are done, move to the next step." | | |
| 18 | + | | `AI.Generate` | **AI Node** | A text box where the designer writes a prompt. | | |
| 19 | + | | `? [ branch ]` | **Decision Diamond** | A choice point (e.g., "Is the player honorable?"). | | |
| 20 | + | | `Lock / Undo` | **Safety Wrapper** | A "critical zone" that ensures the quest doesn't glitch. | | |
| 21 | + | ||
| 22 | + | --- | |
| 23 | + | ||
| 24 | + | ### 2. How a Game Designer Interacts with it | |
| 25 | + | A designer would use a **"Quest Orchestrator"** tool. Their workflow would look like this: | |
| 26 | + | ||
| 27 | + | #### A. Drag-and-Drop Composition | |
| 28 | + | 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. | |
| 29 | + | ||
| 30 | + | #### B. Natural Language Prompting | |
| 31 | + | For the AI nodes, the designer doesn't deal with model parameters. They see a field called **"NPC Personality/Goal"** and write: | |
| 32 | + | > *"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."* | |
| 33 | + | The tool wraps this into the `AI.Generate` block with the correct system prompts. | |
| 34 | + | ||
| 35 | + | #### C. The "Safety" Layer (Abstraction) | |
| 36 | + | Non-technical designers shouldn't have to worry about "Sagas" or "Distributed Locks." The tool abstracts these as **High-Level Templates**: | |
| 37 | + | * **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. | |
| 38 | + | * **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. | |
| 39 | + | ||
| 40 | + | --- | |
| 41 | + | ||
| 42 | + | ### 3. The "Compiler" Pipeline | |
| 43 | + | The relationship between the Designer and the DSL is a **Compilation Pipeline**: | |
| 44 | + | ||
| 45 | + | 1. **Visual Layer (UI):** Designer draws a graph $\rightarrow$ **JSON representation**. | |
| 46 | + | 2. **Translation Layer (Compiler):** The JSON is converted into the **Universal DSL** text. | |
| 47 | + | 3. **Execution Layer (Engine):** The DSL is parsed by the orchestrator and executed as a state machine. | |
| 48 | + | ||
| 49 | + | **Why do it this way? Why not just go from Visual $\rightarrow$ Execution?** | |
| 50 | + | * **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. | |
| 51 | + | * **Auditability:** A lead designer can review the DSL text to ensure no "infinite loops" or "broken joins" were created visually. | |
| 52 | + | * **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. | |
| 53 | + | ||
| 54 | + | ### Example: Visual $\rightarrow$ DSL | |
| 55 | + | **Designer Action:** | |
| 56 | + | * Drags an **AI Node** $\rightarrow$ Drags a **Splitter** $\rightarrow$ Drags two **Tasks** $\rightarrow$ Drags a **Merge Node**. | |
| 57 | + | ||
| 58 | + | **The Generated DSL:** | |
| 59 | + | ```python | |
| 60 | + | Module DynamicQuest { | |
| 61 | + | AI.Generate { ... } -> Quest.Split | |
| 62 | + | Quest.Split F-> [Task.One, Task.Two] | |
| 63 | + | [Task.One, Task.Two] J-> Quest.Finish | |
| 64 | + | } | |
| 65 | + | ``` | |
| 66 | + | ||
| 67 | + | 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. | |
Novější
Starší