Estados en Bevy: coordinar transiciones pendientes, trabajo de entrada y limpieza

Instalar un estado y separar sus responsabilidades

En la API de Bevy 0.20.0 citada, init_state instala los recursos del estado actual y del estado pendiente y habilita los schedules de transición. El soporte de estados requiere StatesPlugin, incluido en la colección de plugins por defecto. Usa OnEnter para el trabajo de entrada, OnExit para el de salida y una condición in_state para los sistemas que deben ejecutarse mientras un estado está activo. Son contratos de ejecución distintos. [1]

En un menú, la construcción corresponde a la entrada y la interacción a las actualizaciones continuas. Si la construcción se coloca en un sistema que se ejecuta de forma continua, los objetos pueden recrearse, a menos que lógica adicional del proyecto lo impida.

Tratar una solicitud como dato pendiente

NextState encola el destino solicitado. Otro sistema puede sobrescribir su valor antes de que se ejecuten las transiciones; no es una cola de eventos que conserve todas las solicitudes. Solo importa el valor pendiente en el momento del schedule de transición. [2]

Por defecto, StateTransition se ejecuta antes de PreStartup y después de PreUpdate en cada frame. Por tanto, una solicitud hecha más tarde en el frame espera a un punto de transición posterior, salvo que el proyecto ejecute el schedule de forma explícita en otro lugar. El código no debe asumir que solicitar un destino cambia de inmediato el estado actual ni que ejecuta sus sistemas de entrada. [3]

Resolver un conflicto concreto durante la carga

Imagina los estados definidos por el proyecto Menu, Loading y Playing. Al seleccionar un nivel se solicita la carga. El estado de carga inicia el trabajo y espera a que esté listo; solo después de eso la lógica del proyecto debe solicitar el paso a juego.

Supón ahora que la señal de que todo está listo y la cancelación del jugador llegan durante la misma actualización. Elige una regla documentada del proyecto, por ejemplo que la cancelación tenga prioridad, y deja que un único sistema de decisión escriba la solicitud final. De lo contrario, varios escritores pueden sustituirse entre sí el valor pendiente sin expresar la política prevista. Al depurar este caso, registra tanto la solicitud como la transición aplicada. Es un diseño ilustrativo, no la reproducción medida de una condición de carrera. [2]

Dar a los objetos temporales un responsable de salida

Mantén los objetos del menú distinguibles de los persistentes, de modo que el trabajo de salida del menú elimine solo lo que le pertenece. Un menú diseñado con 4 botones debe volver a contener 4 botones al regresar a él. Revisa la ruta de salida con el mismo cuidado que la de entrada, incluida la cancelación durante la carga.

Las condiciones de ejecución de estado deciden si se ejecutan los sistemas seleccionados; por sí solas no describen todos los recursos y entidades que deben sobrevivir a una transición. Define ese ciclo de vida en la lógica de configuración y de limpieza. Asegúrate de que el trabajo de entrada inicial pueda obtener sus dependencias en el punto de transición de arranque documentado. [1][3]

Elegir con criterio la semántica de las solicitudes repetidas

El método NextState::set de la referencia ejecuta los schedules de entrada y salida incluso cuando el destino es el mismo que el estado actual. Usa NextState::set_if_different cuando las solicitudes redundantes al mismo estado deban omitir esos schedules; la referencia señala que una asignación explícita previa a ese mismo estado en el mismo frame aún puede provocar que se ejecuten. [2]

Esta distinción importa si la entrada reinicia el progreso o si la salida elimina objetos temporales. Revisa la activación repetida de un botón, el regreso al menú y una solicitud al mismo estado. Ajusta los nombres de los métodos y el comportamiento a la versión de Bevy del proyecto; estas comprobaciones propuestas no se han ejecutado aquí.

Fuentes

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