I’ve gone back and forth on this quite a bit.
First, I used blueprints. I used the perception system to have the AI follow a detected player. After doing some research, I learned about the behavior trees and decided to give them a shot.
So, my first venture into behavior trees … did not go well. I didn’t understand decorators very well and it seemed more suited for simple behavior than the complex behavior I was attempting to create. So I went back to blueprints.
I created a massive blueprint to handle all sorts of scenarios. What to do if the AI is idle, how to handle seeing the player, hearing the player, whether it should run from multiple players, EQS queries to handle movement paths and I used “Add Movement” nodes to move the AI instead of “Move-To” so that I could smoothly update targets and the rotation wouldn’t look weird. It worked great … in single player. In multiplayer, the process was not smooth. I needed everything to execute on the server and the number of branches I used, checking perception and ensuring the path was valid along with using the “Add Movement” made for a very jittery/janky experience. So I took another look at behavior trees.
Turns out, you can configure these trees much better than what I had first thought. And using services seems to handle repeated calculations much better than navigating through a blueprint on every tick. They appear to have done some pretty nice optimizations on how those are processed. It did take a bit of work to get it to do the same thing my blueprint did with some wonky bits in there to handle odd situations (like re-starting a composite node to re-calculate a path before re-executing a “move to”) but so far so good. And it runs much smoother. And it looks much cleaner than my event graph.
I’d say behavior trees are definitely worth using.