First of all, this is actually a great standalone package! The core logic nodes are there and with custom nodes, we can design whatever we want. So kudos to the Behavior team for that.
I have some questions in regards to performance. Is the tick rate of the graph bound to the Update loop and can it be changed? Use case is to save performance by lowering the update rate of the entire graph rather than execute every frame for agents that do not need fast response times. And for multiplayer context, bind the graph’s tick rate to the network server tick rate. I’ve checked the docs and it doesn’t seem to be mentioned there unless I missed it.
I’ve also checked the dependencies and it doesn’t seem to depend on anything from the DOTS stack. Are there any plans for a DOTS compatible version in the future? I feel like something like this should run in Jobs and be Bursted to get more performance, especially since graph logic runs multiple times per second. For instance, Opsive is planning a DOTS version of their Behavior Designer.
Anyways, I would like to reiterate that this package is good. I hope it gains traction and gets more features along the road.
Hey, Congratz on the 1.0 release! I hope we see more adoption.
I would also strongly second what saskenergy said about utalizing DOTS (I didn’t realize it wasn’t already). I could easily see performance being a bottleneck that prevents wide adoption. I think for agent behaviors it is especially critical so that a large number can be in a scene at once without tanking performance.
Additionally, it would be super cool if you were able to suport Entities in the future, though I understand that would be difficult. But Entities is such a great use-case for it because who wouldn’t want a lot of agents roaming around your scene!
Utalizing Burst should be (relatively) low hanging fruit. But I imagine if you want to really utilize Jobs it will require a 2.0 version. But I really hope now that you have the 1.0 out you can get more people using it and also get some nice performance improvements (I haven’t tested, so I am not saying the performance is bad now, but could be several times faster potentiually if using DOTS)
Yes, at the moment we don’t have DOTS support and it is relying on Update(). We do have plans for performance improvements, including variable update frequency and we’re looking into a viable way to make it DOTS/jobs friendly while keeping the high flexibility we offer with the package. It’s not an easy one, but it’s definitely on our minds!
Behavior never needed a Muse subscription, even when it was called “Muse Behavior”. You can make your own graphs and custom nodes and simply implement the C# interface that’s created for you! If your graphs aren’t working, please please a thread with the Behavior tag and a repro or video and we’ll look into it! I’m sorry you’re having difficulty with our package
Note, you can still use the generative / muse features if you add Muse Common via the package manager. At least it’s more clear this is 100% optional and the package can stand on its own legs now as the feature it is. I believe it brings a lot to the table and I hope it proves itself
the editor is based on GraphView, correct? If so, does this include any improvements to it and should we even be looking forward to “GraphTools Foundation” going forward anytime soon?
Just to note that now that Muse Behavior has changed to simply “Behavior”, the tag “Behavior” here, in Unity Discussions, results in posts about this package not being correctly differentiated from many others that contain that generic tag, such as many AI posts that are being identified with the name “Behavior”.
Amusing… This could be like the most impressive package addon to use… yet there is nothing absolutely nothing suggest that at all… what am I missing, no showcase no demo’s?
Is there any plans to allow horizontal-flow for value types that could be tied to “ports”? Similar to VisualScripting, retaining the current way of declaring Variables through “slots” in the text, but with a context option to move the “slot” to a port, so you can manually choose to expose a “Value Port” to feed values from basic math operations, or exposing nodes for Type properties/fields (at least getters) for CustomTypes or MonoBehaviour/Scriptable types? It seems currently you cannot make basic operations without a custom Node.
I understand this is supposed to be more of a high-level behaviour tree, so it might not fit the design goals. But i believe this kind of util might help make it much more flexible.
We would be interested to hear about your use cases and your needs in this respect. At the moment, it is possible to make a simple state machine using an enumeration along with a Switch node. It’s basic but using a second Switch node and buffering the Current and Previous states, I believe you should be able to reproduce a “state enter/exit” behavior. For the “state update”, you would need a third switch along with the OnStart on repeat.
(And I cannot give you more information in regards to GraphView, sorry )
If I could design such a graph visually and write all the nodes (conditions, actions) for a graph that Unity provides, this would be great to have for an asset. I’d love to move in that direction but I can’t depend on existing paid assets and developing a graph myself is very time consuming.
FYI the above graph is generated from the C# statemachine definition which is less than 200 lines of code, and I then generate this plantuml graph from the existing machine. I’d love to flip this around.
Hey @CodeSmile , I think that’s very doable with an enum switch and a Restart node. You can use the Set Variable node to change the states accordingly. Let us know how you get along with this and if you need help
)
) that we are currently investigating the addition of Math operation nodes.
