 42ba9dfaea
			
		
	
	
		42ba9dfaea
		
			
		
	
	
	
	
		
			
			# Objective Extracts the state mechanisms into a new crate called "bevy_state". This comes with a few goals: - state wasn't really an inherent machinery of the ecs system, and so keeping it within bevy_ecs felt forced - by mixing it in with bevy_ecs, the maintainability of our more robust state system was significantly compromised moving state into a new crate makes it easier to encapsulate as it's own feature, and easier to read and understand since it's no longer a single, massive file. ## Solution move the state-related elements from bevy_ecs to a new crate ## Testing - Did you test these changes? If so, how? all the automated tests migrated and passed, ran the pre-existing examples without changes to validate. --- ## Migration Guide Since bevy_state is now gated behind the `bevy_state` feature, projects that use state but don't use the `default-features` will need to add that feature flag. Since it is no longer part of bevy_ecs, projects that use bevy_ecs directly will need to manually pull in `bevy_state`, trigger the StateTransition schedule, and handle any of the elements that bevy_app currently sets up. --------- Co-authored-by: Kristoffer Søholm <k.soeholm@gmail.com>
		
			
				
	
	
		
			45 lines
		
	
	
		
			3.2 KiB
		
	
	
	
		
			Rust
		
	
	
	
	
	
			
		
		
	
	
			45 lines
		
	
	
		
			3.2 KiB
		
	
	
	
		
			Rust
		
	
	
	
	
	
| //! In Bevy, states are app-wide interdependent, finite state machines that are generally used to model the large scale structure of your program: whether a game is paused, if the player is in combat, if assets are loaded and so on.
 | |
| //!
 | |
| //! This module provides 3 distinct types of state, all of which implement the [`States`](state::States) trait:
 | |
| //!
 | |
| //! - Standard [`States`](state::States) can only be changed by manually setting the [`NextState<S>`](state::NextState) resource.
 | |
| //!   These states are the baseline on which the other state types are built, and can be used on
 | |
| //!   their own for many simple patterns. See the [state example](https://github.com/bevyengine/bevy/blob/latest/examples/ecs/state.rs)
 | |
| //!   for a simple use case.
 | |
| //! - [`SubStates`](state::SubStates) are children of other states - they can be changed manually using [`NextState<S>`](state::NextState),
 | |
| //!   but are removed from the [`World`](bevy_ecs::prelude::World) if the source states aren't in the right state. See the [sub_states example](https://github.com/bevyengine/bevy/blob/latest/examples/ecs/sub_states.rs)
 | |
| //!   for a simple use case based on the derive macro, or read the trait docs for more complex scenarios.
 | |
| //! - [`ComputedStates`](state::ComputedStates) are fully derived from other states - they provide a [`compute`](state::ComputedStates::compute) method
 | |
| //!   that takes in the source states and returns their derived value. They are particularly useful for situations
 | |
| //!   where a simplified view of the source states is necessary - such as having an `InAMenu` computed state, derived
 | |
| //!   from a source state that defines multiple distinct menus. See the [computed state example](https://github.com/bevyengine/bevy/blob/latest/examples/ecs/computed_states.rs)
 | |
| //!   to see usage samples for these states.
 | |
| //!
 | |
| //! Most of the utilities around state involve running systems during transitions between states, or
 | |
| //! determining whether to run certain systems, though they can be used more directly as well. This
 | |
| //! makes it easier to transition between menus, add loading screens, pause games, and the more.
 | |
| //!
 | |
| //! Specifically, Bevy provides the following utilities:
 | |
| //!
 | |
| //! - 3 Transition Schedules - [`OnEnter<S>`](crate::state::OnEnter), [`OnExit<S>`](crate::state::OnExit) and [`OnTransition<S>`](crate::state::OnTransition) - which are used
 | |
| //!   to trigger systems specifically during matching transitions.
 | |
| //! - A [`StateTransitionEvent<S>`](crate::state::StateTransitionEvent) that gets fired when a given state changes.
 | |
| //! - The [`in_state<S>`](crate::condition::in_state) and [`state_changed<S>`](crate::condition::state_changed) run conditions - which are used
 | |
| //!   to determine whether a system should run based on the current state.
 | |
| 
 | |
| /// Provides definitions for the runtime conditions that interact with the state system
 | |
| pub mod condition;
 | |
| /// Provides definitions for the basic traits required by the state system
 | |
| pub mod state;
 | |
| 
 | |
| /// Most commonly used re-exported types.
 | |
| pub mod prelude {
 | |
|     #[doc(hidden)]
 | |
|     pub use crate::condition::*;
 | |
|     #[doc(hidden)]
 | |
|     pub use crate::state::{
 | |
|         apply_state_transition, ComputedStates, NextState, OnEnter, OnExit, OnTransition, State,
 | |
|         StateSet, StateTransition, StateTransitionEvent, States, SubStates,
 | |
|     };
 | |
| }
 |