The other functionalities are quite similar to Unity, such as detecting input, physics interaction, raycasting, etc. but all these behavior trees and blackboards seem quite cumbersome and extra work to me and i would personally prefer implementing the AI behavior “manually” from the source code in the Tick() function, as I was used to in Unity.
In short, in Unity I had a structure similar to this: I had a class called EntityBase, which implemented 2 major methods: UpdateBackground() and virtual UpdateBehavior() { }. Unity’s Update function (equivalent to the Tick() in UE4) would call the UpdateBehavior, which would store some important values, and then call the UpdateBackground() which would use these values to control things like movement, cast spells, etc. Note that the UpdateBehavior was declared virtual, with an empty implementation. If i wanted to create a new NPC, I would just extend EntityBase and override UpdateBehavior(), where I would implement the specific behavior for the new NPC.
I would like to do the exact same thing in UE4, but are there any advantages to using behavior trees and blackboards over hardcoding behaviors in c++?
Apart from it looking “pretty” and friendly for those who have no programming experience, eg. presenting the behavior to the art team or a potential investor or w/e, I don’t see an advantage of using them. Thanks in advance for any answers
Do it your way if that’s what your comfortable with. If you can’t see the advantages of Behavior Tree’s and the provide system there is no reason for you to use them.
In one of my projects I made a “Utility System”. But it is not called on every tick. It is ticked once to get the next behavior to execute. Interrupting events can call it to get one to switch to if it’s in a Behavior. There is no “hard coding” though. The behaviors themselves are components and any of the entities can be assigned them and weights through the editor.
With the addition of the EQS system the given Behavior Tree system is very robust. Yes, you have some overhead to learn the system that somebody else made, but once done it’s flexible and will perform well. “Hardcoding” behaviors is very brittle in my opinion, but if it’s a tiny project with only you as a developer there’s no harm in it. If there were other people though, and they started suggesting changes to the behaviors and you were reluctant to change it because it was already coded then you would have a problem.
It’s best to learn these things by doing them, not by hearing someone else’s opinion. Do it your way first, you’ll learn more.
For prototyping Behavior Trees are cool because of the runtime visual debugging functionalities, i.e. you can see which branch is active.
By the way, I am using a hard coded behavior tree at the moment, similar to what you described, because of better performance, and because I do not use the UE4 navmesh pathfinder. It has been designed and written due to behavior tree rules, thanks to my good experiments with UE4 BT testing. I replaced my earlier hierarchical state machine with the C++ BT system because I found it much better…
But in my case it is an RTS game, where the units are actors (not pawns or characters), and only have to move to places where their owning group actor is sending them (which will run also a hard coded BT based on potential fields in future). If you need more independent and intelligent human like behavior, imo it is faster to develop and fine tune with BT, then you can convert to C++ relatively easily if better performance is needed. I personally drew a BT sketch before implementing it in C++ (using root, decorator, selector, sequence, task and event functions).
I have no experience with the EQ system, because I use my own custom pathfinder, so I have an integrated system, no need to have two, one for pathfinding (navmesh) and another for realizing environmental effects… But in case of 1st or 3rd person games I would definitely use the UE4 BT and EQ system.
