Iterating through a BehaviorSource's Tasks

gumboots

New member
Hi again!

Another attempt to do something BD wasn't really designed to do...

I have broken my rather large Behavior Tree into separate ExternalBehaviors. This is great for modularity! However it is difficult to track SharedVariables, particularly when a new one is added. That is, ensuring all nested Behavior Trees have the correct SharedVariables declared to eventually be passed down to a tree that uses it. Can you think of anyway to easily manage this? Going through all of my trees in order manually would be far too time consuming, and wouldn't solve adding new variables later.

I had the idea of traversing the tasks of a Tree to check for any variables that should be mapped, but I couldn't seem to iterate the tasks. There'd also be the issue of actually making sure these values were assigned correctly etc.

Any ideas are greatly appreciated!
 
Last edited:

Justin

Administrator
Staff member
You could start at the root note of the behavior tree with:

BehaviorSource.RootTask

And then traverse down through all of the children if the task is of type ParentTask. You can use the Children property to access the child. From here you can detect if the task is of a certain type (such as a reference task) and then start iterating through the external tree. This should allow you to track the shared variables.

On a side note I am just starting to think about Behavior Designer 2 and am starting from a fresh project so I'm not restricted by any of the current designs. If you have any suggestions to make this process easier I'd love to hear it!
 

gumboots

New member
It obviously depends on your target market, but wherever I can, I prefer to drive with code. (I understand the need for a UI for the trees themselves, of course.) While it's bending Behavior Designer a bit, my [MappedProperty] attribute works quite well! I create all the properties I need almost entirely via code, and am notified of properties in the Behavior Tree that aren't a part of my class. Even the sleekest UIs built in Unity are cumbersome when you're used to your own code, so being able to manage my properties this way is excellent. In my dream world, everything would be mapped to a class' properties by default, and you would create temporary variables in some other way. The issue I have above is an interesting one to try and solve.

This is only some very quick thinking, but what if you exclusively used External Behaviors in the new Behavior Designer. You would still put a Behavior Tree on a GameObject, but they always use External Behaviors. External Behaviors could be Scriptable Objects created from a class that inherits from your base class (e.g. "Behavior"). So, to create a new External Behavior: I first create my class, (inheriting from the abstract "Behavior"). Then create a new ScriptableObject using that class. In it, I mark each property I want published in the tree with [Property]. And voila, deleting and adding properties is code driven!

Then, for the actual problem of this thread, maybe child-trees (which as per above are also their own classes) always traverse up the hierarchy to find the first parent tree with the defined property? So if there's any amount of trees between a parent that has the property MyProperty, and the child class that has it, the child will skip all of the trees without that property? Issues arise when you have two classes with two properties that are distinctly different but named the same of course. Maybe you need to mark the child-tree properties explictly one way or the other: e.g. [Property(IsInherited = false)].

I now realise I've just blabbered on about a bunch of core structure ideas, which I'm not sure you were asking for! Haha.
 
Top