Knowledge is the foundation of intelligence. Game actors need to remember long term facts, or just keep cached copies of sensory information that’s expensive to acquire. How do you manage this information in a way that’s simple to develop, but yet allows for interesting behaviors?
Most games have limited number of so-called “canned” assets; these are predefined sounds, animations, voice recordings, etc. So if you build your AI with these assets, you’ll most likely need a fixed amount of information from the world to use them in a suitable context.
When that’s the case, a static blackboard is most likely the approach for your game.
The Blackboard Architecture
Generally speaking, a blackboard is a data-structure that stores information used by multiple different systems. Like a real-world blackboard:
- Anyone can read information from the blackboard at any time.
Theoretically, anyone can write down some facts too.
In AI, the blackboard is ultimately a way for different behaviors to communicate together. The advantage of the blackboard is that it provides modularity; the different systems don’t depend on each other, instead they just exchange the data via the blackboard. This reduces the level of coupling between the different behaviors, which makes the system easy to work with.
Fixed Knowledge
A static blackboard stores only certain types of information, and it cannot change at runtime (as opposed to a dynamic blackboard). The information within the predefined slots of blackboard can change at runtime of course, but no new facts can be added.
For example, for a typical combat game, variables with the following types are stored:
Boolean — Is the actor in cover from fire.
3D Vector — The last known position of the enemy.
Real Number — The current level of aggressiveness.
The structure of the blackboard is designed during development. The designers must go through an iterative process of figuring out what information is required to support intelligent selection of the behaviors and assets.
Pros and Cons
Using this approach has many advantages. Static blackboards are:
Simple to create when the game isn’t overly complex, the behaviors are well specified.
Very efficient in terms of performance and storage requirements.
Quick to build, and simple to implement in all programming languages.
On the other hand, they have the following disadvantages compared to other more dynamic systems. Specifically, they:
Can’t store extra information without up-front design.
Suffer from slow turn around times, as change to the knowledge structure requires a recompile.
So, in essence, it’s a trade-off between minimizing the time spent upfront on the blackboard, and the time required to create additional facts during development.
Words of Advice
As always, start simple. Using a C++ struct or small class with simple variables is perfectly acceptable at first.
The blackboard must have almost no dependencies. If your blackboard depends on specific behaviors then it lost all its modularity with one #include!
Make some simple debugging tools for printing the content of your blackboard. It’ll be easier to see what’s going on at runtime.
Do you use a blackboard architecture? Is it static or dynamic?
