Blackboard gives no option of creating List<YourCustomScript>

[NixonAroboX]

From what I have seen, in the Behavior Graph there is no way of creating a List of a specific Type beside the presets on the blackboard.
E.g. Any ScriptableObject. Workaround would be to reference a Class that has that custom List inside.
Am I missing something?

[LauraRantonen]

Hi @NixonAroboX !

Your understanding is correct - we’re currently only supporting basic types for list variables created through the Blackboard menu. We would definitely like to extend the selection of types that can be used for lists (including custom types as well), but haven’t gotten there yet due to other priorities. Hopefully soon!

[wyattwilson]

I was searching for the same functionality when I found this. The behavior graph package is so close, but just a few missing features like this are really limiting.

[NixonAroboX]

It’s nothing that’s too bad, just create a bootstrapper class where you store your custom lists and arrays. You just reference the bootstrapper in the blackboard and you’re fine

I am using behavior graph for our current production title

[wyattwilson]

Thanks for the reply. I’m using the paid asset “Behavior Designer”, and I was just checking out the new behavior graph package. A few things like this, not being able to assign default values, and not having standard “public” variables that are only visible in the inspector are disadvantages that will probably keep me from switching over.

That being said the editor performance and UI are much better, and the future for this package could be great. If I wasn’t already invested in a different solution I’m sure I could use the behavior graph package with only a few tweaks and workarounds.

[NixonAroboX]

I respect that.
Def. keep your eyes open about updates on behavior graph, the team is working very hard from what I can tell. If it is not for you now, it may be after a couple of updates =)!

[ShaneeNishry]

@wyattwilson

Thanks for the reply. I’m using the paid asset “Behavior Designer”, and I was just checking out the new behavior graph package. A few things like this, not being able to assign default values, and not having standard “public” variables that are only visible in the inspector are disadvantages that will probably keep me from switching over.

That being said the editor performance and UI are much better, and the future for this package could be great. If I wasn’t already invested in a different solution I’m sure I could use the behavior graph package with only a few tweaks and workarounds.

Hey @wyattwilson, thank you for the feedback!

I’d like to attempt to answer some of it:

not being able to assign default values

What do you mean by that? Is it in nodes or Blackboard? Because you can assign default values in both.

1. Assigning a value in a blackboard variable for the graph’s blackboard will show that value as default in the inspector.
2. In a node class you can assign a default value like the following:

[SerializeReference] public BlackboardVariable Speed = new BlackboardVariable(1.0f);

Please note that if the node was already created it won’t reset to the new value and you’ll need to re-add it to the graph or set it manually.

not having standard “public” variables that are only visible in the inspector

I assume you mean non BlackboardVariable fields in nodes? I’m hoping to tackle that one early Q1

Can I ask you to provide me with more blockers and quality of life issues that stop you from moving to this package? What’s your wishlist?

[wyattwilson]

Hi @LauraRantonen ,

First of all, thank you for clarifying about the default blackboardvariable values for nodes. I didn’t see this mentioned in the documentation, but I like the implementation.

Also to clarify, yes, I was referring to non-blackboard variable fields in nodes. Having all variables in the node description gets very verbose very fast, and not all fields have equal importance or frequency of use, so I look forward to having this option, especially for more complex actions.

On a related node, I’ve noticed a formatting issue where the “story” doesn’t seem to format blackboard variables properly when using multiple lines via “\n”. The text does break into a newline, but then when reaching a blackboard variable the text seems to center vertically. (see image) Maybe this is just using the “story” in an unintended way however.

One of the issues I’ve encountered are how ticks work. I see that I can manually call the “Tick” method for a behavior graph to update, but is there an intended way to stop the automatic call of “Tick” every frame? My use case involves many enemy objects, and ones that are of lower importance and higher distance from the player don’t need to be called every frame. I suspect I may be able to prevent the automatic calling of “Tick” by disabling the Behavior Agent component, but I haven’t tested this yet.

I am also curious what exactly occurs on a “Tick”. Does the graph execute until it reaches a “running” status? Upon a node’s “Success” does the next node call “OnStart” and “OnUpdate” that same tick (assuming that "OnStart returns Status.Success)?

I am also curious about the “Status.waiting” behavior. I see that this is occurring while child nodes are being executed according to the documentation, but to me it is unclear exactly what that means. Is this only for use with flow nodes, for example a sequence node returning “Status.iswaiting” while the children are being performed?

Now I may have some bad habits regarding how some nodes are intended to be used since I am coming from a different behavior tree implementation, but are aborts only called once in their sequence? The previous system I used had aborts implemented into its equivalent of “flow” nodes, and that abort would be evaluated every update, along with a hierarchical structure of higher priority sequences being able to “steal” the execution from lower priority ones. If this sounds convoluted, it is because it is (and it was poorly implemented), but I hope that the advantage of that system can be imagined. Let me give you the example of what I am currently using this system for:

My enemy npcs have a “stunned” state when they have had their ‘posture’ bar fully depleted (similar to Sekiro). This overrides all other behaviors. So when the variable “isStunned” is true the behavior tree should abort all behaviors being performed and jump to the “isStunned” branch. How should this behavior be handled in the behavior graph? In the previous behavior tree system I was using, the previously mentioned “Hierarchical priority abort structure” was a very inelegant solution that fit this exact scenario. I am just struggling to determine the intended method for implementing this type of behavior in the behavior graph. I do see potential solutions with custom flow nodes, but hopefully there is an integrated solution.

All of that being said, I decided to start migrating towards the new behavior graph due to its better editor performance and ui. There is a lot that I am impressed by. I really hope that it is widely used because it seems like a significant tool for the vanilla Unity experience. I just hope that the documentation is updated to be as pedantic as I am, and that the examples in the demos are made significantly more complex to show how more advanced behaviors are intended to be implemented.

Thanks for replying and showing interest in my feedback. I am very excited about the potential of this package.

[MorganHoarauUnity]

Hello @wyattwilson ,

Thank you very much for taking the time to share your feedback

There is a lot to cover, so I might miss a few bits, don’t hesitate to ask for more details!

@wyattwilson

Having all variables in the node description gets very verbose very fast […], so I look forward to having this option, especially for more complex actions.

I think there is a bit of confusion here. We indeed don’t support direct “constant” that would allow to display non-BlackboardVariable [SerializeField] type to a node. However it is already possible have a serialized BlackboardVariable not specify the node story – it will in that case be display in the node inspector:

@wyattwilson

The text does break into a newline, but then when reaching a blackboard variable the text seems to center vertically

Looks like something we didn’t expected
It is true that the node story support rich-text (which is neat to use things like bold and italic). But you are probably the first user trying to use it to multiline. This is not something we want to support as far as I know, as the goal is to let user create to short node instruction that should be short and easy to read. Actually we even have plan to limit the maximum limit of character that a node story can display (or at least limiting the amount of character user can set when creating a new node).

@wyattwilson

is there an intended way to stop the automatic call of “Tick” every frame?

Like you mentionned, you can prevent a graph from running by disabling the Behavior(Graph)Agent component.

Aditionnally, we are working on improving the general lifecycle of BehaviorGraphAgent, and one of the area we would like to improve is the ability to specify the Update method of agents. This way you will be able to choose when they should tick, but also could start implementing Level Of Details mechanism for your BehaviorAgents.

@wyattwilson

I am also curious what exactly occurs on a “Tick”.

You guessed right, when Tick is called, the graph is going to:

1. Look if there are nodes to run
2. If there are, start running them and their child until they all succeed or until one returns Failure/Running/Waiting/… (ofc the actual flow mechanism can be complex as some nodes can run in parallel - sequentially)

@wyattwilson

I am also curious about the “Status.waiting” behavior.

The Waiting status can be use when a node wait for an external system. It usually means that the node started it and is now either going to:

• run forever (or until aborted)
• or is waiting for the system to finish before Awaking itself to then continue execution

A good example of node waiting is the Load Scene. It uses SceneManager to create an async request and wait for completion before resuming the node.

@wyattwilson

are aborts only called once in their sequence?

I’m not sure to understand your question. In Behavior, modifiers such as Abort, Restart or even Repeat are always going to affect their child (and underlyings).

@wyattwilson

The previous system I used had aborts implemented into its equivalent of “flow” nodes, and that abort would be evaluated every update, along with a hierarchical structure of higher priority sequences being able to “steal” the execution from lower priority ones.

This sounds like the priority system that Behavior Tree usually implements. We don’t have that ability currently in Behavior but we discussed some of the implication in this thread in case that might be of interest.

@wyattwilson

[…] How should this behavior be handled in the behavior graph?

That sounds very interesting, I cannot really provide specific guidance as there might be more to consider, but something I usually recommend is to make complex behavior by using an FSM-BT hybrid approach. BT used to evaluate the state of your agent and FSM part to implement state and reaction.

@wyattwilson

[…] the examples in the demos are made significantly more complex to show how more advanced behaviors are intended to be implemented.

Sounds like you already had a look at the Behavior Demo. Would you have suggestion of what kind of complex scenario you would like to see being covered?

Thanks again for taking the time to provide with such in-depth feedback

[xAvatarchikx]

Hi! Has this functionality appeared in the latest version?

[MorganHoarauUnity]

Hi @xAvatarchikx

This functionality is still not yet supported in the latest version, but thanks for bumping the issue. I’ve created a public ticket, feel free to bump it to help prioritize the work.

https://issuetracker.unity3d.com/product/unity/issues/guid/BEHAVB-328
(Link will be active in an hour or so)

I’ve got a bit more details now, so I’ll provide a bit more context.

There are actually 2 parts to the issue:

1. There is a need to support custom UI elements any List of UnityEngine.Object types.
2. There is a need for a new UI workflow to allow the type selection of List from the blackboard view.

It is currently already possible to create a List<YourCustomUnityObject> in your blackboard by creating a custom node and changing the type of a BlackboardVariable of the node with a list of your custom type. However, the first issue mentioned above would cause the BBV list to not draw anything in the blackboard (+ an error).

It should be possible to handle the first part, which would provide this functionality using the manual workflow explained above. I created a ticket to tackle this bit (as it is a bug because you can already create lists of custom type but cannot use them and error is raised)

The second part is more like a feature request that cannot be prioritize for the time being. I’ve have an internal ticket for it.

Thank you for your comprehension.