I used this article (and some other pieces) to help with some robotics research in Python a few months ago. Behavior trees are fantastic abstractions that definitely simplify FSM code, but I found that working within the constraints of decorators could really complicate behavior architectures that can instead be implemented more linearly. Specifically, I wanted to have an overall obstacle avoidance behavior separated from individual movements, but ended up implementing an obstacle avoidance function library totally separate from the BT.
Nice article. This looks a bit like a way to implement a scripting language that uses lightweight threads in a system that doesn't have it built in.
If you're using a language that has either lightweight threads or async/await built in, would you still use a behavior tree, or would you just write code?
A behaviour tree can be data-driven easily, which opens opportunities for easy editing via DSLs, graphical tools and even changing the AI on the fly at runtime. If you can afford it, do BTs.
Interesting article. It seems to me like what you really want here is to do this in a lisp/scheme. Then you can use the full power of lisp (it's the exact same syntax as the behavior tree), leverage lisp's built-in control flow constructs, and just implement nodes as functions with side-effects that return either true, false, or null or something.
