Is it fair to call this an AI library? It looks like a nice, graphical way to put together control flow statements. But this description doesn't mention features you might find in other cognitive architectures, like keeping a working memory or any kind of learning.
There's kind of a trend towards reactive-AI architectures in some areas, especially in game-AI and robotics, with a focus on concise human authoring of situationally reactive plans, as opposed to autonomous learning/etc. The intelligence comes in the ability for a human to specify a fairly concise, high-level plan, which will then "do the right thing" in various situations, without having to explicitly specify all the variations of what that might be. That admittedly gives it a strong PLs focus rather than being a pure AI problem.
Three papers on different approaches, getting sort of progressively further from classical planning as time goes on:
The last one is the direct inspiration for this library I assume, since it's the source of the term "behavior trees". I agree that many do have somewhat more complexity; for example, the 2nd link above is a reactive system with working memory, resolution of joint and dependent behaviors, etc. But game developers have tended to want to strip things down as bare-bones as possible, due to wanting: 1) minimal CPU usage; 2) a simple enough model that not-very-technical gameplay designers can specify a lot of the behaviors; and 3) something simple and deterministic enough that the engineers can predict and debug its behavior.
Well, you get basically nothing for free with the if statements; you have to explicitly code every possible variation in reactive behavior. The ideal system is one that lets human specify the parts they want to specify, and not specify the parts they don't want to specify, so you say "I want you to do X", and then it does the right thing in thousands of possible scenarios.
I mean ultimately, all AI is just a higher-level way of writing normal programs, because it compiles down to the same assembly code as everything else. It's just an issue of what you have to write explicitly, and what you get seemingly "for free". In many areas, the human wants to specify very little (say, a fitness function, or some planning operators plus a plan goal) and then get an automatic answer, but in areas like game-AI, the human wants to specify quite a bit more, but still wants some stuff for free.
So the difficult problem is coming up with a behavior-specification language, supported by a backend that implements it, that lets people specify exactly the parts of things like NPC behavior they want to specify, but then figures out how to apply them in various situations, resolve conflicts, enact them jointly, etc. NPC designers really do have a ton of specific things they have in mind for the NPC's behaviors and personality that they want to be able to encode somewhere, but they don't want to literally have to script every possible variation on every possible NPC interaction, since that blows up exponentially, especially with multiple NPCs and nonlinear storylines. Admittedly, behavior trees are fairly far towards the "you don't get much for free" end of the spectrum, even compared to other reactive planners.
Regarding the question about whether it's fair to call this an AI library...well it's kind of a valid question. But really this is game AI which is isn't trying to be Artificial Intelligence, it's just the subject of making game agents perform behaviours and look intelligent - or even just functional. But is your question really even an important question? Much of classical AI can just be reduced to search (which is why prolog is so popular in university AI courses). Is search AI? Is it any more AI than putting together control flow statements? There is a lot of stuff that can happen in those condition and behaviour nodes. And yes in trivial examples the control flow is fixed, but the "learning" is done by hand by the coder/designer (is it any more "AI" to have it done by a evolutionary algorithms?). And more advanced versions of behaviour trees can incorporate much more sophisticated selectors than just "pick the first that works".
7 comments
[ 2.1 ms ] story [ 24.8 ms ] threadThree papers on different approaches, getting sort of progressively further from classical planning as time goes on:
http://www.ai.sri.com/pubs/files/1364.pdf
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.106....
http://www.gamasutra.com/gdc2005/features/20050311/isla_01.s...
The last one is the direct inspiration for this library I assume, since it's the source of the term "behavior trees". I agree that many do have somewhat more complexity; for example, the 2nd link above is a reactive system with working memory, resolution of joint and dependent behaviors, etc. But game developers have tended to want to strip things down as bare-bones as possible, due to wanting: 1) minimal CPU usage; 2) a simple enough model that not-very-technical gameplay designers can specify a lot of the behaviors; and 3) something simple and deterministic enough that the engineers can predict and debug its behavior.
I mean ultimately, all AI is just a higher-level way of writing normal programs, because it compiles down to the same assembly code as everything else. It's just an issue of what you have to write explicitly, and what you get seemingly "for free". In many areas, the human wants to specify very little (say, a fitness function, or some planning operators plus a plan goal) and then get an automatic answer, but in areas like game-AI, the human wants to specify quite a bit more, but still wants some stuff for free.
So the difficult problem is coming up with a behavior-specification language, supported by a backend that implements it, that lets people specify exactly the parts of things like NPC behavior they want to specify, but then figures out how to apply them in various situations, resolve conflicts, enact them jointly, etc. NPC designers really do have a ton of specific things they have in mind for the NPC's behaviors and personality that they want to be able to encode somewhere, but they don't want to literally have to script every possible variation on every possible NPC interaction, since that blows up exponentially, especially with multiple NPCs and nonlinear storylines. Admittedly, behavior trees are fairly far towards the "you don't get much for free" end of the spectrum, even compared to other reactive planners.
http://chrishecker.com/My_Liner_Notes_for_Spore/Spore_Behavi...
http://aigamedev.com/insider/presentations/behavior-trees/#r...
http://books.google.ru/books?id=1OJ8EhvuPXAC&lpg=PA370&#...
and for people who prefer XML there is a simular architecture based on FSMs called XABSL,
http://www.xabsl.de/
which is used heavily among Robocup teams.