seldom_state
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 bundle 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:
Rust
commands.spawn((
// ... (other inserts)
StateMachine::new(my_initial_state)
.trans::<MyState1>(my_trigger_1, my_state_3)
.trans::<AnyState>(my_trigger_2, my_state_4)
.trans_builder::<MyState2, _, _>(my_trigger_3, |trigger_data| make_state_5(trigger_data))
.insert_on_enter::<MyState7>(my_bundle)
.remove_on_exit::<MyState7, 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 any of the docs
need improvement, feel free to submit an issue or pr!
AlwaysTrigger
: always triggersNotTrigger
: contains a trigger, which it negatesDoneTrigger
: triggers when the user adds the Done
component to the entityleafwing_input
featureAnyState
state, that can be used in type parameters to represent any stateStateMachine::trans_builder
)StateMachine::insert_on_enter
and StateMachine::remove_on_exit
)leafwing_input_manager
](https://github.com/Leafwing-Studios/leafwing-input-manager)
integrationAnd<A: Trigger, B: Trigger>(A, B)
(I might
implement this, and definitely want it)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:
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 defined transitions, you may want to implement a fuzzy state machine. Otherwise, this crate
will likely work for you!
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.
Add to your Cargo.toml
```toml
[dependencies] seldom_state = "*" ```
See the chase.rs
example for futher usage.
| Bevy | seldom_state
|
| ---- | -------------- |
| 0.9 | 0.3 |
| 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.