## 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.