seldom_state
is a component-based state machine plugin for Bevy. It's useful for AI, player state,
and other entities that occupy various states. It allows for greater reusability of state logic
between entities, compared to managing mutually-exclusive components directly in your systems.
A state is a component attached to an entity that defines its current behavior, such as Jumping
or Stunned
. A trigger is a type that checks information about entities in the world, such as
NearPosition
or HealthBelowThreshold
. A transition links two states: one to transition from,
and one to transition to; once a given trigger has occurred. A state machine is a component
attached to an entity that keeps track of that entity's transitions, and automatically changes the
entity's state according to those transitions.
State machines are created like so:
commands.spawn((
// ... (other inserts)
MyInitialState::new()
StateMachine::default()
.trans::<MyInitialState>(my_trigger_1, my_state_2)
.trans::<AnyState>(my_trigger_3, my_state_4)
.trans_builder(my_trigger_5, |my_state_6: &MyState6, trigger_data| {
make_state_7(my_state_6, trigger_data)
})
.on_enter::<MyState7>(move |entity| entity.insert(my_bundle.clone()))
.on_exit::<MyState7>(|entity| entity.remove::<MyBundle>())
// etc.
));
For more complete examples, see the examples
directory. The chase.rs
example is written like a
guide, so it is good for learning. If you need help, feel free to ping me on
the Bevy Discord server (@Seldom
)! If anything needs
improvement, feel free to submit an issue or pr!
- State machine component with user-defined states and triggers
- 15 built-in triggers
AlwaysTrigger
: always triggersNotTrigger
,AndTrigger
, andOrTrigger
: combines triggers with boolean logicDoneTrigger
: triggers when the user adds theDone
component to the entity- 9 more triggers enabled by the
leafwing_input
feature:ValueTrigger
,ClampedValueTrigger
,AxisPairTrigger
,ClampedAxisPairTrigger
,JustPressedTrigger
,PressedTrigger
,JustReleasedTrigger
,ReleasedTrigger
, andActionDataTrigger
EventTrigger
: triggers when it reads an event of the given type
AnyState
state, that can be used in type parameters to represent any state- Transition builders that allow dataflow from outgoing states and triggers to incoming states
(
StateMachine::trans_builder
) - Automatically run events upon entering or exiting states (
StateMachine::on_enter
,StateMachine::on_exit
,StateMachine::command_on_enter
andStateMachine::command_on_exit
)
Comparison with big-brain
Finite state machine is an old and well-worn pattern in game AI, so its strengths and limitations are known. It is good for entities that:
- Do not have a large number of interconnected states, since the number of transitions can grow quadratically. Then it becomes easy to forget to add a transition, causing difficult bugs.
- Act rigidly, like the enemies in Spelunky, who act according to clear triggers such as got-jumped-on-by-player and waited-for-5-seconds, and unlike the dwarves in Dwarf Fortress, who weigh their options of what to do before taking an action.
seldom_state
is a finite state machine implementation, so it may not be suitable for all types of
game AI. If you need a solution that works with more complex states and transitions, then you may
want to implement
a behavior tree (I
had little luck turning existing implementations into a Bevy plugin without forking them). If you
need a solution that operates on fuzzy logic, and do not need to define which transitions should be
allowed, then I recommend big-brain
. If you need fuzzy logic and discrete transitions, you may
want to implement a fuzzy state machine. If you need discrete transitions, but not fuzzy logic,
consider seldom_state
!
seldom_state
is not just an AI crate, though. So, you may want to use big-brain
for your
enemies' AI, and seldom_state
to manage state for your player, and control enemies' animation, or
something.
seldom_state
is rather versatile, so some problems may be solved in multiple ways. If you're lost,
here is some advice.
There are a few solutions to this. The most straightforward is to add the animations to the entity
with on_enter
. This works for animation systems that rigidly follow behavior, such as the player
controller in a 2D fighter or a basic enemy controller. Of course, this is rigid, and anything that
the animations must remember between states must be handled manually. In a platformer like Celeste
that has multiple animations for a single state (lets assume it has states Grounded
, Airborne
,
Dashing
, and Climbing
), you might manage some animations, like the dashing animation, through
on_enter
, and others, like the walk cycle, through systems. Or, you might manage all animations
through systems. This is up to preference.
On the other hand, if your animations are less constrained to behavior, consider using multiple state machines, as in the next section:
Consider a 2D platformer, where the player has a sword. The player can run and jump around, and they
can swing the sword. So whether you're running, jumping, or dashing, you always swing the sword the
same way, independently of movement state. In this case, you might want to have a movement state
machine and an attack state machine. Since entities can only have one state machine, spawn another
entity with its own state machine, and capture the original Entity
in closures in
command_on_enter
and command_on_exit
.
However, perhaps your states are not so independent. Maybe attacking while dashing puts the player
in a PowerAttack
state, or the attack cooldown doesn't count down while moving. Depending on the
scale of the dependency, you might want to just have your state machines communicate through
commands and observing each other's states, or you might want to combine the state machines,
permuting relevant states into states like DashAttack
and IdleAttackCooldown
.
Also, consider managing one set of states through a state machine and another through systems.
Remember that StateMachine
is component-based, so you can solve some problems normally through
Bevy's ECS. Instead of on_enter::<MyState>
you can use Added<MyState>
in a system, and you can
even change state manually through remove
and insert
commands. If you do change state manually,
callbacks like on_enter
will not be called, and you will have to make sure that the state machine
remains in exactly one state at a time. Else, it will panic.
Add to your Cargo.toml
# Replace * with your desired version
[dependencies]
seldom_state = "*"
See the chase.rs
example for further usage.
Bevy | seldom_state |
---|---|
0.10 | 0.5 - 0.6 |
0.9 | 0.3 - 0.4 |
0.8 | 0.1 - 0.2 |
seldom_state
is dual-licensed under MIT and Apache 2.0 at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.