Can we have multiple blackboard support in Behavior Trees?

General Feedback & Requests
1

I guess this is one for Daniel, but I figure it’d be useful here anyway.

Not sure if this is a current or planned feature, but from my reading you generally can only have one blackboard accessed from any given behavior tree?

So if that’s the case, I’d like to request that we add support for multiple blackboards in any given BT’s. The reasons for this are pretty simple, in that if you want to do any form of group AI systems, its far easier if you have some coordinating system to do it. In my own code I pretty regularly use multiple blackboards (with an blackboard ID used to map which one I’m using in a condition).

I’m sure Daniel and Meisko know why you’d want this, but for anyone reading, you would use multiple blackboards for instance to coordinate multi-agent movements like squad behaviors. You’d have each agent with its own blackboard, but then have an overall commander AI that actually manipulates the agents blackboards, or often a central blackboard that is shared between the squad members. Imagine that each squad member has a “who is my current target” object set, stored in its own blackboard, but also has “squad is aware of these threats” in a squad blackboard, so that the AI can position the squad members in such a way that they can engage their own target without compromising their position with respect to what the squad has engaged.

I’ve also used multiple blackboards in social simulations and smart object type systems (using a central blackboard as the way to coordinate agent access to the social object).

If this is currently possible, then ignore this post :slight_smile: but I haven’t seen specific mention of this feature yet.

Ta.

Phil.

2

Reposting a bit from my separate response to zoombapup’s question:

We don’t support multiple blackboards directly. However, there are ways you can use multiple blackboards.

First, we support blackboard inheritance. See my post here about “Parent” tab in the Details view. (I’ve also just made a note to add a specific section about blackboard asset inheritance to the blackboard documentation.)

Blackboard inheritance lets you use a base blackboard with common values for all AI while adding additional values to more specific AI in a hierarchical fashion. Then you’re still referring to a single blackboard based on the AI using the behavior tree in question. (Since the behavior tree will generally refer to specific key values, it makes sense that a specific behavior tree is tied to a specific blackboard.)

Conceptually, a blackboard stores all information needed by a specific behavior tree, so it shouldn’t need multiple ones.

Our support for “Run Behavior” nodes (which effectively run a subtree) does NOT allow you to use multiple blackboards. Each subtree is conceptually part of any tree that calls it, so they share the same blackboard. That means the blackboards must be compatible (anything you reference in a subtree must exist in the parent tree’s blackboard).

One way you could do this would be to have an AI Squad actor of some sort that would have its own behavior tree to decide what the squad is doing. That behavior tree would of course have its own blackboard, and it could also post data to specific “squad” information in the individual AI’s blackboard, which would then cause the AI’s actions to change appropriately (through its behavior tree). You can already post to or read keys from any blackboard in a behavior tree blueprint node. See this post about how to set and get values in a blackboard. You can use the “non-behavior tree” functions to set and get the values on any blackboard component (so you just need to access that component on the pawn from the squad to write to it.

You could obviously write your own helper functions as well to write to all squad members’ blackboards if necessary. Whatever solution you pursue, I’d be wary about having arbitrary numbers of trees hooked up. It ultimately may lead to a lot of confusion about where data is coming from or where it should be set. The solution above might be nice because the communication is one way (squad setting values into individual AI blackboards) and shouldn’t require reading from them at the squad level or writing to them at the individual level.

You can use the same general functions above to share a blackboard if you want. Or have the social object detect AI and write to their blackboards. (The exact best solution of course varies depending on exactly what you’re trying to do.)

I hope this helps. If you have specific reasons that you think we need direct support beyond the blueprint mechanisms, let us know.

3

Hmm, so if you can read and write data from one agent to another via their blackboard, then surely you DO support multiple blackboards :slight_smile: just not “default” ones?

Your example case of the squad AI writing data into squad members blackboards is kind of my point really. Similarly squad members might want to read data from the squad “commander” blackboard, such as arcs of fire to cover. Of course this would work either as a push model (squad updates squad members) or a pull model (squad members pull data from squad commander BB).

My concern is that there might be a number of groups that any given agent belongs to. It all comes down to the issue of composition rather than inheritance. I have come across situations where the set membership of a given agent is quite transitory, they might be a social agent where they are simply walking around a level, then they become part of a social gathering (say a game of football in the park), which then reverts to being just a person walking around when the match is over. The ability to be part of multiple groups suggests to me that composition is better than inheritance in this case. I can see inheritance being useful for specialization (i.e. every agent is “human” but then some are “police” and then some of those police are “corrupt” while others are “good” etc. But for most of what I’ve tried to do, the group membership is transitory (often only for the duration of the interaction, which is usually temporally constrained).

I’ll definitely have some time to play with the current implementation soon, so I’ll give more useful feedback once I’ve had some time with it. It might well be that all the use-cases I can think of are already covered.

4

Yes, under that definition I suppose we do support multiple blackboards. Blackboards are components, so you can have as many as you like, you would just need to set up your own system to access them (whether through blueprints or code).

However, the “default” blackboard for behavior trees is used by built in decorators such as the “Blackboard” conditional decorator, so right now you’d have to either use a blueprint conditional or write your own in C++ if you wanted similar functionality with another blackboard.

You are of course correct that you could use blueprints to pull as well as push. (My example above was push, but pull might very well be better, depending on your usage case.)

Please let us know when you try it out; I’ll be happy to hear your feedback!