I just switched the AI in my game from a custom Utility system that I was using to using the built in Behavior Trees. I really like the system, think it’s easy to work with and very full featured. It’s working out great to call my actions.
I’m having trouble figuring out the best way to call the animations. This is AI for a cat, and we have a lot of animations and montages. One of our goals with this game was to really give the cats interesting behavior. So, there’s tons of animations and variations.
I’ve seen in the Strategy Game Example where they are called from code, and I had tried that way, but it meant everything needed to be done in code. So, I tried using the State machine in the AnimBlueprint so that the animations could get tweaked in a Blueprint giving access to the animator so he could get creative. For how I was doing it before, that would mean the task that the behavior called would switch a state enum on the controller that would get pushed to the Anim Blueprint.
What is the recommended design for calling the animations from the Behavior Tree?
We use a mixture of techniques for handling animation, some of which ties (nearly) directly to the Behavior Tree, while other parts are completely separate.
For basic animation sets (such as movement, for example), the Animation Blueprint handles transitions and blending based on velocity and other properties (mostly unrelated to behavior trees). Since we control movement speed at a high level (i.e. walk, run, sprint) from special “service” nodes in the behavior tree which we call “context overrides”, that then feeds into the blueprint and changes to the correct animation for the speed being used. (“Context override” nodes are just services that store a value when activated, change that value to a the “override” value, and then restore it when deactivated. It’s an easy way to have an entire subtree change a property while active and then restore it to the previous value when exiting.)
For certain types of reactions that aren’t really “behaviors” (such as hit reactions), they are handled as Anim Montages which are triggered separately from the behavior tree as well. The behavior tree doesn’t have to know about them at all. In some cases (like stuns), the behavior tree may be deactivated temporarily until the stun ends.
Most animations that the behavior tree triggers more directly are also montages (such as melee attacks). We use a system we call “special moves”, where a pawn can only have one special move active at a time. We start special moves through a special task in the behavior tree, and that in turn triggers the montage. Special moves are blueprintable, and they can handle any related game-state management. So they can set properties when they start and stop and can have events based on animation notifies or any other conditions you need to handle. Bundling that functionality will likely be better than having to do each piece individually in your behavior tree.
How best to break up animations between the animation blueprint itself and montages may vary based on what types of animations you expect to have and whether or not the game is networked, as well as how exactly the animation replication needs to match in real-time on all machines. Basic looping animations should generally be in the blueprint, while more specialized actions may be better in montages. We’re using specialized support (not in the engine currently) to replicate root-motion montages, for example, so we can have special attacks that look accurate on all machines. If you don’t have to worry about networking, the solutions are of course much simpler. Regardless, montages are a good way to handle animations playing “on top” of normal behaviors or which are one-off additional animations rather than making the blueprint too complex.
Thank you for the information.
In our case, it is not a networked game. I think you gave enough info I can figure out what will be best for us.