0
\$\begingroup\$

In Ian Millington's "AI for Games" it is stated that behavior trees should not actually own any data, and instead a blackboard can be used to store data nodes of a behavior tree need to know about and act upon. A blackboard is defined as an associative container that holds pretty much any kind of information.

But what should actually go into a blackboard specifically? When we have an NPC that follows the player, should it store the current location of the player or an entire reference/pointer to the player object? Is there any benefit to this approach over passing a reference of the NPC to the currently executing node, and allowing the node to access data of the NPC object directly?

\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

When we have an NPC that follows the player, should it store the current location of the player or an entire reference/pointer to the player object?

Not necessarily. You might want to store a reference to the player, depending on how do you want the AI to work.

For example, if you don't want the AI to work on the current position of the player, but on the last seen position of the player, you can put that on the blackboard instead.

You would have to decide if your agents are always aware of the player, of if they are all aware if only one of them sees it (you can add an animation of the agent talking on intercom for verisimilitud), or if only the agent that sees the player is aware of it… And how do they communicate among themselves when they see the player (e.g. do they organize in groups? do they notify nearby agents?).

For another example, you could have your NPC reference what it is following, which allows you to have it follow something other than the player.

Perhaps the player can make decoys, and have the agents follow those. Or perhaps the same behavior can be reused in other cases.


Is there any benefit to this approach over passing a reference of the NPC to the currently executing node, and allowing the node to access data of the NPC object directly?

First of all, are you sure your NPC is not a blackboard? It might be, or it might have one.

Having your behavior work with a generic blackboard class keeps them independent form other implementation details.

You might also want to advantage of a blackboard to hold the data that you need to persist (for saving and loading the game) together.

Furthermore, there is something you get with blackboards that you don't get with a reference to your NPC: Communication. Without a way for agents to communicate they are oblivious of each other. And a blackboard is a way to archive that communication. I'm NOT saying a blackboard is the only way to do it.

Also, the agent might need some information that changes beyond their control to work correctly. For example: should the enemies be alerted, should they be using lethal weapons, or it could be weather or day time, or if the player has completed some objectives, etc. And the AI can get this information form the blackboard.

Thus, consider the scope of the data. You might have data that is local to the behavior, to the agent, to the room where the agent currently is, to the building, and so on… Until you get to global for everybody. If each of these scopes uses different blackboards, you need to organize the blackboards in parent-child relationships. The book mentions this "scope chain".

I would also like to encourage you to look into the concept of an AI director in game development.

\$\endgroup\$
1
  • \$\begingroup\$ Thank you for the insightful answer. I read about shared blackboards for event driven behavior trees, so that is also something I am looking into. I will also read up on AI directors :) \$\endgroup\$
    – Ralph
    Commented Jan 20, 2023 at 7:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .