[Official Unity Post] New Demo for Behavior Package is released!

Learn Content
, , ,
1

We are thrilled to announce the release of a new demo for the Unity Behavior package! :tada:

What is Behavior?

Unity Behavior empowers developers to control NPCs and objects, orchestrate cinematic scenes, trigger events, and adapt to player actions. Rather than relying solely on traditional behavior trees, which can become complex and lead to redundant evaluations, Unity Behavior combines the best of behavior trees and state machines. This hybrid approach creates more efficient and readable behavior graphs.

What’s Inside the Demo?

In this demo, you’ll find a rich array of features designed to showcase different use cases for the package:

  • Comprehensive Assets: Including 3D models, UI components, and audio elements.
  • Example Scenarios: Playable scenes illustrating various AI behaviors and interactions.
  • Behavior Graphs: Examples of game and character state machines as well as behavior trees.
  • Subgraphs: Modular behavior logic with static and dynamic subgraphs.
  • Blackboard Assets: Demonstrating shared global and interface variables for cohesive management.
  • Custom Nodes: Showcasing integration with other systems and versatile behavior creation.
  • C# Binding: Integration examples of behavior graphs with scripts.

These features are combined into a small project to provide an intuitive demo for developers seeking ideas on how to create their own graphs and game logic.

Why Choose Unity Behavior?

Behavior is a new Unity package that stands out with its visual, node-based system, making behavior authoring clear and manageable. The tool’s human-readable nodes and debug-friendly flow graphs ensure that creating and understanding artificial intelligences (AI) behavior is straightforward.

Behavior package is free and compatible with Unity 6000.0.16f1 or later.

Get Started

You can find the demo on the Asset Store.

image (3)
image (3)1920Ă—1080 118 KB

Dive into the new demo to explore how Unity Behavior can transform your AI development workflow. For more information, visit our official documentation and join the conversation on our Discussions page.
To learn more, watch our introductory webinar.

10 Likes
2

Oh, thanks a lot! That’s exactly what I needed!

1 Like
3

Ayye, awesome! This seems like a great way to dive deeper and learn more about the behavior package first hand.

Thanks for releasing this, excited to try this out! :+1:

1 Like
4

I have a question to the team behind this demo.

Considering that Behavior Package is a relatively young tool, working on this demo, did you caught yourself thinking that there is something you would change or implement?

What was your experience as a user of the package?
Thanks!

5

Hi mishakozlov74,

I haven’t forgot about this but didn’t had time to prepare an answer yet. For context we were 2 developers working on the project (an engineer and a tech artist).

I’ve already gathered the tech artist feedback and will make a proper sum up later this week (hopefully I’ll have time :sweat_smile:)

Thanks for your interest!

1 Like
6

Hi @mishakozlov74!

Sorry for the big delay, I ended up getting sick last week and had a few important matter to handle this week :sweat_smile:

Thanks again for reaching out.

My experience with the package is a bit unique and maybe a little biased since the demo was actively dogfooding the tool while it was being developed. The goal was also to ensure expected behavior creation methodology would work while seeking new use cases. So I had the advantage (and sometimes the challenge) of using it with a fresh perspective, trying not to make assumptions based on other approaches like FSM or BT.

Some features, like the EventChannel, quickly showed a lot of potential but can easily be overused. Others, such as RunSubgraph (Static/Dynamic), were a bit trickier to figure out use cases for. The demo actively helped refine these features (though there’s still some WIP).

One thing I learned was to think carefully about what the graph should handle. There are some limitations, like how it’s not practical to try to manipulate data in graph versus orchestrating a sequence of actions. Viewing the tool as a high-level event graph was the most valuable approach for designing these graphs. Of course, since the demo had to showcase a variety of use cases, I did create examples where the graph manipulated data (like the combo system or game mode timer), but I kept these tasks relatively simple.

There are a few features I’d love to see added:

  • More generic nodes for data manipulation (like a generic foreach, list accessors)
  • More control over the graph’s appearance (areas, markdown support for notes)
  • An option to “mute” a node to ignore it in a non-destructive way
  • An invert condition toggle

And a few frustrations I encountered:

  • It’s not possible to create generic nodes with dynamic inspectors (like the SetVariableValue node)
  • There’s almost no control over the lifecycle of behavior agents

In the end, I really believe that the package opens up the ability to create and design behaviors in a way that’s accessible to non-coders. It provides a robust framework for creating game behaviors, orchestrating sequences of actions, or even just triggering events. I also believe it has the potential to become a new foundation for developers, similar to DOTS or UITK, where users and asset store publishers can build specialized frameworks on top of.

I’d especially love to collaborate with other teams, like Input, Networking, Graphics, XR, etc., to bridges more system together while making them more accessible to everyone.

Hope this gives you a good perspective :slightly_smiling_face:
Don’t hesitate if you have more specific question!

3 Likes
7

Hey @MorganHoarauUnity! Thanks for such a detailed answer! Hope you’re feeling well :slight_smile:

I had exactly the same feeling about EventChannel, though the demo helped me finally understand what it should look like. Your examples indeed are very helpful.

Reading your feedback, I suddenly realised that the abstraction level I should maintain for actions is the most obscure part of the tool usage for me.

Don’t you think that data manipulation nodes, such as foreach loop, would blur the border between designing behavior and visual scripting? I actually needed something similar in one of my behaviours and I added such node, but I was sure from the beginning that I am doing it wrong.

The rest of features you’d love to see make a lot of sense to me!

If I may, I’d like to ask why you were trying to avoid assumptions based on FSM? I thought that usually using FSM for decision making and BT for their implementation is a nice combo.

Moreover, I thought that switch node + event channel in your demo is essentially the same concept, isn’t it?

8

This is also an area I’ve been pondering about for a while. During on of the first iteration of the demo, I’ve been trying to make the whole health component using Graph only. However, seeing how much space and time trying to manipulate a simple float could be in a graph and how hard it could be to emit the changes to other systems, I quickly backtracked.

I still ended up using a for loop for the B_GameMode_StateMachine countdown or the B_Attack_Combo/Chain looping using very simple data manipulation.

I’ve ended up considering the balance between iteration speed and how much a system is isolated from other feature.

Maths and logic flow nodes can definitely blur the lines, yet I believe that a minimal amount is still essential to give enough control to users. But unlike traditional visual scripting tools, Behavior is designed to control high-level events and efficiently handle simple tasks.

The tool is coming with some limitation compared to it’s counterparts (No proper FSM flow with explicit transition, lots of built-in nodes don’t work well with BT approach…).
It’s easy to use a single approach you know well to solve all the problem and a lot of users (even internally) were often doing exactly that. But that cuts you from the benefit of other approaches and finding meaningful use cases for each was my job. The FSM-BT hybrid approach has essentially been validated during the demo.

Side note: since, a lot of users have came with very good reasons to use a singular approach and so in the future I’d like to provide a better integration of each so those familiar with them can have a better time onboarding on the tool.

Thanks again for interest :slightly_smiling_face:

1 Like
9

Many feature that should be added might be benefit by opensource this package and allow contribution from github

10

Thanks for your answers (and the demo, of course), it’s very helpful!

1 Like