The first thing I always suggest to everyone, is to avoid creating behaviour trees with a lot of low-level actions (like the ones included) and instead either:
1) Create high-level actions to use, or…
2) Create your code functions as you normally would and use Script Control tasks to call these functions you’ve already implemented, or…
3) Create reusable Behaviour Tree assets for use as SubTrees.
In all of the above cases, (custom actions, implemented functions, SubTrees) these should ideally implement high-level functionality and we should be using the agent’s root Behaviour Tree to design *when* these happen, rather than *what* happens. If GoTo is part of all “interactions” for example, then ideally GoTo should not be a different action, but rather part of these high-level nodes.
It is also generally a very good idea to have an FSM as the root system (instead of a Dynamic Sequencer), if having different and definitely distinctive states for the agent does indeed makes sense.
This is of course generally a very open subject and heavily relies on what the game is and the agent needs to do, but I hope the above pointers help somehow. If you want to elaborate on any of the above, or more specifically to some of your questions, let me know some more details about each subject and maybe what type of game it is that you are making, and I will do my best to help further.
What do you mean by “generalize” behaviours for example a bit more specifically by the way?
Once again, the main rule of thumb (at least for me), is to design the trees for *when* stuff happens, not for *what* or *how* they do 🙂
Gavalakis
