simple_bt

Crates.iosimple_bt
lib.rssimple_bt
version1.0.1
created_at2025-09-16 01:20:19.991178+00
updated_at2025-09-16 03:20:44.885196+00
descriptionminimal(-ish) behavior tree implementation
homepage
repositoryhttps://git.sr.ht/~jangermad/simple_bt/
max_upload_size
id1840758
size73,632
(Jengamon)

documentation

https://docs.rs/simple_bt/

README

Simple BT

A verrrry simple behavior tree implementation.

Included are implementations of the composite nodes in this style:

  • Succeeder: a node that always succeeds (or makes their child always succeed)
  • Inverter: inverts the success or failure of their child
  • Sequence: tick each child in order, fail if any child fails, succeed once finished
  • ParallelSequence: tick every child each tick, fail if any child fails, succeed once all children have succeeded
  • Selector: tick each child in order, succeed if any child succeeds, fail once finished
  • ParallelSelector: tick every child each tick, succeed if any child succeeds, fail if all children failed
  • Repeated: repeat child forever
  • LimitedRepeated: repeat child a number of times
  • RepeatedUntilFailure: repeat until child fails (result is success)

Central types are BehaviorNode and NodeResult.

BehaviorNode required Debug, Send and Sync, and is only expected to implement 1 function: tick, which takes the Arc the node is stored in, and a unique borrow of the blackboard type, and must return a NodeResult.

NodeResult has 3 variants: the control-flow Success and Failure, and Running, which is required to contain the node that should be run on the next tick.

For leaf nodes, this design should be relatively transparent, but for composite nodes, this requires a little more effort to maintain the tree structure on the next tick. In general, users of this library would only be writing leaf nodes (actions and conditions).

To use this library, you must create some blackboard type which doubles as a context type that controls how any leaf node interacts with its environment. See examples/beehave_example.rs for a worked example.

Design Notes

This crate is designed for integration with Bevy games, where a BehaviorArc is to be produced from the Asset system and is Send+Sync so that storing these directly into components and such is possible. Requiring a Debug implementation is just to have some visibility into the node itself.

For reflection, this design would require something like an external reflect handler that uses shared mutability (an Arced RwLock/Mutex or other sharing pattern), where the BehaviorNode implementation only read data (or for simple cases, just stored inline in the given context object).

Commit count: 0

cargo fmt