rootandClaude Opus 5
558365d33f
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>
5.0 KiB
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,colorsundspawnXgibt. 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.