Awesome, thanks for the comprehensive reply! I’d figured out a lot of the process you described, but there were a few points there I wasn’t aware of, so I’m glad I asked . Thanks again for your help, when I’ve finished converting I’ll post some stuff about the other issues I’ve noticed. Kind regards,
One of the great things about other BT solutions is binding a blackboard variable in the graph to a field in a script. Is this possible with Behavior? I hope so, it looks like a really cool package.
How does it performance on mobile platforms? When 1000 objects randomly walk, what is the framework cost of com. unity. behavior itself, and will it generate a lot of GC?
It is important to note that blackboard variables are not individual UnityEngine.Object types (like MonoBehavior or ScriptableObject), so direct serialized reference to them is not possible. However, there are two alternative options available:
Shared Variables: You can make a blackboard variable “shared” which allows it to be shared across all instances of BlackboardReference. This means that any changes made to the variable will be reflected in all instances. (please refer to Create and manage variables and Blackboards for more detail)
CustomScriptableObject: You can create a custom ScriptableObject and generate a serialized asset (using the [CreateAssetMenu] attribute) . This asset can then be referenced by multiple Blackboards through a Blackboard Variable of that SO type. As a result, you can reference that single asset instance in a script and modify its values. (Keep in mind that ScriptableObjects are transient and reset every time they are loaded).
An example of this implementation can be seen in the EventChannel feature.
Hope this will answer your question. Please do let us know if you have other question or feedback
Thanks for adding Behavior graphs, I’ve been after a inbuilt solution like this for a while. I was able to install it by name in Unity 6000.0.19f1. It’s also still in the old project if I upgrade it to 6000.0.3f1. However, in a new 6000.0.3f1 project I’m unable to add it. Adding it by name gives the error in the image. If I try and copy it from the working project to the new project using packages-lock.json it just removes it on load. Are there some extra steps required to add it now that I’m missing?
Sorry but just to confirm, do you mean 6000.0.23f1?
You should be able to find it in the package manager and also install it by name with that version (I just did try with a new empty project and it worked on my side).
Thanks, I don’t know how I missed that. I noticed that a release version of Unity 6 was available so I installed the highest official release of 6 from Unity Hub which was 6000.0.3f. I didn’t even notice it was an older version than what I’d previously installed. Going to install 6000.0.23f1 from the Unity download archive now.
I stumbled across this completely by accident, but am so glad I did. I can’t believe that this isn’t being shouted about in the “What’s new in Unity 6” materials - this is amazing!
Seriously, Unity marketing focus so heavily on “graphic fidelity”, but it’s core tooling like this that I, as a hobby gamedev, have been really looking for in the platform.
I also absolutely love the enthusiasm that @ShaneeNishry and @MorganHoarauUnity are showing in this thread. It shows a real passion and pride in your work, and that’s so refreshing and heart warming to see! I hope Unity management take note and see how real community/end user engagement is done! Thank you for your hard work!
I’ve personally encountered many of the issues mentioned in the vid trying to use BTs. It is much easier to make modular BTs if you combine it with FSMs. I actually have my own BT/FSM implementation that does that.
Unity’s BT package has excellent visualization/debugging/blackboard support. It’d take me ages to reach the that level. It’d be really great if Unity could add FSM support to the package.
You can actually do a lot of that already. Just create an enum and put a restart node on top of a switch node and make your state choose when you change to a different one, it’ll work just the same as the diagram you posted.
I don’t have up to date measurements to show, but we did do a bunch of tests with ~5k game objects to make sure we weren’t causing memory allocations and performance was good. The main performance issues usually game from having many GameObjects animating together, not from Behavior.
That said, there are 2 things to keep in mind:
It’s been a while since we measured it, so we need to get back to it and try it again.
We want to make sure the package is as performant as possible and we have a performance cycle scheduled to look at what more improvements can be done and also start considering our DOTS and jobifying strategies more in-depth. There are limits to what GameObjects can do!
For now I’d recommend giving it a try and letting us know if you have any issues. We’re happy to help
The enum approach works but it requires you to have an enum for each state. This isn’t an issue for macro states like patrol /combat as those are usually predefined for a game. But it is an issue for micro states as the set for them varies for agent to agent. One enemy might have a jump attack and thrust attack. Others might have a jump attack and a ranged attack. It’s not feasible/scalable to have enum states for all of them.
BTs are good at sequential actions but have a lot of issues with interruption and switching behaviors. Transitions are much easier for FSMs. I’d prefer to have a proper FSM implementation rather than make BTs do what they’re bad at. Additionally, other systems, not just AI need FSMs. A proper FSM tool that has visual debuggers would be a great boon. We all know how shit mecanim is.
I understand, and yes definitely, you can do such things but at the end of the day it’s not an FSM. FSM has its own issues where you need to explicitly change to each state from each state and control that logic, which is one of the things Behavior Trees try to solve.
Unfortunately each tool has its tradeoffs. Perhaps we’ll find a way to bridge the gap in a later release. We’re happy to receive suggestions on this