États Bevy : coordonner les transitions en attente, le travail d'entrée et le nettoyage

Installer un état et séparer ses tâches

Dans l'API Bevy 0.20.0 citée, init_state installe les ressources d'état courant et d'état en attente, et active les schedules de transition. La prise en charge des états nécessite StatesPlugin, qui fait partie de l'ensemble de plugins par défaut. Utilisez OnEnter pour le travail à effectuer à l'entrée, OnExit pour celui à effectuer à la sortie, et une condition in_state pour les systèmes qui doivent s'exécuter tant qu'un état est actif. Il s'agit de trois contrats d'exécution distincts. [1]

Pour un menu, la construction relève de l'entrée, tandis que l'interaction relève des mises à jour continues. Placer la construction dans un système qui s'exécute en permanence peut entraîner la recréation des objets, à moins qu'une logique supplémentaire du projet ne l'empêche.

Traiter une demande comme une donnée en attente

NextState met en file la destination demandée. Sa valeur peut être écrasée par un autre système avant l'exécution des transitions : ce n'est pas une file d'événements qui conserverait chaque demande. Seule compte la valeur en attente au moment du schedule de transition. [2]

Par défaut, StateTransition s'exécute avant PreStartup, puis après PreUpdate à chaque frame. Une demande émise plus tard dans la frame attend donc le point de transition suivant, sauf si le projet exécute explicitement ce schedule ailleurs. Le code ne doit pas supposer que demander une destination modifie immédiatement l'état courant ou déclenche ses systèmes d'entrée. [3]

Résoudre un conflit concret pendant le chargement

Prenons les états définis par le projet Menu, Loading et Playing. La sélection d'un niveau demande le chargement. L'état de chargement lance le travail et attend que tout soit prêt ; ce n'est qu'ensuite que la logique du projet doit demander le passage au jeu.

Supposons maintenant que la disponibilité et l'annulation par le joueur surviennent au cours de la même mise à jour. Choisissez une règle documentée pour le projet, par exemple la priorité donnée à l'annulation, et confiez l'écriture de la demande finale à un seul système de décision. Sinon, plusieurs systèmes qui écrivent cette valeur peuvent remplacer mutuellement la valeur en attente sans que la politique voulue soit exprimée. Pour déboguer ce cas, journalisez à la fois la demande et la transition effectivement appliquée. Il s'agit d'une conception illustrative, et non de la reproduction mesurée d'une situation de concurrence. [2]

Attribuer un responsable de sortie aux objets temporaires

Faites en sorte que les objets du menu se distinguent des objets persistants, afin que le travail de sortie du menu ne supprime que ce qui lui appartient. Un menu conçu avec 4 boutons doit de nouveau contenir 4 boutons lorsqu'on y revient. Examinez le chemin de sortie avec autant de soin que le chemin d'entrée, y compris en cas d'annulation pendant le chargement.

Les conditions d'exécution liées aux états déterminent si certains systèmes s'exécutent ; elles ne décrivent pas à elles seules toutes les ressources et entités qui doivent survivre à une transition. Définissez cette durée de vie dans la logique d'initialisation et de nettoyage. Assurez-vous que le travail d'entrée initial peut obtenir ses dépendances au point de transition de démarrage documenté. [1][3]

Choisir délibérément la sémantique des demandes répétées

La méthode NextState::set référencée exécute les schedules d'entrée et de sortie même lorsque la destination est identique à l'état courant. Utilisez NextState::set_if_different si les demandes redondantes vers le même état doivent ignorer ces schedules ; la référence précise qu'un appel explicite antérieur vers ce même état, dans la même frame, peut malgré tout les déclencher. [2]

Cette distinction est importante si l'entrée réinitialise la progression ou si la sortie supprime des objets temporaires. Vérifiez l'activation répétée d'un bouton, le retour au menu et une demande vers le même état. Alignez les noms de méthodes et leur comportement sur la version de Bevy utilisée par le projet ; les vérifications proposées ici n'ont pas été exécutées.

Sources

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