Entscheidung in #51: Zustand pro Behavior-Instanz (Instance.states). Folgen, die beim Bauen sichtbar wurden:
Zwei Behaviors am selben Objekt sehen dieselbe Maschine in verschiedenen Zuständen.
Ein Run behavior-Aufruf startet mit states: {} (wie mit frischen Variablen) – das aufgerufene Behavior kann den Zustand des Aufrufers weder lesen noch setzen.
Ein Objekt, das ein anderes befragen will („ist die Tür offen?“), hat keinen Weg.
Zu klären: Soll der Zustand an das Szenenobjekt (wie Properties/entity.props) statt an die Instanz? Dann teilen alle Behaviors eines Objekts und verschachtelte Aufrufe denselben Zustand, und ein Node State of object (Objekt + Maschine rein, Zustand raus) wird möglich. Alternativ ein globaler Scope pro Maschine für „Spielzustand“ (Menü/Level/Pause).
Kein Umbau ohne Entscheidung – hier nur die Frage festgehalten.
Folge-Issue zu #51 (State machine, Commit e7d82bd, 2026-09-12).
Entscheidung in #51: Zustand **pro Behavior-Instanz** (`Instance.states`). Folgen, die beim Bauen sichtbar wurden:
- Zwei Behaviors am **selben Objekt** sehen dieselbe Maschine in **verschiedenen** Zuständen.
- Ein `Run behavior`-Aufruf startet mit `states: {}` (wie mit frischen Variablen) – das aufgerufene Behavior kann den Zustand des Aufrufers weder lesen noch setzen.
- Ein Objekt, das ein anderes befragen will („ist die Tür offen?“), hat keinen Weg.
**Zu klären:** Soll der Zustand an das **Szenenobjekt** (wie Properties/`entity.props`) statt an die Instanz? Dann teilen alle Behaviors eines Objekts und verschachtelte Aufrufe denselben Zustand, und ein Node `State of object` (Objekt + Maschine rein, Zustand raus) wird möglich. Alternativ ein globaler Scope pro Maschine für „Spielzustand“ (Menü/Level/Pause).
Kein Umbau ohne Entscheidung – hier nur die Frage festgehalten.
---
Folge-Issue zu #51 (State machine, Commit `e7d82bd`, 2026-09-12).
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.
Entscheidung in #51: Zustand pro Behavior-Instanz (
Instance.states). Folgen, die beim Bauen sichtbar wurden:Run behavior-Aufruf startet mitstates: {}(wie mit frischen Variablen) – das aufgerufene Behavior kann den Zustand des Aufrufers weder lesen noch setzen.Zu klären: Soll der Zustand an das Szenenobjekt (wie Properties/
entity.props) statt an die Instanz? Dann teilen alle Behaviors eines Objekts und verschachtelte Aufrufe denselben Zustand, und ein NodeState of object(Objekt + Maschine rein, Zustand raus) wird möglich. Alternativ ein globaler Scope pro Maschine für „Spielzustand“ (Menü/Level/Pause).Kein Umbau ohne Entscheidung – hier nur die Frage festgehalten.
Folge-Issue zu #51 (State machine, Commit
e7d82bd, 2026-09-12).