Expressing behaviours and state changes in BTs

[grofit]

Hey,

So again I am still fairly new to the whole BT paradigm, so I have a question around state of an entity.

So lets say I am making a simple beat em up game, so my character can move, attack, take damage, idle as basic states (from a FSM point of view). Now with an FSM I would transition from Idle -> Move when I press a move button etc, however when attacking I should not be able to move, same with when I am taking damage. So basically in an FSM world I have states and transitions.

So in the BT world how do I go about expressing these sort of behaviours?

So lets say I have the same behavours Move, Idle, Attack, TakeDamage. I would assume each one would be a sub tree, and there would be a condition to move from one behaviour to another, so in FSMs I can transition to attacking from Idle, Move however I am not sure how to express that in the BT world as if I am on idle, I can check if a button is down then go to move, however when I attack I do not want to move, so I am a bit confused as the best way to manage state, i.e should I have a state enum which is just checked on selectors each level down the tree being a different behaviour, or should I be doing it based more on button presses etc?

I hope this makes sense, the clarify my main question is about managing the transitions between behaviours.

[Gavalakis]

Hey,

Personaly, I wouldn’t try to force myself creating a BT that works like an FSM since it’s a different logic, but I understand what you mean.
My choice would be something like the attached screenshot.
Every “state” (here an action for demo, but a subtree most certainly), is “layered” in priority, from highest to lowest. Thats the number one rule of thumb for BTs 🙂

So the Taking Damage is the most important one and it should happen no matter what.
Then the Attack, is higher priority than move, which means that if while I’m moving, I press the attack button, the attack will take place since it’s more important even if the ‘Move’ is not yet finished (eg animations).
The Move, well it’s just above the Idle and the Idle is the last resort, when nothing else is going on.

The way this is build layering priorities, it means that if I’m attacked and the ‘taking damage’ behaviour is going on, I am unable to move or attack myself or otherwise, since the Taking Damage is the higher priority.

Same of course goes for if I’m Attacking, I won’t be able to move until the Attack “State” is finished (eg finished animations etc)

The Dynamic Selector makes it possible to switch between those “States” at will as soon as the condition of the Accessor becomes true even while a lower priority “State” is not “Finished”. So we can think of the Accessors here kind like the transitions of an FSM, but possible to transit from lower to higher priorities only.

Personaly I would chose a more declarative/direct condition checking instead of an enum, unless there are a lot of things going on.

The condition for the move in this example is silly, but you get the point 🙂 You could check the velocity for example.
The condition for the Take Damage is a Check Event, which can be send to this agent from another agent or other means as an example.

So, again, the rule of thumb is to layer the behaviours/states in priority. There always have to be some 🙂

Im certain there are more ways to go about it, but this would be my personal preferance.

Join us on Discord: https://discord.gg/97q2Rjh

[grofit]

Hey this makes sense, I am only talking with the FSM paradigm because I do not really *get* the BT paradigm yet, however the above is similar to what I thought it would be, check which trigger is active (be it a state, a key down, a collision) then run that behaviour.

One other question on this, with FSMs (especially Playmaker) there is a lot of event based communication to de-couple certain things, so like one thing may be listening for input and based upon the input that would fire an event for another state to pick up, so something like CheckForInputState, then if “Space” was pressed raise the “Attacking” event, if a <move> key was pressed fire the “Moving” event etc, so is there any sort of event based interactions within behaviour trees or is it all done in a hierarchical manner? I would assume it is only done as a tree hence the name Behaviour TREES.

[Gavalakis]

Well, there is a simple event system in there (I like simple). In practise you can check an event with a condition and send and event in many different ways, the simplest being the SendEvent action, but you can send an event from within any action/node or just directly through the GraphOwner or the Graph itself.

In the example tree above the first Accessor’s condition is a CheckEvent (“if [Attacked]”).
You could send that [Attacked] named event somehow (eg: owner.SendEvent(“Attacked”) or SendEvent Action) and the Dynamic Selector would respond.
Keep in mind that an event is true only for one frame.

So in practise it’s just like another condition. Of course in the context of BTs the tree will still be evaluated hierarchicaly 🙂

Join us on Discord: https://discord.gg/97q2Rjh

[Author]

Posts