Can Nested FSM/BTs have their own BlackBoards?

[Matt Newcombe]

Hi,

Is it possible to have a nested behavior tree which also uses it’s own blackboard instance (potentially even from a prefab), at the moment it seems when I created a nested BT, although I can assign the nested BT a blackboard manually in the editor, when I drop into it from the parent in nodecanvas editor, the blackboard is switched to that of the parent.

Thanks in advance

[Gavalakis]

Hello,

This is done by design. So that a subtree regardless of where it is used, it can be parametrized based on the agent using it, since all blackboard variables are propagated down to all subtrees. This way, you only have one place to look for all the variables and that is the single blackboad that the agent has.

There was a time when I tried allowing a seperate blackboard to each graph, and in the end it really became confusin so I didn’t continue on that path.

Can you please provide a use case?

Thanks

Join us on Discord: https://discord.gg/97q2Rjh

[dragondeojosrojos]

Hi! I was just wandering the same thing,

My case of use would be as follows:

I have multiple behaviors that make little actions like FollowPath , AttackTarget , EnterBestCover etc and I use them nested inside some other “master” behavior

All these behaviors are like functions and they have some kind of input and output variables, FollowPath for example has a variable “pathToFollow” witch must be set by the master behavior just before executing the nested one, also, FollowPath can have a variable “nodePosition” holding the position of the current node of the path being followed. In this way, one variable is acting like a parameter of the function (pathToFollow), and the other works like a local variable used in the function;

As we know, there is only one blackboard that holds all the variables, and dynamically creates whatever one the behaviors might need, this type of configuration brings the problem that if two nested behaviors , working in parallel in some way, and using the same name for some of its variables, the two behaviors will be continuously overriding the value of the same variable and will provoke some very hard to track bugs.

When the project grows in complexity this scenario is very likely to happen at some point.

The proposal would be this:

First, When editing a behavior, there could be a panel like the blackboard , the behavior can the define variables just like the blackboard but they also can be tagged as “public” or “local”,

Then, When selecting a Subtree Node , on the panel where the node info appears, on the part that says “Defined Subtree parameters” it will show the list of the variables of the subtree tagged as public (not the locals), and they will appear as regular fields like the ones used for the tasks and conditions, so one could set their values.

And last, the blackboard needs to functions a little different, we still have one component shared for all the behaviors and it stills creates all the variables used for all the nested behaviors, but its stores the information in some kind of dictionary, the dictionary Key would be the Id or something that identifies the instances of the nested behaviors, and the value will be the actual information of the blackboard variable that is being used now.

In this way the blackboard can hold multiple variables with the same name and keep the variable space of each behavior separated, also treating the behavior like a “task” to witch one can pass variables in, and get results out, using an intuitive workflow in line with the design of node canvas.

That´s all! 🙂
I´d like to know if you think that implementing a solution like that is viable, and if it does, i´d like to propose it like a feature suggestion.

Thanks!

[Gavalakis]

Hey,

Thanks a lot for your time in writing your suggestion.
Very similar to this, is something I want to improve and implement long time now, meaning the ability of sub-trees to have their own public/protected blackboard variables able to define through the inspector panel of a sub-tree node like you mention. The only real problem I am facing is the fact that changing the workflow in such a drastic way will break designs already created up to current version. So the real problem is to implement these in a way that will not break anything and keep everything seamless.

Most of the work to actualy support these features has been done code wise, so it’s mostly about me putting them to use in a way that will not break anything 🙂

I am not really sure what you suggest with the Blackboard changes at the end though :).
The way I’ve though of this, is that if each behaviour has it’s own blackboard variables, then the Blackboad component added on the GraphOwner, would be only used to parametrize the “master” behaviour’s variables.
Can you elaborate on that?

Thanks!

Join us on Discord: https://discord.gg/97q2Rjh

[Async0x42]

I’ll +1 the request for a ‘local’ blackboard. I think it’d be nice to clean up some things.

I don’t know which way it’ll be implemented, but for me, a simple way would be to just have the ‘global’ agent blackboard at the top-right like now, then underneath it, and identical window, but for local blackboard variables that are only for the current graph. This way you have access to all variables, and it wouldn’t impact peoples existing blackboards.

[emmcd333@gmail.com]

Hey,

I, for another, would really look forward to the ability to create sub-tree and/or other BT BB’s as sole owner of the variable. I’d liken it to a method specific variable. You can reference with an extra step but otherwise inaccessible(sort of preaching to the choir..sorry just elaborating). As far as implementation and on going use, wouldn’t it be okay to make all pre-existing variable in a given project “public” by default and then only by election would they change to “local” (in reference to a previous post). I’m sure I’m missing something on the workflow impact , though it seems doable.
My dilemma is we are building an RTS genre with level drops into 3rd person environment. The scroll wheel is really getting a workout!

[Gavalakis]

Thanks for you input. This feature is the most high in the queue and is actually already partially implemented. The only reason it’s not officially released yet, is because I’m trying to find the best way to keep all previous projects created *totally* compatible with this new workflow and not break anything. It is getting there.

Thanks again.

Join us on Discord: https://discord.gg/97q2Rjh

[Author]

Posts