So far, we’ve walked through the basics, Notion databases, and templates for databases. I’ve used some examples of databases that are useful for managing a D&D campaign. But I haven’t gone into an explanation on the full system.
 
Well the time has come, I plan to walk through the full blueprint that I am currently using in my Notion D&D system. And I will explain what I use each table for. Once I have laid out the roadmap for you, we will get back into case studies on creating the different tables. As always, remember to use what you like, and change or discard what you don’t.

Categorizing our Notion Databases

Notion lets us store all our information within databases. But not all databases have the same purpose in our D&D Notion system. You may not make these distinctions regularly, but understanding their differences is important. It lets us build our databases out in the in a specific manner. It gives us focus on how we will be using them throughout the management of our campaigns.
  • Content Databases. These databases store specific bits of information actively used at the game table. These are what make up your world and your campaign. Things like NPCs, items, locations.
  • Procedural Databases. These databases store information that helps you run the game at the table. They are your operating manual, or components of the manual. Adventure notes, encounter tables, and secrets are all examples.
  • Meta Databases. Meta databases store information that supports your campaign. They help you as a game master create adventures, offer advice, or knowledge to help your game. General GM knowledge, media archive, or player character databases are examples.

Content Databases

Content databases our the bread and butter of your Notion system. If you aren’t capturing some of these details, its going to be difficult to have an organized management system in Notion.
  • Characters. This is my NPC database. I track all details about NPCs worth remembering here. I’ve shown examples of this one in past posts, because it is a critical one to roleplaying games.
  • Factions. I have a separate database for factions. NPCs pool resources together and form collective goals. Those are factions. More often than not, you will have factions in your games. Its worth making note of the important ones and their details.
  • Items. I put together a database for important items in my game. Usually these are magic items. But, if I think of cool treasure that is mundane, I’ll add entries to the database too.
  • Locations. Locations are grand areas that have importance in your game. I decided to have two location tables. This one focuses on large-scale areas (cities, kingdoms, wilderness areas). For more granular locations, I use the sublocations database.
  • Sublocations. Related to locations, but these are a small-packaged size area. Usually, these are adventuring sites (castles, dungeons, caves). Having two separate location tables means that I can connect the two together. I found that the important attributes of large scale areas and small areas were different. So I broke them apart.
  • Immortals. I created a table for important figures that do not have a finite lifespan. Gods are the major players here. But I genericized it so I could include archfey, demon princes, archdevils and so on.
  • Traps & Puzzles. If you design a clever trap or puzzle, you might as well save them for further use in the future. Having them organized in a database lets you pick and chose when you need one.

Procedural Databases

These databases flesh out your session notes. They give you the information that you need to run a game at the table. They organize your content into a clear and usable fashion.
  • Adventure Notes. I store all my adventure notes in a single database. That way, I can reference them as I need to. It also lets me build out an adventure notes template. I can apply the templates again and again as I create new adventures for my players.
  • Encounters. If you use random encounters, I recommend creating an encounter database. You can pull in encounters based on location or environment type. Easy to reference and built once.
  • Fronts. The idea for fronts comes from Sly Flourish who got it from Dungeon World. Essentially, it is a way to think about your forces plans in the world. How do they go about achieving goals? The term fronts comes from “fighting on multiple fronts”. Which is what your players will be doing when they face off against disparate threats in the world.
  • Events. Events are the steps and actions that make up fronts. To achieve a villain’s goal, they will have to string together a bunch of smaller goals or victories. These happen through events.
  • Ideas & Notes. I use this as a catch all table to record thoughts as they come to me. Most of these pertain to future ideas for adventures, or things that belong in a content database.
  • Secrets. This also comes from Sly Flourish. Secrets are bit of information that provide more context to the players.

Meta Databases

Meta databases provide information about your game or how to run your game. These tables help structure and organize your Notion system. You usually don’t reference these tables while running a game. Player characters being the one exception.
  • Player Characters. This database lets me track my PCs and their abilities. When they earn items or treasure I can assign it to their PC and track it.
  • Campaign. Useful if you run multiple games in the same world. You can assign locations, adventure notes, NPCs, and so on to a specific campaign. That way you can keep straight what belongs where, but use the same tables to do so.
  • Media Tome. I use this as a repository for articles, posts, and videos that I have found useful and want to reference again. The Notion web clipper makes adding to this table a breeze.
  • Knowledge Tome. I keep notes about different aspects of running a game. This lets me organize my thoughts on a subject in a single page. Knowledge ideas include: monster design, running faster combat, courtly intrigue, and so on.

Established Notion Blueprint

With an established blueprint, you are ready to create your own databases. Build out the ones that make sense for your game and forget the rest.
 
Think about the important properties you want to see on the database. What will be useful for filtering, sorting and categorizing? How will you connect your tables together? What templates will you build for each table?
 
For the rest of this series, I’ll walk through my databases and the components of them.