Article
files/blackboard

Using a Static Blackboard to Store World Knowledge

Alex J. Champandard on July 18, 2007

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:

  1. Simple to create when the game isn’t overly complex, the behaviors are well specified.

  2. Very efficient in terms of performance and storage requirements.

  3. 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:

  1. Can’t store extra information without up-front design.

  2. 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?

Discussion 12 Comments

alexjc on July 18th, 2007

Sounds interesting Eddie. Is this the project on your website? I've also been quite happy with static blackboards, and it certainly helps to have a bunch of template helpers that work with any data-type to do various operations... Thanks for the feedback also, and be sure to spread the word in Abertay! Alex

alexjc on July 18th, 2007

Sounds interesting Eddie. Is this the project on your website? I've also been quite happy with static blackboards, and it certainly helps to have a bunch of template helpers that work with any data-type to do various operations... Thanks for the feedback also, and be sure to spread the word in Abertay! Alex

leghan on July 20th, 2007

In my opinion, I think its more interesting having the differente data labeled, and so, to make blackboard dinamic, so you can publish different data for the same subject (ej, resources needed) so the available agents can easy search for data that may be of their interest (ej for needs that thay can supply). When the project gets bigger, and more complex within development progress (and every AAA project ends up growing in design requirements and) you probably will end up with a system that is so spread that becames dificult to change or refactor. But it all about what are the expectations of your proyect. But be aware that EVERY project starts with a desing that promises to be "very simple" and "cool" at the same time.. and then lately you feel of your bed and wake up. Angel. PD: Very interesting site. Congratulation!!!

leghan on July 20th, 2007

In my opinion, I think its more interesting having the differente data labeled, and so, to make blackboard dinamic, so you can publish different data for the same subject (ej, resources needed) so the available agents can easy search for data that may be of their interest (ej for needs that thay can supply). When the project gets bigger, and more complex within development progress (and every AAA project ends up growing in design requirements and) you probably will end up with a system that is so spread that becames dificult to change or refactor. But it all about what are the expectations of your proyect. But be aware that EVERY project starts with a desing that promises to be "very simple" and "cool" at the same time.. and then lately you feel of your bed and wake up. Angel. PD: Very interesting site. Congratulation!!!

gware on July 20th, 2007

I have been working with a dynamic blackboard for few years. It needed computation power to navigate in it, and lot of meta data (to get rid of type issues, and ease the navigation). I worked fine, but became a bit messy : - everybody would write in it at any time - everybody would erase data in it - some memory became "wasted" due to both metadata and data duplication ("I copyied data X to Y because it is erase by process Z" and so on). From my experience, programmers (I included) tend to carefully design and refactor code (thus carefully design data structures), but can make messy calls (thus, copy anything anywhere, and sometimes ... forget to free memory). Static blackboard have , in my opinion, a big advantage : they are designed to store ONLY what is really used. Maybe an hybrid system could help programmers in few aspects. From the post it would something that have the following caracteristics : - Simple to create - Efficient (memory and computing power) - Simple to create (this is the hardest part IMO) - Can store extra information - Does not need to be recompiled Adding to this list : - possibility to dump extra information type and data (to reinject in the static part if possible) Seems a bit difficult, some tradeoffs have to be made. I think it can be a little tricky to get it up and running, but it can also be worth it. This would give programmers a way to easily add new data to the architecture and reduce turn around times, while having the static pros described above. A guide line of such system could be that at each release a log file of the dynamic data is dumped, and most of it should be refactored to fit in the static architecture. Also, I think most games have a "complete" data design before the end of the development process and, if the programmers are careful enough, this time can happen early in the process. When this is done, the static blackboard architecture become the most efficient way to store and load data (saving you metadata and processing data to access what you stored).

gware on July 20th, 2007

I have been working with a dynamic blackboard for few years. It needed computation power to navigate in it, and lot of meta data (to get rid of type issues, and ease the navigation). I worked fine, but became a bit messy : - everybody would write in it at any time - everybody would erase data in it - some memory became "wasted" due to both metadata and data duplication ("I copyied data X to Y because it is erase by process Z" and so on). From my experience, programmers (I included) tend to carefully design and refactor code (thus carefully design data structures), but can make messy calls (thus, copy anything anywhere, and sometimes ... forget to free memory). Static blackboard have , in my opinion, a big advantage : they are designed to store ONLY what is really used. Maybe an hybrid system could help programmers in few aspects. From the post it would something that have the following caracteristics : - Simple to create - Efficient (memory and computing power) - Simple to create (this is the hardest part IMO) - Can store extra information - Does not need to be recompiled Adding to this list : - possibility to dump extra information type and data (to reinject in the static part if possible) Seems a bit difficult, some tradeoffs have to be made. I think it can be a little tricky to get it up and running, but it can also be worth it. This would give programmers a way to easily add new data to the architecture and reduce turn around times, while having the static pros described above. A guide line of such system could be that at each release a log file of the dynamic data is dumped, and most of it should be refactored to fit in the static architecture. Also, I think most games have a "complete" data design before the end of the development process and, if the programmers are careful enough, this time can happen early in the process. When this is done, the static blackboard architecture become the most efficient way to store and load data (saving you metadata and processing data to access what you stored).

leghan on July 23rd, 2007

I agree with Gabriel, that making things more sophisticated can end up with messy code, but this is only a matter of programmer expertise and good practises. I must say that my 'dynamic' vision is nor to make every 'meta' and fully generic. It would help simple gruop the data stored in substructures (not having lots of bool, ints and floats without context), and having the positibility to add labels (tags) to the data structs, maybe defining different 'subjets' inside the blackboard, so as to have the data organized, and also making possible for proccess to subscribe to the subjects, so they get called when the subjects content changes (avoiding polling policies). I was only trying to explain that having the plain static blackboard struct is just a bit as going back to the times of global-variable-programming in C... And as a software engineering devotee, this is something I will always try to avoid (when ever possible, and convenience)

leghan on July 23rd, 2007

I agree with Gabriel, that making things more sophisticated can end up with messy code, but this is only a matter of programmer expertise and good practises. I must say that my 'dynamic' vision is nor to make every 'meta' and fully generic. It would help simple gruop the data stored in substructures (not having lots of bool, ints and floats without context), and having the positibility to add labels (tags) to the data structs, maybe defining different 'subjets' inside the blackboard, so as to have the data organized, and also making possible for proccess to subscribe to the subjects, so they get called when the subjects content changes (avoiding polling policies). I was only trying to explain that having the plain static blackboard struct is just a bit as going back to the times of global-variable-programming in C... And as a software engineering devotee, this is something I will always try to avoid (when ever possible, and convenience)

alexjc on July 23rd, 2007

[B]Gabriel,[/B] It's interesting to hear about your experiences. Certainly having one central place where all processes interact can reveal organizational problems. But I believe most of these can be resolved by either software techniques: [LIST] [*]Nobody deletes any information, it just expires (the blackboard removes it). If you want to change the behavior of other processes, instead of deleting, mark that data as false or inactive. [*]Add facilities to subscribe to certain data (using a certain label as id), and only post the data if somebody is interested. [/LIST] Also, having more restrictive design practices may help with such problems. When you find processes disagreeing, then they certainly have overlapping responsibilities which can be fixed by having a supervisor process to regroup them together... [B]Angel,[/B] That's sounds like a very sensible design! It could be implemented rather easily using a visitor and a bunch of observers... It's funny to see how modern design patterns tend to mirror what was invented years ago in various fields :-) Alex

alexjc on July 23rd, 2007

[B]Gabriel,[/B] It's interesting to hear about your experiences. Certainly having one central place where all processes interact can reveal organizational problems. But I believe most of these can be resolved by either software techniques: [LIST] [*]Nobody deletes any information, it just expires (the blackboard removes it). If you want to change the behavior of other processes, instead of deleting, mark that data as false or inactive. [*]Add facilities to subscribe to certain data (using a certain label as id), and only post the data if somebody is interested. [/LIST] Also, having more restrictive design practices may help with such problems. When you find processes disagreeing, then they certainly have overlapping responsibilities which can be fixed by having a supervisor process to regroup them together... [B]Angel,[/B] That's sounds like a very sensible design! It could be implemented rather easily using a visitor and a bunch of observers... It's funny to see how modern design patterns tend to mirror what was invented years ago in various fields :-) Alex

Sergio on July 24th, 2007

A blackboard is a very useful pattern, but also can be abused. I agree with Angel when he says that it might feel like going back to programming in C. If you structure your data in a blackboard, and expose it to everyone, you're effectively losing all the benefits of encapsulation that object-oriented programming is supposed to provide. You are disconnecting algorithms and data, and that will give you the most flexibility for simple problems, as it will remove most of the interfacing you usually have to do with objects. You are also not committing to any static dependencies, as the lack of explicit #includes proves. However, the dependencies will still exist, and mistakes will appear when a behavior somewhere forgets to update the data in the proper way, or does something wrong with it. Code duplication can also ensue, as you have only raw data. Of course, you can write an algorithmic layer around the data, but then you're creating a different structure. For object state, I favor structuring the data in small to medium components. Those components have both data and logic (to manipulate and update the data). Instead of a boolean to indicate that the agent has cover, I'd use a component to manage the cover state (which might include additional, relevant information, like type of cover, time in cover, etc). The component could be flexible and accept external algorithms to find cover, but would offer a specific, well documented, interface to any object's behaviors interested in using cover. That said, I still think a blackboard is a very useful solution when you don't want to build a whole component architecture. I use it often to coordinate agents, as coordination logic lies with the agents themselves and it's often simple. But even in those cases, I usually end up with something mostly static but slightly more complex than a plain C struct. Also, our scripters use a fully dynamic blackboard in Lua (which is easy to implement), but they can afford to keep code complexity low enough. If their code got more involved, I would advise them to move to an object-oriented, component-based structure.

Sergio on July 24th, 2007

A blackboard is a very useful pattern, but also can be abused. I agree with Angel when he says that it might feel like going back to programming in C. If you structure your data in a blackboard, and expose it to everyone, you're effectively losing all the benefits of encapsulation that object-oriented programming is supposed to provide. You are disconnecting algorithms and data, and that will give you the most flexibility for simple problems, as it will remove most of the interfacing you usually have to do with objects. You are also not committing to any static dependencies, as the lack of explicit #includes proves. However, the dependencies will still exist, and mistakes will appear when a behavior somewhere forgets to update the data in the proper way, or does something wrong with it. Code duplication can also ensue, as you have only raw data. Of course, you can write an algorithmic layer around the data, but then you're creating a different structure. For object state, I favor structuring the data in small to medium components. Those components have both data and logic (to manipulate and update the data). Instead of a boolean to indicate that the agent has cover, I'd use a component to manage the cover state (which might include additional, relevant information, like type of cover, time in cover, etc). The component could be flexible and accept external algorithms to find cover, but would offer a specific, well documented, interface to any object's behaviors interested in using cover. That said, I still think a blackboard is a very useful solution when you don't want to build a whole component architecture. I use it often to coordinate agents, as coordination logic lies with the agents themselves and it's often simple. But even in those cases, I usually end up with something mostly static but slightly more complex than a plain C struct. Also, our scripters use a fully dynamic blackboard in Lua (which is easy to implement), but they can afford to keep code complexity low enough. If their code got more involved, I would advise them to move to an object-oriented, component-based structure.

If you'd like to add a comment or question on this page, simply log-in to the site. You can create an account from the sign-up page if necessary... It takes less than a minute!