Reply To: Can Nested FSM/BTs have their own BlackBoards?

[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!