Locations

Locations organize where campaign events happen.

Location hierarchy

Use locations for regions, settlements, districts, and sites. Keep each level focused so related NPCs, maps, items, sessions, and notes remain easy to scan. The locations page shows root places first and nests child locations beneath their parent. A location detail page shows breadcrumbs back to the root and a child-location panel before related records.

Each location can also have its own type label. Use presets such as Region, Plane, Wilderness, City, Dungeon, Site, or Room, or type a custom label that fits your campaign. The label is display-only; parent/child nesting still controls the actual hierarchy depth.

Use the hierarchy for places the table revisits. If a place is only a single scene, a session recap or note section may be enough.

Visibility

Locations follow the same campaign visibility model as other resources:

• GM only for unrevealed places.
• Players for places the table knows.
• Selected players for character-specific knowledge.

What to include

• A short player-safe summary.
• GM notes about unrevealed dangers, rumors, factions, or clues.
• Maps attached to the place when a reference image helps orientation.
• NPCs, items, sessions, notes, and questlines related to the location.

GMs can use quick actions on a location to place an NPC or item there, link a map, or remove a current location/map link. Moving the same NPC or item to a new located_at location replaces the old current location; use session links for history.

Example hierarchy

For a city campaign, use a structure like:

1. Region or city.
2. District or neighborhood.
3. Building, landmark, or faction base.
4. Room, site, or hidden area only when the detail is worth revisiting.

This keeps navigation calm while still supporting deep campaign geography.