Is there any reason in particular to use behaviour trees over regular blueprint scripting for more or less simple AI? For example- following an AI tutorial that makes them move to random waypoints, it requires you to make loads of blueprints, setting blackboard keys, events, checking conditions etc. However, you can achieve the same exact functionality by simply getting all actors of the waypoint class, and using the AI move to node in the character blueprint to pick a random one, and move to it. I also have shooting functionality on seeing a pawn- this too is as simple as having a pawn sensing component, and on seeing an enemy, I call the necessary attack functions. Ideally I’d like to use EQS to find the best enemy and best waypoints etc., but is there a way to keep the simple regular scripting but still have the power of EQS?
Well if your plan is use scripts to simply your workload, then EQS is doing line traces with 3d math. You can do most of this on your own by creating logic as you have. For example, a trace for you, if you’re visible, weighing on where you currently facing to decide the best choice. Getting all actors off a class, or sphere tracing in a grid format returning actors to be tested if they’re your enemy. This is all easily made accessible by EQS.
You could definitely do it yourself, just depends what you’re trying to do.
There is a Line of Sight function available too.
Would there be a way to only run the EQS system in the behaviour tree, and then get the results in the character blueprint which would set the enemy target/waypoint location etc? I love how the EQS system works- the weighting of values etc is all super nice and easy, but it seems the setup of a simple enough behaviour tree is far more work and clutter than doing it in the character itself- are there benefits to doing all the logic in the behaviour tree (ignoring the obvious- for very complex decision making AI’s etc). All I want my AI’s to do is move to random waypoints, and on seeing an enemy, attack until dead, then resume moving to random waypoints. This is all currently setup in my character using a very small amount of nodes (doing the equivalent with behaviour tree tasks/decorators is a much longer and more error prone method I have found).
I suppose if you only used the BT to run EQS queries then you still achieve that responsive behavior you want. What I would suggest is just creating a really small tree which runs EQS Query, and have a service which constantly checks for the value to be set then report it back to the Controlled Pawn.
I also would suggest watching my stream on EQS & AI Perception. I do cover making a behavior tree, and I explained it well enough for most people to understand the advantages of using a tree. While you may not use a tree because what you explain is pretty straight forward, I do have to say the BT is not as complex as it seems. I run into a problem even on the stream, where I need 1 set of logic to always run and another set to independently run within the same tree. The solution was a Sequence Tree, first child which always needs to run is also a Sequence. This was choose because if it was a Selector, and we know this logic will return Success, the Selector will return fail. Resulting in the Sequence succeeding, and the rest of the children not being called. So the next child is a Selector in the Sequence tree. This was choose because it will return false when it child’s Succeed. At least that is the behavior we want. Because the children will be sequence nodes, so we want to know our sequence ran successfully depending on which tree was appropriate.
This ensured 1 set of logic always ran, while at least 1 of the other 2 are expected to fail.
Now in your case I could create a simple sequence tree which runs one EQS query for me, and achieve similar results. I would just need to make a system to attack once the bot found his target. Additionally I used a sensing component to immediately update of our target
Here is the demo project. (Enable EQS in Experimental Settings before Use)
The stream if you’re interested
Awesome, thanks so much for the thorough explanation! I actually was working from your older AI tutorial- will check the new one now- the perception/EQS new features seem to cut out a lot of the older work that had to be done!
I also think the BT is far too convoluted, it has too many components you have to string together and then jump back and forth between multiple windows to get anything done.
All the AI components should be store in the AI controller, just like variables and components are nicely stored in a blue print.
Working in BT is like trying to learn a whole new application.
I also think the BT is far too convoluted, it has too many components you have to string together and then jump back and forth between multiple windows to get anything done.
All the AI components should be store in the AI controller, just like variables and components are nicely stored in a blue print.
Working in BT is like trying to learn a whole new application.