What is Blackboard good for?

Development Programming & Scripting AI
, , ,
1

It’s a pain to have to use the Blackboard when I want to reference values ​​from a Pawn or Controller in a Behavior Tree.
Since the Controller, Pawn, and Behavior Tree are one-to-one relationships, it would be convenient to be able to cast them once and reference all the values ​​directly.
This may be for abstraction reasons, but in most cases the Controller is likely to have a full reference to the Pawn, so this seems completely pointless.

What is the value of a blackboard?

2

The blackboard is useful if you want shared information between AI’s (Instance Synced). You can have parameters like an alert status or player position synced for every AI.

It also holds all of the AI’s state information in one place (think of it like a long term memory of sorts)

2 Likes
3

So who has the initiative to change the variables? If all AIs could access the same blackboard at the same time and change values, it would be incredibly chaotic.
I don’t think there’s any need to share values ​​across the AI ​​except in specific cases.

4

There is no owner in the case of shared variables. Think of them as a sort of hive mind / overarching consciousness.

1 Like
5

I have to agree that i think its an outdated model, you can try StateTrees or even custom systems

1 Like
6

No matter how many times I look into it, I can’t understand the usefulness of Blackboard. This feels like an unnecessary interruption between the behavior tree and the controller. I don’t need a hive mind. I need is smooth communication between the AI ​​and the Pawn.

The state tree seems simpler. I’ll try this one.

7

Well when it comes to deeper systems like

  • Multiple AI state behaviour trees
  • Complex AI state flow and decision flow
  • group AI , sharing, ticketing
  • long term memory as caching for performance

So with blackboards and BHT we can truly seperate AI logic from the pawn/controller. This enables more fluid archetype creation, thread safe logic and sophicticated ai flows. I don’t think it is outdated but its and old proven system that works and I still prefer behaviour trees and blackboards over cause of track records.

You will see if you go deeper their pros and cons. Every system and design have trade offs. In complex flows bht is harder to get grip on and execute however it’s doesn’t flinch in the long term.

Let’s say you have a flow of 1 to 1 combat with enemy boss.
State → Hibernating (pre-combat idle)
State → Agroed
→ Deployment (move to formation/intro)
→ Combat Phase 1
State → Immobilized (Parry / Stagger reaction)
State → DBNO (Down But Not Out → execution window)
State → Dead

each of these even more can be subtree ( which should be designed by a designer) with its own conditions, priorities, and memory keys all held together through the Blackboard rather than scattered across the pawn.

Once you start doing phases, reactions, shared awareness, and tactical decision flows, a centralized memory and hierarchical behavior system becomes incredibly valuable, state tree is good with mid level decision making and layering however it’s shallower compared to BT, with task decorators, debugging etc.

In terms of your question what I felt is you want to keep variables on controller or pawn (better controller atleast) and always get those variables since they are updated already in the pawn/controller, why I am doing it again on BB? casting etc. There are multiple answer to this

  • On BP side yes can feel overwork, however on C++ side can be one time job. Once you have a reference object the rest is history.
  • Pawn / controller should define how AI should work rather than controller telling AI. Define combat ranges, weapon, speed from controller pawn but AI should do it’s own job in the end.
  • As you said, abstraction becomes VERY important in that sense. For example: imagine you have an item that turns a rare enemy type friendly toward you. That enemy should stop attacking, stop reacting to aggro cues, ignore combat ranges, and maybe even follow or assist you.
    If all of that logic lived directly inside the pawn/controller, you would have to patch or override half of its internal behavior code. but with a Blackboard architecture, you can query that condition once (does player have the item?) and immediately switch the AI’s state. The state machine or BT then automatically drives the next behaviors without touching gameplay code at all.
    In other words, the controller provides data, the Blackboard stores the AI’s memory and world assumptions, and the Behavior Tree decides what to do. This separation keeps your system flexible, maintainable, and resilient to feature changes.
8

There’s some context to my question.

First, the AI ​​I’m trying to create will share a Pawn with the player, so the AI ​​needs to “control” the Pawn just like the player.
Second, the classes used by the AI ​​do not use Character Movement, so it is difficult for the AI ​​to think and move on its own, and instructions must be given from the controller.

I understand the behavior tree itself, but I wondered why it was necessary to go to the trouble of copying the variables used in it to the blackboard.

Casting can accomplish this goal, but it seemed kind of silly to have to do it every time I create a task. So now I use an interface, but it still feels like a lot of unnecessary effort.

9

I understand, quite nice design aspect to handle, I always like those kind of gameplay stuff :slight_smile: follower, team change, “control mind” = Very Fun. Comes with their unique gameplay problems and technical problems.

Well you are right about it why trouble?

  • It’s in your hands as decisions, if this is going to be extended to many archetypes over the course of the game can be something good to bother ourselves.
  • Can be different approach, like this is a very tight coupled system that has shared pawn and custom movement. You can use interface or parallel task with a rate to update whatever you need. Distance between them etc. In this kind of scenario it’s perfectly valid to keep it simple and working.
  • You can write custom movement tasks to ease the pain still its question about why bother.

So in other words.

  • There is nothing wrong with you do and your system. I am just pointing out further complexity around it for future.
  • If this system can expand to some other archetypes, some other systems like multiplayer / possession maybe can be better to be unified with parallel tasks, or on going async tasks.
  • Interface is the best way to do it with BP, without casts and hard couplings. Also you can cast once and store components with type (custom movement component) and communicate with that. That is also a valid approach.

On C++ side things can really get easier on this aspects btw. It is possible to make a custom struct and write those on blackboard. You can have events like if a variable changed re initilize struct etc.

Also I just want to point out something that is not a very popular opinion : Casting Is OK :slight_smile:
Cast if this is not an overused system, it’s not THAT MUCH costly, they are already coupled tightly, If they are already coupled , over casting is not important that much. If this is not going to be a massive AI ecosystem it’s not a big crime as you think.

EX:

AI → Control Mind (Player) → PlayerMovementComponent-> ControllerInput (Direction)
AI → Control Mind (Player) → WeaponComponent → Shoot
AI → Control Mind (Player) → GAS → TryActivateAbility(GetAbilities.0)->LifeTap
…

Struct
{
CurrentMovementComponent
CurrentWeaponComponent
CurrentGasComponent
CurrentCombatRanges
}

Controller → OnPosses-> If (Controller = AIController) → AIController->BB → ReInitilizeStruct()

ReInitilizeStruct()
{
Cast(Controller->Pawn)->IfValid(PlayerMovementComponent) = CurrentMovementComponent
…

BlackboardComp->SetValueAsObject(“CurrentStruct”, MyStruct);
}

10

The question seems to be changing from “What is Blackboard?” to “How can I avoid using Blackboard?”:joy:

Perhaps when it was first designed it had clear advantages, but technological advances have overshadowed them.
I’m a little late to the party, but maybe we don’t need to worry about this these days :roll_eyes:

In that sense, it may be an outdated feature.