Thank you, for the link, this is what I’m looking for.
Gave this a try yesterday, and it looks super promising! And definitely a better UX and feel compared to things on the asset store so far. I really want to use this! 
I had a few questions when trying to move over my simple trees I made from Behavior Designer over to this
- In Behavior designer, I have these ‘abort types’ on the nodes. If the conditional ‘Can use Ability’ ever returns true, it will abort those further down the tree.
The closest thing I was able to find to replicate this, was to kinda ‘inverse’ this, and have the abort type on the last node
is this the best way?
-
Are there more complex examples available somewhere? The sample doesn’t seem to give much depth, and doesn’t feel super realistic.
-
Similar to the above, I’m able to ‘abort’ higher up in the tree if some kind of event happens. It seems I’m able to use
tree.Restart()in code to do a similar effect I want here. Which is good, since I couldn’t find an immediately obvious way to trigger graph events from code? How would you approach that?
Thanks for the work on this, I have no idea why this hasn’t gotten more coverage! CodeMonkey where are you! 
total game changer!
One last thing while I was testing, this behavior was unexpected to me. I would’ve thought the ‘abort if’ node would abort its children as well. But it doesn’t seem to?
Sorry if I’m missing some docs, i think i’ve read them all but might be missing something 
That is good to hear about the performance, as I will be using 200-400 agents at a time, non ECS for now.
Anything to keep in mind? Previously I was using a tick manager to control which agents ran and have them offset frame since I didn’t need them doing things EVERY frame, especially if they’re waiting for an animation or something.
Thoughts, or is that just overkill?
Hi Donurks,
We did find a regression / bug with components.
This will be fixed in the next release, we are testing the fixes right now.
Thanks for reporting!
2 Likes
With that amount of agents, I would try without first, and check if you need to optimise later.
I don’t believe the behavior package should cause any slowdown at this scale.
@Darren_Kelly What do you think about using this behaviour tree to create Dialogue system? Could it be a good idea?
I think that should be doable yes, and not a bad idea!
@Darren_Kelly Is there any way to create customized Blackboard variables for the Unity localization package and getting a function like the OnValidate for the behaviour graph?
Thanks! The image showed me the answer: you use a blackboard.
BB is common but in my experience across both engines, you end up spending a lot of time abstracting and that’s not very Unity-like.
A much nicher and easier alternative can be seen Panda BT. All it does is execute user code that reside in attached mono. The user code is responsible for world state peek/poking and the BT is only an execution controller. This is extremely good because that’s how the rest of unity functions so you don’t need to shuffle various ways of thinking, it’s also less abstract so you don’t waste as much time.
Now, Panda uses reflection, which isn’t ideal in hot path but most of the time BT executes things at a low frequency and in my experience, the gain in usability far outweight the slight loss in perf. Also BT code usually spends copious amount of time in world queries using physics or navmesh samples and this far outweights (also) the loss in reflection.
Finally the biggest advantage of Panda is how terse node code is. There is near zero scaffolding, in contrast, the current direction you’re aiming for is excruciatingly verbose with half the code i’ve seen being scaffolding because EACH NODE needs its own class.
You need to think in terms of Unity production: iteration time is the most important, not performance, and most of the time we keep the prototyping code and release, only optimizing hot path.
To that end, I recommend you take a look at uNode which allows both reflected and hard coded nodes.
To summarize: less abstraction, less layers of thinking, terser node code, keeping BB for those coming from Unreal and keep the hard coding for hot path or mobile.