Docs: When to use behaviour groups vs ST vs BT

[madeleineostoja]

More of a question than an issue, for a section that might be helpful to add to the docs — as the author of the library it would be great to know when you’d recommend using the core behavior and action grouping compared to the bundled BT and state chart / tree implementations?

I think the case for BT is clear, as it adds several selectors and decorators that allow for traversal logic on top of utility scoring (but the core action groups allow for the sequencing that BTs are mainly used for, maybe something to point out in docs). However the case for the state tree is much less clear for me. Can’t the core behavior and action groups do everything the state tree can and more? Is the only reason to use the state nodes to allow explicit action selection with transition_to?

And looping back to BTs, since the basic sequencing and tree organisation is duplicated with behavior and action groups, would there be any sense in just adding the functionality of additional decorators and selectors into the core concept of behaviors and actions instead? One implementation to rule them all?

[JarkkoPar]

I'll add a section about this in the docs, good questions.

The Action Groups and Actions in the Agent Behaviours work well when you have somewhat simple action sequences you want to execute for a Behaviour. Compared to Behaviour Trees, the Actions are a more high-level concept.

Behaviour Trees allow the creation of more robust plans for realizing a Behaviour or an Action. A very good example that many quickly run in to is moving the AI entity from one place to another using path finding. I see this as a long-running task and during the task a lot of things can happen: The AI can get stuck, the AI may need to climb up a ladder, or maybe jump off a cliff, for instance. Behaviour trees are perfect for handling such situations.

I could make the BT more tightly bound to the Agent Behaviour concept, but I've decided to keep the binding as loose as possible to allow the use of the Behaviour Trees without the other nodes. So the devs who just want to create a behaviour tree with some score-based picking have the option of doing so. I think your feedback is very good, though, for maybe I can keep this option and make it more straight-forward to have a behaviour tree as just one of the Actions in a Behaviour.

The short answer to your question about state trees is yes, the direct transitioning is one of the reasons behind state trees. Agent Behaviours and Behaviour Trees are not built with the idea of directly jumping from a node to another. A State Tree is also a general-purpose hierarchical state machine. You can use it for defining states for an AI entity, but also for any other state selection you may need (states of menus, items, game in general, ...). I've used them to manage the states of a network game when loading a level & syncing the game state, and to handle the states of a platformer character controller. The utility-aspects give the State Tree more versatility when choosing the child state, so the prioritization of the child states can be less static.

My own usage of these nodes is that I use Agent Behaviours and State Trees to define the overall Behaviour/State selection, and then when needed I use a Behaviour Tree to create the more detailed plan to realize the Behaviour/State. This keeps the state management out of the Behaviour Trees and makes them smaller, and on the other hand allows the Behaviours/States to focus on the "bigger picture" and care less about the details or complexities of how the related goal is achieved.

[madeleineostoja]

Wonderful insight, thanks!

And yep I’ve ended up doing something quite similar when planning out my ai agents — behaviors at the top level to execute deterministic BTs for individual “actions”. But then I realised the inbuilt action and behaviour group nodes were feeling pretty similar to BT sequences, and that’s all I currently need, hence the question :)

I’m not experienced enough in the area to know whether or not it would be a good idea to add additional BT concepts (decorators, etc) to core actions and behaviours, but it feels like it could be elegant. Either that OR even trim down the scope of core actions and behaviors, so if you want sequencing and a tree-like structure you use the BT nodes. Just feels like a lot of crossover between the two atm.

Fair enough re the state tree implementation, I figured that was the case. I already have a decently robust state machine setup so I was wondering if I was missing something.