Ever wanted to replicate the behaviour of the monsters in Breath of The Wild? Or perhaps have deeply varied discussions like in Firewatch? Or even know when to let out a horde of zombies like in Left 4 Dead? Well in that case, the Blackboard design pattern’s for you, friend!

The Blackboard pattern? What’s that?

In short, it is a design pattern that allows us to handle data and events dynamically at a centralized point.

That sounds neat, how can I use it?

From the very start of our current project, the designer knew that he wanted the game to be systemic, and so he came to me and asked that I create a blackboard system based on the one found in this blog post by the developers of Dead Body Falls. And so, armed with my courage and my slightly above beginner knowledge of Unity, I set out to accomplish the task ahead. As interesting as that blog post was, it lacked some depth on the aspect of actually implementing it, so I thought I’d make that process a lot clearer by turning my quest into a step-by-step guide for you all to revel on. I’ll be splitting this guide across a few different posts, each detailing one specific part of the system, starting with this post focused more on an overview of what’s to come.

One detail to note however: this process involved a lot of trial and error and research on technologies and tools that I wasn’t particularly familiar with beforehand. If you feel some areas could be improved on, please let me know! I’ll be glad to take any constructive criticism and update the guide as needed.

Part 1: Conceptualize Our Needs and Desires

From analysis of the Gamasutra blog post and discussion with my teammates, I’ve managed to extract the following requirements for our tool to be any good:

  1. The blackboard must serve as a centralized hub for sharing and extracting data
  2. We must be able to trigger events from the blackboard, so that a component doesn’t have to look again every frame
  3. We must be able to decide whether or not any data gathered will persist between play sessions, both for ease of testing and actual use in the game logic
  4. We must be able to group and read the information found in the blackboard easily

From these requirements, I formed the following test scenario that encompasses our needs:

A player spawns in a room whose door is opened and closed by a switch. The door should remember its state (whether it is open or closed) between sessions.

And here’s a little gif of what the end result will look like:

A player spawn in a room whose door is opened and closed by a switch

That’s all for now! In the next part, we’ll look into a first rough implementation of the system. Thanks for reading!