Location ledger / change log for DMs
This is a working location ledger, not an atlas. Each row tracks what changed at a place, who is there now, what the party knows, what stays on your side of the screen, and what should pull them back. Copy it into any notes app, or use it as-is.
Two example locations below show what a filled-in entry looks like. The structure is system-agnostic; the names are placeholders you can replace.
Example location record
Every location lives inside a parent chain, carries a type and a current status, and can drop a pin on a campaign map. The share-safe Summary and Notes feed the campaign share view when the record is included; DM notes and Secrets stay on your side of the screen.
Pinned on the Rumerton harbor map
DM notes and Secrets stay on your side of the screen.
Two worked locations
Same thirteen rows. Very different places. One has changed around the party without them noticing. The other changed because the party acted, and the consequences are still running.
Tavern / Active
The dockside tavern the party keeps coming back to. The front room has not changed, but what works there has. A good example of a familiar place that quietly moved under the party.
Last change from session notes
Session 9: owner refused the sealed letter. Cass's cousin is new behind the bar. The back stair is still unsearched.
Landmark / Hidden
A place the party partly revealed in session 9 but did not finish investigating. Half the truth is in the open; half is still concealed. A good example of a location where the change is the story.
Last change from session notes
Session 9: half the roster is ash. The vendor thread is open. Madric is one step behind the party, not in front yet.
The tracker / thirteen rows
Three groups. Identity is written once. State in play is where most session updates land. The knowledge split is how you remember what the players can say and what stays on your side of the screen.
Group
Who and what this place is. Fill these when the row opens and leave them alone unless the place itself changes.
How the party refers to the place in one line. Add a parenthetical true name only if the party does not know it yet.
Example / The Anchor and Lantern, Rumerton.
One tag from: region, city, town, village, building, tavern, temple, dungeon, wilderness, landmark, camp, other. Types are for scan speed, not taxonomy.
Example / Tavern.
The place this sits inside, or the places inside this one. Plain text, one line each. Use this the same way you use nested folders.
Example / Rumerton, Dockside quarter.
One sentence a reader could use at the table to remember what this place is. Not a description of the room; the shape of the place in the campaign.
Example / The party's Rumerton meeting spot. They leave messages for the Fellwake crew with the owner.
One of: active, hidden, abandoned, destroyed, unknown. Change it when it changes; leave the history in your notes.
Example / Active.
Group
What changes session to session. Three of these (Inhabitants, Notes, and DM notes) are dedicated fields on the location record. The worksheet conventions below (first discovered, last touched, what changed last, if the party returns, open thread) are prompts for what to write into those fields, not separate storage.
Named NPCs, factions, or forces currently present. One line each. Include offscreen occupants. Say so if the place is empty.
Example / The owner. Quill when she is waiting. A new bartender as of session 9.
Share-safe state. Use this for the short summary a player could repeat ("the party's Rumerton meeting spot; the owner knows Cass by name"). Appears in the campaign share view alongside the description.
Example / The party's Rumerton meeting spot. They leave messages for the Fellwake crew with the owner.
Multiloop does not carry a dedicated "last touched" or "what changed last" field on a location. These are prompts for what to write into DM notes on the location: a one-line delta from the session that last moved the place, plus a session number. DM notes stay on the DM side of the screen.
Example / Session 9: the owner stopped taking sealed letters for Mireport. Paid through the harbor patrol. Back stair to the cellar is still unsearched.
The one concrete thing that will be different next time the party walks through the door. Also a DM notes prompt, not a separate field on the location. Leave blank when nothing has changed; do not invent forced prep.
Example / The letter drop is gone. Quill will suggest a new one at Saltwright.
Secrets on the location holds true-but-hidden facts and reveal triggers. Use it for the one thread that keeps this location in the tracker: a hidden passage the party has not found, a payment the owner has accepted, a reveal that will fire when the party asks the right question.
Example / Owner was paid through the harbor patrol to stop taking letters. Back stairs lead to a cellar the party has not searched.
Group
What players can read and what stays on your side of the screen. The product uses Description, Secrets, and DM notes; it does not mask individual worksheet rows for you.
The share-safe facts a player could read: appearance, the named owner or occupant they met, the obvious hook.
Example / Dockside tavern where the party meets Quill. The owner knows Cass by name. Good fish stew.
What is true but not revealed. The lie, the buried body, the hidden stair, the reveal trigger if one is ready.
Example / The owner was paid to stop taking sealed letters. The back stairs lead to an unsearched cellar.
The one reason this place still needs DM attention. If this note is blank for three sessions with nothing waiting, archive or set the place aside.
Example / Whether the party notices the new couriers before Quill changes the handoff pattern again.
One more row
Below the thirteen fields, keep a one-line delta from the last session that touched this place. It is the ledger's tie to your session notes. A row with no delta for three sessions, no occupants, and no open thread is safe to archive.
Tracker rhythm
The tracker works in a plain document tonight. A place becomes a row the first time something happens there the party will remember, not before. The same rhythm runs in a markdown file, a spreadsheet, a notebook page, or a campaign workspace.
First named scene
Open a row the first time the party stands in a place, names it, or earns a working lead to it. Not sooner. A place the party has only heard gossip about stays a line in your session note, not a row.
Sessions that moved it
Touch the row only in sessions that changed something about the place, whether the party was present or offscreen forces moved the state. Update status, last touched, who is here, what changed last, and what will be different if they return. Leave identity rows alone unless the place itself changed.
Quiet and resolved
Archive after three sessions with no thread, no returning character, and no party interest. Archive on resolution too: the place was destroyed, abandoned by the party on purpose, or paid off whatever it was tracking. A stale row is prep debt.
Margin rule / cut
Every row you write is a row you maintain. Keep the tracker small by keeping these out of it.
Margin rule / write
Every location in Multiloop is a record with a defined field set. The tracker above names each field using DM language; the worksheet conventions ("last touched", "what changed last", "if the party returns", "open thread") are prompts for what to write into those fields, not separate storage.
In Multiloop
Worksheet-only conventions to keep in your own notes, not in a field that does not exist: the session-number columns you would use in a spreadsheet, the one-line delta you write after each session, and the public/DM-only chip in the tracker header. In the product, those map to DM notes and secrets content, plus the record-level player-view setting.
Location sharing happens through a campaign share view that filters each location by its player-view setting. Share-safe content (name, type, description, summary, inhabitants, notes) appears in the share view when the record is included; DM notes and secrets stay on the DM side. Write anything the party can read into share-safe fields and keep private material in DM notes or secrets.
Next prep opens with approved new location records already in place, shared notes accounted for in the scan, your deliberate DM-note and secrets edits ready to read, and the locations where nothing has changed still quietly unchanged.
Markdown / plain text
This works in a plain document, a markdown file, a notebook page, or a campaign workspace. One block per location, or one file per location. Select and copy.
# Location: [Name]
Identity
Type:
Parent location:
Summary:
Status:
State in play
First discovered: S
Last touched:
Who is here now:
What changed last:
If the party returns:
Share-safe notes
Description:
Secrets:
DM notes (open thread):
Last change from session notes:
FAQ
Get Early Access
Multiloop holds each location as a record you can nest, link to maps and pins, and reference from the NPCs, sessions, quests, and encounters it touches. Analysis can surface new location candidates from DM and shared player session notes for you to approve.