From what I can tell BT isn’t really making things better than having one or two switch case inside a blueprint. In BT my logic is now being spread across several BTT that are having to interface with a blackboard which enables the BT to do things. When I’m looking at the BT I can’t easily adjust my logic. I have to go into a BTT to adjust logic and then jump to BT and mess with the logic and then set variables in blackboard that will be adjusted in the BTT or the controller.
This doesn’t seem better. It just feels different. Maybe if I was recycling a lot of my logic I could use this but my logic isn’t going to be reused anywhere else. Sticking on a bunch of decorators that have partial control over the logic while having a BTT controlling some of the logic just seems silly.
Swapping between a lot of menus is not an intuitive way to work but it seems to be what I have to do when I use behavior trees.
I’m not saying you can’t do good things with this. I do like the real time visual representation you see with the BT. Despite this, it seems like a heavy time investment that ultimately leads to a loss in productivity. If the BT was just the BT by itself it would be great but it isn’t and it can’t be.
The system is more of a “visualizer” just like the widget editor, the state machine editor in animation blueprints etc… In the end it’s just a wrap around c++ functionality producing a big bloated binary file. What’s not to love . These editors exist because not everyone is a programmer (sadly) to get a bigger target audience. The only editors I think really add something are the ones for 3D animation but that’s another story. Behavior trees? not so much. It is definitely just a fancy switch. Not even that reusable unless you dynamically load one BT into another which feels hacky. Edit If only we had a text based source file we could hook into any external visualizer, not the visualizer acting as the source file which is more often the case XD.
I can see it being useful in a team setting where the BTT and blackboard parameters are setup and ready and you are tasking a technical artist with developing behavior. But a smaller team or solo developer it does feel cumbersome.
But I do feel better about building behavior with blueprints having tinkered with BT. That my solutions for dealing with time based events are the way to go.
I also found the included BT system to be cumbersome and I wrote my own boolean ‘task switching’ system because that ended up being easier to understand. My system works, but in the long term I’m maintaining more code. If I link with other developers, they are likely going to be familiar with the included BT system and learning this custom system may be cumbersome. My project is still early, so maybe I’ll force myself to use BT just to reduce technical debt.