das ist erst relevant wenn behavior als node funktionieren
hier ein paar fragen vorweg:
habe ich gesehen dass es die variablen grid, shapes, colors und spawnX gibt. diese sind sehr kryptisch. welche nodes fehlen, bzw. wie kann man das schöner gestalten.
man könnte jetzt das ganze auch in mehrere behavior strukturell aufsplitten und diese in das Tetris-Behavior als Node einbetten
Beantwortet und umgesetzt
Beide Punkte hatten dieselbe Ursache, und die lag nicht im Tetris-Projekt: der Engine fehlte
ein Datentyp. Eine Variable konnte nur Zahl, Text oder Ja/Nein sein (PropertyValue), also
musste jede Menge von Werten in einen String kodiert werden. Genau daher kamen deine vier
kryptischen Variablen — nicht aus einer schlechten Wahl beim Bauen.
1. Die kryptischen Variablen: es fehlte die Liste
list ist jetzt eine Variablen- und eine Port-Art. Sie hält Zahlen, Texte, Ja/Neins oder Farben und wird im Inspector als eine kommagetrennte Zeile getippt.
Variable
vorher
jetzt
grid
200-Zeichen-Text, . = leer
Liste aus 200 Zahlen, -1 = leer
shapes
224 Ziffern am Stück
Liste aus 224 Zahlen
colors
"03066326048763714..." – Farben als 8-stellig gepaddete Dezimalzahlen
Farbliste: #2ec9d6, #f5c542, …
spawnX
"3433333"
3, 4, 3, 3, 3, 3, 3
Dazu acht neue Nodes, alle allgemein statt Tetris-eigen: List (Konstante), Fill
(ein Wert wiederholt – so entsteht ein leeres Brett), Count, Item at, Set item, Sub list, Join lists, Index of.
Was das im Graphen ausmacht: eine Zelle lesen war Substring(grid, i, 1) + Equals '.', jetzt Item at(grid, i) >= 0. Eine Landung schreiben war sieben Nodes (zweimal Substring,
zweimal Join, To text, Add), jetzt einer: Set item.
Bewusst nicht gebaut: eine Liste von Objekten. Eine Liste wird in die Projektdatei
geschrieben, ein Objekt ist ein Handle, das keinen Reload überlebt — eine Objektliste wäre die
erste Wertsorte, die beim nächsten Laden still verschwindet. Objekte gehen weiter über Namen
(Repeat + Item at + Object by name), und eine spätere Item-Art reference (stabile Id)
wäre reines Hinzufügen, kein Bruch.
2. Aufgesplittet: aus einem Graphen sind zehn geworden
Erst waren es fünf; auf deinen Einwurf hin habe ich auch die einzelnen Schritte eines Frames
zu Behaviors gemacht, die das Master-Behavior nur noch setzt.
Behavior
Aufgabe
Nodes
Spawn piece
welcher Stein als nächstes kommt und in welcher Spalte
5
Next move
welchen einen Zug dieser Frame versucht
44
Fits
passen die vier Zellen dorthin?
18
Draw piece
den fallenden Stein an seinen Platz stellen
14
Lock piece
die gelandeten vier Zellen ins Brett schreiben
20
Clear lines
volle Reihen entfernen und zählen
29
Show lines
den Zähler auf den Schirm schreiben
5
Draw board
das Brett zeichnen
11
Piece cell
wo eine der vier Zellen eines Steins sitzt
12
Tetris
nur noch: in welcher Reihenfolge, und wohin die Antwort
84 (vorher 219)
Piece cell war der erste Gewinn: dieselben zwanzig Nodes standen zweimal im Graphen. Jetzt
einmal — und drei der anderen rufen es auf, Sub-Behaviors im Sub-Behavior.
Keins der neun hält Zustand, genau dein „kann man über input/output lösen". Next move ist
das Beispiel dafür: es bewegt nichts, es schlägt einen Zug vor und gibt ihn zurück
(nx, ny, nrot, kind, fall, wantDx, wantRot). Ein eingelöster Tastenwunsch kommt als 0
zurück — so wird ein Tastendruck genau einmal ausgegeben, ohne dass das Sub-Behavior die
Variablen des Aufrufers kennt.
Woran man misst, dass der Master wirklich nur noch dirigiert: in seinen 84 Nodes steckt keine Schleife und kein Listenzugriff mehr — kein Repeat, Item at, Set item, Get position, Set position, Set text. Das prüft der Smoke-Lauf, damit die Arbeit nicht
unbemerkt zurückwandert:
PASS the master calls every step as a node, and does none of their work itself
calls: spawn-piece, next-move, fits, draw-piece, lock-piece, clear-lines, show-lines, draw-board
work: []
Draw piece, Draw board und Show lines haben keinen End-Node: sie beantworten nichts,
sie zeichnen nur.
Ein Fehlschlag unterwegs
Der Game-Over-Check fiel um — und die Messung nannte den Grund selbst: lines: 20. Meine
Vorlage für „Brunnen voll" bestand aus 19 vollen Reihen, die Clear lines wegräumte, bevor
der neue Stein überhaupt anstand. Der Check maß also das Aufräumen statt das Spielende. Jetzt
lässt jede Reihe ihre letzte Spalte frei: blockiert, aber nirgends vollständig.
Und beim Gegenprüfen fiel auf, dass mein erster Persistenz-Test nichts bewies — er lief über den
schema-geführten Weg, während der Filter, den ich repariert hatte, für Container-Instanzen gilt.
Beide Wege sind jetzt einzeln abgedeckt.
Übernommen aus todo-notes/done/tetris-und-data-logik.md beim Umzug auf das Issue-System (2026-09-12).
Angelegt: 2026-09-09 · 1d8e6eb — Note down two follow-up wishes
Abgeschlossen: 2026-09-09 · 558365d — Rebuild Tetris as ten behaviors that pass values around
Gemeldet von: admin
## Tetris Game verbessern
das ist erst relevant wenn behavior als node funktionieren
hier ein paar fragen vorweg:
- habe ich gesehen dass es die variablen `grid`, `shapes`, `colors` und `spawnX` gibt. diese sind sehr kryptisch. welche nodes fehlen, bzw. wie kann man das schöner gestalten.
- man könnte jetzt das ganze auch in mehrere behavior strukturell aufsplitten und diese in das `Tetris`-Behavior als Node einbetten
---
## Beantwortet und umgesetzt
Beide Punkte hatten dieselbe Ursache, und die lag nicht im Tetris-Projekt: **der Engine fehlte
ein Datentyp.** Eine Variable konnte nur Zahl, Text oder Ja/Nein sein (`PropertyValue`), also
musste jede Menge von Werten in einen String kodiert werden. Genau daher kamen deine vier
kryptischen Variablen — nicht aus einer schlechten Wahl beim Bauen.
### 1. Die kryptischen Variablen: es fehlte die Liste
`list` ist jetzt eine Variablen- und eine Port-Art. Sie hält Zahlen, Texte, Ja/Neins oder
**Farben** und wird im Inspector als eine kommagetrennte Zeile getippt.
| Variable | vorher | jetzt |
|---|---|---|
| `grid` | 200-Zeichen-Text, `.` = leer | Liste aus 200 Zahlen, `-1` = leer |
| `shapes` | 224 Ziffern am Stück | Liste aus 224 Zahlen |
| `colors` | `"03066326048763714..."` – Farben als 8-stellig gepaddete Dezimalzahlen | Farbliste: `#2ec9d6, #f5c542, …` |
| `spawnX` | `"3433333"` | `3, 4, 3, 3, 3, 3, 3` |
Dazu acht neue Nodes, alle allgemein statt Tetris-eigen: **`List`** (Konstante), **`Fill`**
(ein Wert wiederholt – so entsteht ein leeres Brett), **`Count`**, **`Item at`**, **`Set item`**,
**`Sub list`**, **`Join lists`**, **`Index of`**.
Was das im Graphen ausmacht: eine Zelle lesen war `Substring(grid, i, 1)` + `Equals '.'`, jetzt
`Item at(grid, i) >= 0`. Eine Landung schreiben war **sieben** Nodes (zweimal `Substring`,
zweimal `Join`, `To text`, `Add`), jetzt **einer**: `Set item`.
**Bewusst nicht gebaut:** eine Liste *von Objekten*. Eine Liste wird in die Projektdatei
geschrieben, ein Objekt ist ein Handle, das keinen Reload überlebt — eine Objektliste wäre die
erste Wertsorte, die beim nächsten Laden still verschwindet. Objekte gehen weiter über Namen
(`Repeat` + `Item at` + `Object by name`), und eine spätere Item-Art `reference` (stabile Id)
wäre reines Hinzufügen, kein Bruch.
### 2. Aufgesplittet: aus einem Graphen sind zehn geworden
Erst waren es fünf; auf deinen Einwurf hin habe ich auch die einzelnen **Schritte** eines Frames
zu Behaviors gemacht, die das Master-Behavior nur noch setzt.
| Behavior | Aufgabe | Nodes |
|---|---|---|
| `Spawn piece` | welcher Stein als nächstes kommt und in welcher Spalte | 5 |
| `Next move` | welchen **einen** Zug dieser Frame versucht | 44 |
| `Fits` | passen die vier Zellen dorthin? | 18 |
| `Draw piece` | den fallenden Stein an seinen Platz stellen | 14 |
| `Lock piece` | die gelandeten vier Zellen ins Brett schreiben | 20 |
| `Clear lines` | volle Reihen entfernen und zählen | 29 |
| `Show lines` | den Zähler auf den Schirm schreiben | 5 |
| `Draw board` | das Brett zeichnen | 11 |
| `Piece cell` | wo eine der vier Zellen eines Steins sitzt | 12 |
| **`Tetris`** | **nur noch: in welcher Reihenfolge, und wohin die Antwort** | **84** (vorher 219) |
`Piece cell` war der erste Gewinn: dieselben zwanzig Nodes standen **zweimal** im Graphen. Jetzt
einmal — und drei der anderen rufen es auf, Sub-Behaviors im Sub-Behavior.
**Keins der neun hält Zustand**, genau dein „kann man über input/output lösen". `Next move` ist
das Beispiel dafür: es *bewegt* nichts, es schlägt einen Zug vor und gibt ihn zurück
(`nx, ny, nrot, kind, fall, wantDx, wantRot`). Ein eingelöster Tastenwunsch kommt als `0`
zurück — so wird ein Tastendruck genau einmal ausgegeben, ohne dass das Sub-Behavior die
Variablen des Aufrufers kennt.
**Woran man misst, dass der Master wirklich nur noch dirigiert:** in seinen 84 Nodes steckt
**keine Schleife und kein Listenzugriff mehr** — kein `Repeat`, `Item at`, `Set item`,
`Get position`, `Set position`, `Set text`. Das prüft der Smoke-Lauf, damit die Arbeit nicht
unbemerkt zurückwandert:
```
PASS the master calls every step as a node, and does none of their work itself
calls: spawn-piece, next-move, fits, draw-piece, lock-piece, clear-lines, show-lines, draw-board
work: []
```
`Draw piece`, `Draw board` und `Show lines` haben **keinen End-Node**: sie beantworten nichts,
sie zeichnen nur.
### Ein Fehlschlag unterwegs
Der Game-Over-Check fiel um — und die Messung nannte den Grund selbst: `lines: 20`. Meine
Vorlage für „Brunnen voll" bestand aus 19 **vollen** Reihen, die `Clear lines` wegräumte, bevor
der neue Stein überhaupt anstand. Der Check maß also das Aufräumen statt das Spielende. Jetzt
lässt jede Reihe ihre letzte Spalte frei: blockiert, aber nirgends vollständig.
Und beim Gegenprüfen fiel auf, dass mein erster Persistenz-Test nichts bewies — er lief über den
schema-geführten Weg, während der Filter, den ich repariert hatte, für Container-Instanzen gilt.
Beide Wege sind jetzt einzeln abgedeckt.
---
*Übernommen aus `todo-notes/done/tetris-und-data-logik.md` beim Umzug auf das Issue-System (2026-09-12).*
- **Angelegt:** 2026-09-09 · `1d8e6eb` — Note down two follow-up wishes
- **Abgeschlossen:** 2026-09-09 · `558365d` — Rebuild Tetris as ten behaviors that pass values around
- **Gemeldet von:** admin
admin
added the todo-note label 2026-09-12 15:03:53 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Tetris Game verbessern
das ist erst relevant wenn behavior als node funktionieren
hier ein paar fragen vorweg:
grid,shapes,colorsundspawnXgibt. diese sind sehr kryptisch. welche nodes fehlen, bzw. wie kann man das schöner gestalten.Tetris-Behavior als Node einbettenBeantwortet und umgesetzt
Beide Punkte hatten dieselbe Ursache, und die lag nicht im Tetris-Projekt: der Engine fehlte
ein Datentyp. Eine Variable konnte nur Zahl, Text oder Ja/Nein sein (
PropertyValue), alsomusste jede Menge von Werten in einen String kodiert werden. Genau daher kamen deine vier
kryptischen Variablen — nicht aus einer schlechten Wahl beim Bauen.
1. Die kryptischen Variablen: es fehlte die Liste
listist jetzt eine Variablen- und eine Port-Art. Sie hält Zahlen, Texte, Ja/Neins oderFarben und wird im Inspector als eine kommagetrennte Zeile getippt.
grid.= leer-1= leershapescolors"03066326048763714..."– Farben als 8-stellig gepaddete Dezimalzahlen#2ec9d6, #f5c542, …spawnX"3433333"3, 4, 3, 3, 3, 3, 3Dazu acht neue Nodes, alle allgemein statt Tetris-eigen:
List(Konstante),Fill(ein Wert wiederholt – so entsteht ein leeres Brett),
Count,Item at,Set item,Sub list,Join lists,Index of.Was das im Graphen ausmacht: eine Zelle lesen war
Substring(grid, i, 1)+Equals '.', jetztItem at(grid, i) >= 0. Eine Landung schreiben war sieben Nodes (zweimalSubstring,zweimal
Join,To text,Add), jetzt einer:Set item.Bewusst nicht gebaut: eine Liste von Objekten. Eine Liste wird in die Projektdatei
geschrieben, ein Objekt ist ein Handle, das keinen Reload überlebt — eine Objektliste wäre die
erste Wertsorte, die beim nächsten Laden still verschwindet. Objekte gehen weiter über Namen
(
Repeat+Item at+Object by name), und eine spätere Item-Artreference(stabile Id)wäre reines Hinzufügen, kein Bruch.
2. Aufgesplittet: aus einem Graphen sind zehn geworden
Erst waren es fünf; auf deinen Einwurf hin habe ich auch die einzelnen Schritte eines Frames
zu Behaviors gemacht, die das Master-Behavior nur noch setzt.
Spawn pieceNext moveFitsDraw pieceLock pieceClear linesShow linesDraw boardPiece cellTetrisPiece cellwar der erste Gewinn: dieselben zwanzig Nodes standen zweimal im Graphen. Jetzteinmal — und drei der anderen rufen es auf, Sub-Behaviors im Sub-Behavior.
Keins der neun hält Zustand, genau dein „kann man über input/output lösen".
Next moveistdas Beispiel dafür: es bewegt nichts, es schlägt einen Zug vor und gibt ihn zurück
(
nx, ny, nrot, kind, fall, wantDx, wantRot). Ein eingelöster Tastenwunsch kommt als0zurück — so wird ein Tastendruck genau einmal ausgegeben, ohne dass das Sub-Behavior die
Variablen des Aufrufers kennt.
Woran man misst, dass der Master wirklich nur noch dirigiert: in seinen 84 Nodes steckt
keine Schleife und kein Listenzugriff mehr — kein
Repeat,Item at,Set item,Get position,Set position,Set text. Das prüft der Smoke-Lauf, damit die Arbeit nichtunbemerkt zurückwandert:
Draw piece,Draw boardundShow lineshaben keinen End-Node: sie beantworten nichts,sie zeichnen nur.
Ein Fehlschlag unterwegs
Der Game-Over-Check fiel um — und die Messung nannte den Grund selbst:
lines: 20. MeineVorlage für „Brunnen voll" bestand aus 19 vollen Reihen, die
Clear lineswegräumte, bevorder neue Stein überhaupt anstand. Der Check maß also das Aufräumen statt das Spielende. Jetzt
lässt jede Reihe ihre letzte Spalte frei: blockiert, aber nirgends vollständig.
Und beim Gegenprüfen fiel auf, dass mein erster Persistenz-Test nichts bewies — er lief über den
schema-geführten Weg, während der Filter, den ich repariert hatte, für Container-Instanzen gilt.
Beide Wege sind jetzt einzeln abgedeckt.
Übernommen aus
todo-notes/done/tetris-und-data-logik.mdbeim Umzug auf das Issue-System (2026-09-12).1d8e6eb— Note down two follow-up wishes558365d— Rebuild Tetris as ten behaviors that pass values around