I was thinking maybe we could have some kind of open talk about blueprint functions and execution times when it comes to AI, both behaviour trees, as well as home made solutions and problems people have encountered.
I think there are some basic points that are important that can be cover in much or little detail.
Getting Knowledge of the world.
This is a big area, this is everything from querying the basic state of the physical representation to the world, to find other relevant actors.
Acting on said Knowledge.
Based on a pile of logic, the knowledge above will boil down to an action or set of actions for the ai to execute.
As for getting knownledge of the world, UE have a big set of functions that one can use, You can attach shapes that will report intersect events of actors or components as a event call to the actor.
You can do intersect queries on your own, for components or actors giving you a set of actors to loop trough or just figure out if there is a relevant one.
There are even senses you can simply attach to a actor that can feed back vision and detection.
When it comes to acting on knowledge the possibilites are even larger.
Quering distances and dot products between visions and positions, line traces and even more interesectiosn based on data.
The hard question is to know what functions give the best performance for a given task.
When it comes to complex logic for a complex actions Behavior trees are a really good idea, more flexibles and more shared data between steps then a Finite State Machine.
When it comes to really simple logic, it could be that you just need the physics engine and intersections. Or simply need to know all the positions of objects, to figure out if they are close enough or not.
One will not by a quick or even maybe a more thoughtful glance, say that function X will be better then function Y using Unreal Engines implementation.
I for instance have a case where I need to know if any of my dynamic actor types are with in range when trying to perform an action.
Here we have a see of options, do we have a sensor as big as the area we want to query and add to a integer when some one steps in, and remove when some one leaves.
Performance wise that is kind of ok, the physx is optimized to handle these types of events and we don’t need to write our own logic, other then the value +1 and value -1. This requires one additional problem based on implementation, we need to filter out our sensor area for other actors when they query about us. That we know everything within a sphere of radius 128, that doesn’t mean we occupy a sphere of 128. Additional logic and flags need to be set.
Another option then is to have a Intersect call, that can take either a shape you declared, or define a shape trough blueprint, this will give you a list of all actors, checking the size and if it is zero would give you information if anyone is in range, and return true false. The problem here is that you need to provide logic to prevent this call to be run each frame, doing a query against all actors in range every frame can cost a lot of performance, but it is quite easy to use and could be cheaper if the queries can be do less often, 3 times per second instead of per frame. This is my current solution since it is fast, but I do already notice performance issues with around 2000 actors, that being said, it is in editor and the queries are running every frame.
The third option is a AI Manager of sorts, it will hold reference to all relevant actors and their position, so we do not query the world, we query the manager.
To this we add some optimized functions so that the manager can sort and handle the data and feed it back quickly.
For instance, all ais are stored in cube sectors, upon query we simply calculate what sectors the query will cover, and loop trough the content of these sectors. Some simple math will quickly filters out all actors that are to far away, one could even stop the check as soon as one ai is encoutered since that is all it takes. Draw back here is loss of speed, and actually constructing the manager, and makeing sure that the sorting of the data takes more performance then just query all the data. Resorting the data on actor movmenent is also an issue, but could in my case give an insane performance bonus, but it could give a false positive speed results.
Remember to consider the worst case and not the best case when doing these things. Otherwise you might get sudden unexplained slowdown and wierd behaviour due to the search actually require to go trough all actors.