The main thing you need to think about when constructing a BT is priority. That is, "if I don't need to do A, I can consider doing B". You repeat a lot of that until you get down the most basic thing... like an idle state. In your case, "Flee" is the highest priority -- it is self-preservation and nothing else matters at the time. If you are not fleeing, you are fighting, if you are not fighting, you might be looking. If you are doing none of those, you are idle. Each of those nodes would have a conditional check similar to what you are already doing.

Is my health low and there is an enemy? Flee. If not...
Is there an enemy? Fight.
Is there a sound? Suspicious.
Idle.

For the most part, you evaluate the BT every think cycle. If the conditions are the same, you end up right where you were. If they change, you might end up in a different place.

Now this is the simple version... there are obviously more things that you could do with it. For example, "fight" could have things like "move to opponent" and "attack". The former would have the simple condition that we are out of range of the target. If we are IN range, then we would fall through to "attack". Of course, we would only be in this branch if there was an enemy in the first place (the condition we checked above).

That's a quick primer on how to "think" in BTs.

For starters, yeah.

Perhaps this will help.

Here is an excerpt from one of my test BTs. Maybe it'll help





new Behavior(
new RootSelector(
//determins which branch to take
getEnemyState,

//Idle State
new Selector(
new Conditional(() => false)
),

//Active State
new Selector(
new Conditional(() => false)
),

//Combat State
new Selector(

//get a target
new Sequence(
//do i have a target?
new Inverter(new Conditional(hasLiveTarget)),
//get a target
new BehaviorAction(findTarget)
),

new Selector(
//attempt to move back into range of target
new Sequence(
//check to verify you still have a target
new Conditional(hasLiveTarget),
//are you too close to the target
new Conditional(isTargetTooClose),
//not too far
new Inverter(new Conditional(isTargetTooFar)),
//can you move away
new Conditional(canMoveAwayFromTarget),
//move
new BehaviorAction(move)
),

//attempt to move within range of target
new Sequence(
//check to verify you still have a target
new Conditional(hasLiveTarget),
//are you too far from the target
new Conditional(isTargetTooFar),
//not too close
new Inverter(new Conditional(isTargetTooClose)),
//can you move towards the target
new Conditional(canMoveTowardsTarget),
//move
new BehaviorAction(move)
)
),

//attempt to attack the target
new Sequence(
//check to verify you still have a target
new Conditional(hasLiveTarget),
//are you too close to the target
new Inverter(new Conditional(isTargetTooClose)),
//are you too far from the target
new Inverter(new Conditional(isTargetTooFar)),
//can you attack the target
new Conditional(isTargetAttackable),
//attack target
new BehaviorAction(attackTarget)
),

//go idle until something happens.
new Sequence(
//assess self
new BehaviorAction(idle)
)

)
)
);



Not sure what language or pseudo code form this is, but doesnt it seem that he word 'new' used for every function call/whatever is redundant/cluttery ?

This (Behavior Trees) is basicly nested if-then logic which is OK for some types of logic processing but most more complex decision making requires
actual 'state' that gets resumed so to to bypass reprocessing previously passed decisions and allows concentrating on calculating decisions
in the current context.

Ive looked at FSM use for quite complicated AI (FSM for 'solutions' picked by a planner) and saw that you usually have to load up each state
with logic testing local resume-conditions to see if the current state/context still applies (and then usually transitioning backwards to a FSM
predecessor state or even restarting the FSM
Similarly the design also has shunts/shortcuts to precheck fulfilment of a states pass requirements and skipping that states actions to go on
to subsequent states in the sequence.

The BT like construct would be used to control the state transitions within a FSM (but custom to each state)


1)Moveto Toolbin
2)Grab Hammer
3)Moveto Worksite
4)Hammer Something

if you start this task/solution and you already have a hammer you should have the logic skip the first 2 states

If you get to the worksite (probably a recursive FSM to make that happen) and you no longer have a hammer (retest possession of the tool) then
you need to back up to the point where the hammer is acquired . That state will check position and if you are 'there' then it will skip the move and
go do the next state.

Notice it only runs the decsion logic IF the context calls for it and not every time.
At each state in the sequence you dont want to have to retest all the preconditions (which in more complex AI may dwarf the processing of simple if-then statement tests)

Just for state 1 you might need to test:

where am I (position is often alot more than just coords)
Can I move (what means)
Where is the toolbin (has it moved) - find it - path or repath



if you are at state 3 you check if you have a hammer (appropriate type maybe) and who cares about testing precondition of [revious state that are not relevant
to the current context. Processing of the above is usually ALOT more work than just looking in simple variables.

There are other logic constructs/features like handling retries on failures (and how many before giving up - often a complex cost allowance system) that can muck up the logic or handling parallel subtasks (where the most opportune gets done first and its results are maintatined while the other task is then done)

When you have this added complexity to the definition of the decision process suddenly the FSMs organization around localized context becomes much more useful.





Behavior Trees are one tool that has its use in the right place and FSMs in their place.

I might use the ordered test logic of a BT to do an overall (frequently run) situational test (one where you do test everything thru a static priority first ordering)
to find when current activities are to be aborted and new priorities force complete reevalution of the situation from a fdifferent logical point of view.

EX- hitpoints at low threshold -- all behavior changes to survival mode and all previously calculated priorities and subtask priorities are null and void.



Similarly if you have fairly dumb objects who's entire decision tree is short/simple to calculate (thus not all that much cost to rerun every/frequent decision cycle)
then simplifying the coding to be less than what a FSM requires can be simpler to create. Some physics reactive code might be like this because
you are choosing/arbitrating between modal processing for discrete factors (ex- set-on-fire event intersected with splashed-with-water event )

In really complex simulated environments you probably start using a multidimentional lookup table because of all the combinations and the irregular logic and
special endcases that likely exist (and laying out the logic linearly will be tedius and hard to visualize/validate)






Oh and an added comment is that even FSMs get to large/unwieldy when dealing with complex decisions/tasks so that Hierarchical FSMs would be used to try to keep their individual complexity down AND in my designs there is a planner type decision picking/evaluating between potential solutions that gets done, and then those sub-solution are FSMplus . Note - the 'evaluation' when picking the best solution is a one-pass set of tests per solution that probably will resemble BTs stacked logic