Events Database in Notion
Welcome back to building our D&D campaign management system in Notion. Today, we are looking at the second of our procedural databases: Events. Events are the sub-steps that make up Fronts. In Dungeon World, where Fronts originate from, the game designers call events “Grim Portents”.
A villain has a grand plan. A goal they wish to achieve. Those plans usually take multiple steps. Each event affords your players the opportunity to mess with the villain’s plans. Or outright stop them completely.
On the flip side, if the players do nothing within a set time, then the villain becomes successful. And they move onto the next step [event] towards their goal. You should telegraph each successful event to the players. Let’s say the player’s choose not to reinforce the borderlands. And the Ogre-Mage’s forces break through. Then the players should start hearing news about the Ogre-Mage’s advance. Refugees should be fleeing into the areas where the players are. This telegraphs to the players that the front is growing.
Of course, they still have to choice to intervene or not. If they don’t, proceed through the next event after an appropriate amount of time. This ratchets the tension up even more.
Events as a Separate Notion Table?
You can easily list out your events within a front’s Notion page as a quick bulleted list. But I chose to make them a separate table. I have found that each event can be a whole adventure (or more) in-itself. Therefore, I want to capture a lot of key information about each event.
This also lets me easily create a linked database in my Fronts template. So I can access all that good information on the Front’s events cleanly.
Descriptive Properties
Here are the descriptive properties I include in my Events database.
| Column | Property Type | Description |
|---|---|---|
| Event | Title | Title/description of the event. |
| Order | Number | The [rough] numerical ordering within the Front. |
| Status | Select | The current state of the event. I use: Future, Underway, Ended – Success, Ended – Failure |
| Condition | Select | The conditional order of the event. Some events rely on the completion of prior events and others do not. I classify events as: independent, Linear-Dependent, Concurrent, and Parallel. |
Relational Properties
Events tie to different databases in my Notion system. They include:
- Fronts. What front does the event belong to?
- Locations. What locations are central to the event?
- Villains. Links to characters database. Who is the major villain(s) involved in the event?
- Villains – Immortal. Links to immortal database. Is an immortal behind the event instead of a mortal? Link them to the event.
- Items. What items are central to the event?
- Factions. What factions are driving the event?
- Adventure. What session notes do you use to run the event? Link them.
- Secrets. What secrets provide information about the event? Link them here.
When I put everything together, this is an example of what my Events database looks like:
Notion Templates for Events
I only use a single event template. The template is a quick summarization about the event. I want to know what the mini-goal is, who is acting and how they plan to do it. I also define the success and failure states for the villain. You can also define the criteria for success or failure. How long does it take for success if the PCs ignore the threat? You can define it here, or feel it out at the table as they play other adventures.
I rarely dig into the events at the table. But they provide key information for adventure preparation. Each event will make up the basis for one or more adventures. Additionally, They are referable at the table should I need to look something up.
Like Fronts, keep this simple and easy to reference. In the next part of our Notion series we’ll talk about the Secrets database.
Further Reading on Notion:
Feature Art Credit: Ede László
Leave A Comment