Complex AI Performance & Visual Programming with Fluid BT

[ashfidable]

I just want to say, this is amazing behavior tree implementation! I am using it for small games now and it's working great.

Been finding a free tool like this from a long time - few are bloated and few are just lacking. This one is right on point. So, thank you!

I do have few questions, I am doing FSM mixed with BT and it's great. I want to ask about the performance in general and talking about scriptable objects implementation based on this.

Do we have a performance test on this with heavy AI?
Is it possible to turn little sequences and actions into separate scriptable objects? I am guessing the TaskStatus returns for each object and cannot be shared via scriptable object - so I am not really sure.

[ashblue]

Thank you very much for the kind words ^_^ I'll try to address your questions as best I can below.

Performance
Compared to popular solutions on the Asset Store Fluid BT is lightning fast. There are no visual objects that need to be digested, so the initial builds are crazy quick. When restoring ticks it only ticks the immediately necessary parent and resets insta nuke the parent nodes. I've run a large number of AIs on the screen with various game projects and never noticed any performance issues. State machine logic is mostly flat so it should have zero overhead on state transitions.

Unless you're going 300+ nested nodes deep I wouldn't really worry about this sorta thing. That said, I haven't written a performance test scene with an insane number of AIs.

ScriptableObject(s)
Fluid is really designed to be a coding first solution. So it doesn't support visual programming with ScriptableObject(s) (SOs). The architecture "could" support SOs, but there are already solutions out there like Behavior Designer that do this kinda thing better than I ever could.

If you really wanted to, you could overhaul the architecture to eat SOs and generate a tree. You'd just need to crate a custom tree builder that runs on SOs. All the code is data driven architecture so anything is possible.

I mostly created Fluid BT because I noticed solutions like Behavior Designer were struggling to scale with large projects. Specifically when having to edit a lot of logic to overhaul my AI systems. From my experience visual programming AI systems can start to break down in game dev when you need to do massive refactors on the code base.

[ashfidable]

300+ nodes deep? Oh I am not even near 30 haha. This is seriously amazing to know!

Talking about scriptable objects, how would that work? I understand it's code-driven (I love that fact about this Btree) but scriptable objects are usually shared unless you create a runtime instance of it (which totally is not cool thing to do haha at least to me)
I love the btree viewer but I think if we don't have the builder pattern for scriptable objects, we can actually change the architecture to SO based then yes? The reason I want to do this is because few of my designers wants to drag and drop actions and sequences (they hate the visual graph that most of btrees provide to make their tree)

[ashblue]

Yeah, the library is absurdly performant for most people's needs. If you splice a ton of ultra complex trees together you might have problems, but I haven't heard of anyone doing that.

You could have SO(s) with parent child relationships and a root node to start. Then just walk through the SOs and convert them to the corresponding node type. Remember all nodes are either ITask or ITaskParent.

ScriptableObject(s) could just be converted to an ITask/ITaskParent type so you could inject them directly into the tree.

The above said, it's still a lot of work to do this as you'd have to architect a new tree and write wrappers around the existing tasks and parent nodes. I'd personally go the Behavior Designer (BD) route, as it's super well documented for non-technical people. Also, I've spoken with the creator on several occasions, submitted patches to BD, and he's a super solid guy. BD is great for teams who have a designer without coding skills who needs to work on BTs.

If you do give a Fluid BT visual scripting library a go, please let me know how it turns out. I've thought about doing this sorta thing as a prototype, but just haven't found the time.

[ashfidable]

This is actually wonderful to know that all these are actually possible to do. I really can't thank you enough for this haha. I will have to try the conversion to ScriptableObjects and touch the visual scripting part later. Because my designers really love the drag and drop thing than a graph.

I wanted to buy BD for a long time, but it's too expensive when it comes to designer's choice (Designers are really not sure if they want to use or not). We had our engine before and I had graph editor built for them but after a while, they were just confused on connections (I am probably sure it's my fault due to poor choice of UI for graph). However, I showed them the build pattern for this behavior tree (+ few custom action nodes using BehaviorTreeBuilder) and it was just instant understanding of the flow for them. I am not really keen on Scriptable Objects architecture, but its handy when you can change behaviors on fly.