Building Locations

A Location file is any place the party can stand in: a settlement, a stretch of wilderness, a derelict voidship, a single room where the ambush happens. It is the thinnest schema on purpose — a place is mostly atmosphere, description, and the details the GM will run when the boots hit the deck.

The fields and what they're for

• name — required. Name it the way the world would say it: Hive Meridian, The Rustgate, Promethium Sump 7.
• type — a free label, not an enforced list: settlement, wilderness, dungeon, landmark, voidship, battlefield. Pick the word that helps a reader file it in their head. The example's "Starting Area" is fine for a placeholder; in a real world, be concrete.
• atmosphere — the feeling, in a line or two. This is the field that sets the scene before anyone rolls: "The air is hot, wet, and smells of machine oil; the only light is the red glow of a distant furnace." One strong sensory detail beats three paragraphs.
• description — the tour. What the party actually sees when they arrive: layout, entrances, hazards, the thing that catches the eye. Write it as if describing the room to someone who just walked in.
• notes — inhabitants, hooks, exits, hidden details, table-specific rules. If it will come up during play but isn't visible at a glance, it lives here.

The atmosphere/description split

The most common mistake is collapsing these two. atmosphere answers how it feels; description answers what you see. A player reads both: the description orients them, the atmosphere tells them whether to trust what they see. When you write, keep them separate — a moody atmosphere with no description leaves the table lost, and a clinical description with no atmosphere leaves the scene flat.

Where the secrets go

Location files are searchable compendium entries — treat them as content players can read. A public hook ("the innkeeper is hiding something") is fine. The actual secret ("the innkeeper is a genestealer cultist; her contact is in the cellar") belongs in GM Instructions, not in the location's notes. If it would spoil the reveal, it is GM material. See chapter 6 for the full split.

Conventions that keep locations usable

• One place per file. A hive city and the tavern inside it are two files: the city is the location the party travels through, the tavern is the location where the scene runs. Link them by name in prose rather than nesting them in one file.
• Name the parts the rules need. If a location has cover, chokepoints, or dangerous terrain, say so in description — the Combat chapter of the Player's Handbook runs on exactly those details (cover bonuses, difficult terrain, engagement ranges).
• Hooks over history. A paragraph of backstory is nice; one active hook — a dispute, a deadline, a door that should not be open — is what starts a session. Put history in notes if you must, but lead with what the party can do.
• Keep the identity stable. Locations are what maps attach to. If a location file becomes a map, rename the display name freely but keep the file's slug stable, or the map link breaks.

The example location in the project shows the intended shape: a starting area whose atmosphere plants one detail "that tells players something is waiting beneath the surface" and whose notes invite the hooks that turn a place into an adventure.