Bevy States: ausstehende Übergänge, Eintrittsarbeiten und Aufräumen koordinieren

Einen State installieren und seine Aufgaben trennen

In der zitierten Bevy-0.20.0-API installiert init_state die Ressourcen für den aktuellen und den ausstehenden State und aktiviert die Übergangs-Schedules. Für die State-Unterstützung ist StatesPlugin erforderlich, das in der Standard-Plugin-Sammlung enthalten ist. OnEnter dient für Arbeiten beim Eintritt, OnExit für Arbeiten beim Austritt, und eine in_state-Bedingung für Systeme, die laufen sollen, solange ein State aktiv ist. Das sind unterschiedliche Ausführungsverträge. [1]

Bei einem Menü gehört der Aufbau zum Eintritt und die Interaktion zu den laufenden Updates. Liegt der Aufbau in einem dauerhaft laufenden System, können Objekte immer wieder neu erzeugt werden, sofern zusätzliche Projektlogik dies nicht verhindert.

Eine Anforderung als ausstehende Daten behandeln

NextState hält das angeforderte Ziel vor. Der Wert kann von einem anderen System überschrieben werden, bevor die Übergänge laufen; es ist keine Event-Queue, die jede Anforderung bewahrt. Massgeblich ist allein der ausstehende Wert zum Zeitpunkt des Übergangs-Schedules. [2]

Standardmässig läuft StateTransition vor PreStartup und danach in jedem Frame nach PreUpdate. Eine Anforderung, die später im Frame erfolgt, wartet daher bis zum nächsten Übergangszeitpunkt, sofern das Projekt den Schedule nicht ausdrücklich an anderer Stelle ausführt. Code sollte nicht davon ausgehen, dass das Anfordern eines Ziels den aktuellen State sofort ändert oder sofort die Eintrittssysteme des Ziels ausführt. [3]

Einen konkreten Konflikt beim Laden auflösen

Angenommen, das Projekt definiert die States Menu, Loading und Playing. Die Auswahl eines Levels fordert das Laden an. Der Loading-State startet die Arbeit und wartet auf die Bereitschaft; erst danach sollte die Projektlogik den Wechsel zum Spielen anfordern.

Nun sei angenommen, dass die Bereitschaft und der Abbruch durch den Spieler im selben Update eintreffen. Hier ist eine dokumentierte Projektregel zu wählen, etwa dass der Abbruch Vorrang hat, und ein einzelnes Entscheidungssystem soll die endgültige Anforderung schreiben. Andernfalls können mehrere schreibende Systeme den ausstehenden Wert gegenseitig ersetzen, ohne dass die beabsichtigte Regel zum Ausdruck kommt. Beim Debuggen dieses Falls sind sowohl die Anforderung als auch der tatsächlich angewendete Übergang festzuhalten. Dies ist ein illustrativer Entwurf und keine gemessene Reproduktion einer Race Condition. [2]

Temporären Objekten einen Austritts-Verantwortlichen geben

Menüobjekte sollten sich von dauerhaften Objekten unterscheiden lassen, damit die Austrittsarbeit des Menüs nur entfernt, was ihm gehört. Ein Menü, das mit 4 Buttons entworfen wurde, sollte nach der Rückkehr wieder 4 Buttons enthalten. Der Austrittspfad ist ebenso sorgfältig zu prüfen wie der Eintrittspfad, einschliesslich eines Abbruchs während des Ladens.

State-Run-Conditions entscheiden, ob ausgewählte Systeme ausgeführt werden; sie beschreiben für sich genommen nicht jede Ressource und jede Entity, die einen Übergang überdauern soll. Diese Lebensdauer ist in der Setup- und Cleanup-Logik zu definieren. Ausserdem ist sicherzustellen, dass die erste Eintrittsarbeit ihre Abhängigkeiten am dokumentierten Startübergangszeitpunkt erhalten kann. [1][3]

Die Semantik wiederholter Anforderungen bewusst wählen

Das referenzierte NextState::set führt Eintritts- und Austritts-Schedules auch dann aus, wenn das Ziel dem aktuellen State entspricht. NextState::set_if_different ist zu verwenden, wenn überflüssige Anforderungen desselben States diese Schedules überspringen sollen; laut Referenz kann ein früheres explizites Setzen auf denselben State im selben Frame sie dennoch auslösen. [2]

Dieser Unterschied ist wichtig, wenn der Eintritt den Fortschritt zurücksetzt oder der Austritt temporäre Objekte löscht. Zu prüfen sind wiederholtes Betätigen eines Buttons, eine Rückkehr zum Menü und eine Anforderung desselben States. Methodennamen und Verhalten müssen zur Bevy-Version des Projekts passen; diese vorgeschlagenen Prüfungen wurden hier nicht ausgeführt.

Quellen

1. AppExtStates — Bevy contributors.
2. NextState — Bevy contributors.
3. StateTransition — Bevy contributors.