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.

Does that mean you still used FSM inside the sequences or selectors?

Or you used FSM for less than you usually would. Like pure state based use-cases instead of shoe-horning it. Which I did, heh.

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?

You still need to be able to plug in stuff like decorators to say, invert values, have a throttle or a counter and etc.

Essentially you're going to need a wrapper to create a tree from either a DSL or e.g JSON from a GUI.

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.