How To Use Obsidian For Role Playing Games (to understand Information Architecture)

Information architecture becomes practical in Obsidian when notes are organized around how people need to *retrieve* rules and state during play—especially for role-playing games where progress, relationships, and mechanics change constantly. The core workflow here uses a mix of “one note per idea” (atomic notes) and “one big document” (a gameplay guide or character sheet) built by embedding and linking smaller notes. That combination reduces scrolling, keeps rules close at hand, and prevents the common failure mode of knowledge bases: losing the right detail at the wrong moment.

The setup is demonstrated using a solo RPG framework (Starforged, with a cast-iron style rules hack referenced as the source of the mechanics). A folder called “star forged” holds game-specific structure, including a character sheet and administrative sections. The character sheet is treated like a template so new characters start with the same headings and layout. From there, the organization splits into two competing approaches: a single document that contains everything versus separate notes for each entity (like each vehicle, person, or rule component). The single-document approach is simpler to drop into a canvas or diagram, but it breaks down when relationships need to be shown separately. The per-entity approach is more flexible but creates friction from creating and managing many documents.

To bridge that gap, the vault uses Obsidian linking and embedding in targeted ways. For example, “epic” ranking rules are stored in their own note, then linked so a quick command-click or hover preview reveals the exact progress and growth values without opening the full rules file. Progress tracking is handled similarly: instead of a static description, the vault embeds a “progress” view that updates from “0 out of 24” up through “24 out of 24,” letting the player change progress and immediately see the interface reflect it.

Relationships introduce the trickiest constraint. When a canvas or relationship map would otherwise pull multiple people into the same embedded section, the workaround is to embed only a specific heading from a larger “people” note—so one relationship card appears while others stay hidden. This keeps the “single document” convenience for diagrams while preserving the “separate entity” clarity needed for distinct relationship states.

The same embedding-and-linking pattern scales to the full “gameplay guide,” where each rules section becomes its own note, then gets reassembled into a single ordered document. That “one document to rule them all” design makes it easy to collapse sections, jump via headings, and reference rules from multiple places. Even deeper, self-referential linking is used so a section can show only the relevant embedded portion rather than recursively dumping the entire document.

Finally, the transcript shows how the interface supports play: a character sheet uses Berkeley Mono glyphs to render progress and momentum as visual rings and bars, and the dice roller plugin provides D6/D12/percentage dice with modifiers and “oracle” lookups. The result is an Obsidian vault that functions like a responsive rules dashboard—where information architecture isn’t abstract, but directly tied to faster decisions, fewer missed mechanics, and less time hunting for what matters mid-session.