Rebuild Tetris as ten behaviors that pass values around

The board is a list of 200 numbers now instead of 200 characters, so a cell is
Item at and a landing is Set item instead of seven nodes of string surgery.

The bigger change is that the one 219-node graph is gone. Each step of a frame is
a behavior of its own - Spawn piece, Next move, Fits, Draw piece, Lock piece,
Clear lines, Show lines, Draw board, plus Piece cell for where one of the four
cells of a piece sits. None of them holds state: what they need arrives through
their inputs, every answer leaves through their outputs. That is what lets Fits
answer for turning, moving and falling alike, and Piece cell serve the fit test,
the drawing and the landing instead of being the same twenty nodes three times.

Tetris itself is down to 84 nodes and only says in which order the steps run and
which variable each answer lands in. The smoke test holds it to that: it fails if
a loop or a list access reappears in the master graph.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
rootandClaude Opus 5 committed 2026-09-09 21:27:01 +02:00
1 parent a9c3111377
commit 558365d33f
5 files changed
+1022 -628

No files matched your search

+94
View File
@@ -0,0 +1,94 @@
## 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.
-7
View File
@@ -1,7 +0,0 @@
## 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