I was wondering if I should explore a way to use the Behavior Trees & CO to put in place my game states and transitions.
I know they should be devoted to the AI Controllers and Actors but they also seem perfect for this other purpose.
Is it worth a try or should I keep it simple and just Blueprint my game states and transitions ?
Thanks for your advice.
BTW I couldn’t find any posts regarding this request although it was mentioned somewhere that someone did something like that.
Sorry after reading my post I realized it was too vague and unclear.
My casual game will have a 3d UI (no widgets) to stick with my theme.
I was wondering if it could be a good idea to use a Behavior Tree and CO to manage the composition, transitions and animations of my 3d UI interface. It would be responsible to animate the transitions between screens (actually removing in a nice way the 3d objects off the screen and showing the new ones for the new screen - might not be a problem if the Level is the same during the whole game as it is a little game).
The benefits I’m seeing, maybe wrongly, are :
Confine the UI Navigation States and Transitions in the Behavior Tree & CO
Execute multiple actions at the same time and switch to other tasks when they are all terminated without having to code that in a complex way (ie.checking if multiple timers ended)
Less consuming in term of resources - Behavior trees are less resourceful as they aren’t refreshed every frames (which suits perfectly my needs)
Avoid Blueprint complexity (spaghetti) like setting UI States based on the execution of multiple Animation Graphs and other timer completion checks… Behavior trees are graphically talkative.
The Cons…
Will Behavior trees be really helpful for this specific application ?
– Quick ? will I gain time in doing so (I don’t master them at all and will have too - well, at least the basics to suite my needs)
– Useful ? will it be easy to add/remove animation effects on screen transitions to incorporate new objects for example ?
– Spaghetti ? will I really gain in readability or will I still eat Italian food ?
I played with this idea a bit. It is trade off.
easier to make multiple branching algorithm, code that has a lot ifs and thens or case of is much better and smaller
but connecting all that you your game is bloated and mess.
However you can make some nice and tidy library of services (for behavior tree) and then use that all
I did that around 4.7 so probably now behavior trees are much more polished.
ps. running behavioral tree out of blueprint is a bit clunky, also was asynchronus/ran separate from blueprints.
I have played around with the Behavior Tree and I think I won’t use them. I will create a BP Screen Manager Class to manage the screens. This class will communicate with the 3d UI elements. 3d UI elements will derive from a base class implementing functions or interfaces and hence manage their visual life cycle as autonomous entities when requested. This should spare me the Italian food syndrome.
Behavior Trees could have been fine but there are too many dependencies inherent to their use.
Here is a small glance at my test sample. I think I can do better and cleaner with BPs.
In my opinion Epic should make Behavior Tree a bit more generic. It would be great to be able to use their power in other contexts than AI without having to struggle with their dependencies.
You don’t need a BT to manage Game States, because 1) there isn’t that many states to manage; 2) Game State is controlled directly by the Player(s). But, I can see where a BT Flow Graph Editor being useful for organizing the flow of execution. You can sort of hack that with standard BP by straightening BP node connection wires. That Logic Flow System is very nice. I sort of hacked one using AnimBPs incorporating Logic Vars and sometimes dummy Skeletal Meshes & dummy Animation Sequences for Timers.
