how to keep composite node retick running child？

[benloong]

the selector and sequence node did not save running child index，so next tick will restart tick children？

[linkdd]

Let's say I have a CharacterController state machine with the following states:

• Idle
• Moving Towards Enemy
• Attack Enemy

And a Behavior Tree composed of the following nodes:

• Sequence:
  • Check: If Enemy in field of view, then SUCCESS, else FAILURE
  • Task: Transition CharacterController to state Moving Towards Enemy, then SUCCESS
  • Check: If Enemy in attack range, then SUCCESS, else RUNNING
  • Task: Transition CharacterController to state Attack Enemy, then RUNNING

Now, an enemy comes into the field of view, so the first check succeeds, which means the task is executed, which change the state machine's state. The enemy is not yet in attack range, so the second check is still RUNNING, therefore the sequence node is RUNNING as well (the last task is not executed this tick).
Then, you run the state machine's update (its tick) which moves the character towards the enemy.

Next tick, the enemy is still into the field of view, so the first check succeeds, the first task transitions the state machine (which is a no-op since it is already in that state), then the second check is executed. The enemy is now in attack range, so the check succeeds and we move on to the second task which transitions the CharacterController to the Attack Enemy state and returns RUNNING, the sequence node is therefore still RUNNING.
Then, you run the state machine's update which kills the enemy.

Next tick, there is no enemy in the field of view, so the first check returns FAILURE, and therefore the sequence node returns FAILURE.

---

TL;DR: To maintain state between ticks, I'd use a state machine given to the behavior tree via its "world" data structure.

I hope it answers your question 🙂

[linkdd]

NB: The second check is actually a task, since a check only returns SUCCESS or FAILURE.

[linkdd]

auto tree = seq<blackboard_type>(
  node_list<blackboard_type>(
    check<blackboard_type>([](const blackboard_type& bb) {
      return has_enemy_in_fov(bb.character_controller, bb.enemies);
    }),
    task<blackboard_type>([](const blackboard_type& bb) {
      auto enemy = find_closest_enemy(bb.character_controller, bb.enemies);
      move_towards_enemy(bb.character_controller, enemy);
      return execution_state::success;
    }),
    task<blackboard_type>([](const blackboard_type& bb) {
      auto enemy = find_closest_enemy(bb.character_controller, bb.enemies);
      if (enemy_in_attack_range(bb.character_controller, enemy)) {
        return execution_state::success;
      }
      else {
        return execution_state::running;
      }
    }),
    task<blackboard_type>([](const blackboard_type& bb) {
      auto enemy = find_closest_enemy(bb.character_controller, bb.enemies);
      attack_enemy(bb.character_controller);
      return execution_state::running;
    })
  )
);

Then:

/* each tick */
auto bb = blackboard_type{
  .character_controller = /* ... */,
  .enemies = /* ... */,
};
tree.evaluate(bb);
update_character(bb.character_controller);

[benloong]

Thank you @linkdd. its sound not like a traditional behavior tree.

[linkdd]

It is a very simple implementation yes.

In my game engine (WIP), I implemented Unity-like coroutines, so I also have some tasks that are RUNNING as long as the coroutine has not returned.

It's up to the user to decide how to hook this library to their code, I did not want to impose anything on the actual architecture, which is why this is very barebones.

[linkdd]

Also, moving this to a discussion rather than an issue.