The Location Database in Notion
Locations are a vital component of our roleplaying games. They serve as the backdrop for our adventures and games. Locations give the players things to interact with. They set expectations about how the environment will behave around the players. If the PCs head to a desert, then they know to bring extra water. In some cases, they subvert those expectations by making the world fantastical. We can apply elements of magic in various ways in the locations that we explore in our games. Floating castles, roiling elemental storms, and expansive demi-planar mage towers are all examples.
As a dungeon master, likely one of the first questions you ask yourself is “where are the players going?” or “where will this adventure take place?”. And so your need for locations arise in your preparation. Using our campaign management system in Notion. I prefer to keep my locations stored in databases. They become easy to reference and find as we develop our campaign notes. But they stay in their own Notion page. The page contains the relevant information for the location. But it keeps it available for multi-use by not burying it in adventure notes only.
Two Location Databases
I referenced in my blueprint that I use two location databases. I call them the locations and the sublocations databases. Locations are for major places in the world. These are cities, dungeons, castles, and so on. Anything that is a large enough unit, I capture in the locations database.
Sublocations are locations that require their own set of information. But the location is only a piece of a greater locale. A magic shop in a city is an example of a sublocation. It has relevance in the game, because the players will likely visit it. But, the location belongs to a greater parcel that I am documenting in the locations database. The database properties differ between the two databases. The locations database uses descriptive properties. These identify where it is in the game world. The sublocation database uses descriptive properties that focus on classifying its type.
Here are the descriptive properties I include in my locations database.
|Plane||Select||Identifies what plane of existence is the location found on.|
|Continent||Select||Identifies what continent the location is found on (if on a world, or place with continents)|
|Region||Select||Identifies the region the location is found on. Could be a sub-unit of a continent, or a used on planes where continents are not a thing.|
|Kingdom||Select||Identifies the Kingdom that the location is found.|
|Environment||Multi-Select||A tagging system that lets you identify the prevalent environment characteristics of the location. For example: forest and hills.|
Locations tie to a lot of different databases in my Notion system. They include:
- Characters. Which NPCs do we find in this location?
- Factions. Which factions have a presence here?
- Immortals. Do any immortals have an oversized influence here?
- Items. Are there any important items found here? Any treasure tied to this location?
- Adventure Notes. I reference which locations I plan in which adventures. Makes my referencing quick and easy.
- Campaign. Which locations tie to which campaign(s) I am running? Useful for filtering and finding the relevant locales.
- Events. Are any specific front events tied to a location? Connect them.
- Fronts. Are any locations important to the front? Connect them.
- Related Locations. A reference column that references the table on itself. This lets me associate locations with other locations.
- Sublocations. This is how I reference sublocations within the location.
- Secrets. If there are any secrets tied to or about a location, I connect them.
- Media Tome. If I’m borrowing a location from someone else, I can reference their work here.
- Chars. This is a rollup to count the number of NPCs I have associated with the location.
Here is a sample of my complete location database:
Location Notion Templates
Templates come in handy for our locations. Our different types of locations will use different information to run in our games. The information I need for a city might be different from the information I need for a village. And the information I need to run a village will be different from what I need for a dungeon.
Currently, I have four templates that I use:
- Capital template
- City/Town Template
- Village Template
- Dungeon Template
The dungeon template is generic for dungeon. I can use it for castles, caves, temples, towers, and so on. The information needed to run those locales is standard enough to use a single template. You can make a lot of templates when it comes to locations. I would like to make a wilderness areas template, but have yet to do so. If you play in a hexcrawl game, then you could make a hex template easily enough.
Next time we will cover the sublocations database to round out our locale content.