# 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`](examples/beehave_example.rs) for a worked example.
## Design Notes
This crate is designed for integration with [Bevy](https://bevy.org/) 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).