How to Link Characters, Locations, and Plot Into a Living Web

Most campaigns trail off from disconnection, not from lack of detail. You build a rich NPC profile, a detailed city description, a faction with internal politics, but none of them know about each other. You become the sole thread holding it all together. Forty sessions in, you can't remember which NPCs operate in which city or which faction controls the northern trade routes.

The fix isn't more notes. It's a relational database where every character, location, and faction is a node in a web of explicit, system-tracked connections. When you write that Mira trained under Torvald, both entries update. When you @mention Ashenmoor in a session journal, Ashenmoor's "Mentioned In" list grows automatically. The web is self-documenting: every creative decision you make adds connective tissue that makes the next decision easier.

This guide covers how to build that web in Kanka from your first entry to your hundredth session.

What you'll learn: How relational connections differ from wiki links, the three-stage connection workflow, and when to stop building and start reading the web Kanka features used: entry Relations, @Mentions, Relation Explorer, Campaign-Wide Connections Web, entry Archiving Time to complete: 15 minutes to learn, ongoing to master

What Is a Relational Web?

A relational web is a campaign where every entry knows about every entry it's connected to, not through your memory, but through explicit, system-tracked links. That distinction matters. A wiki page can link to another page, but neither page "knows" about the connection. A spreadsheet can list NPCs and their locations in columns, but it can't show you that the blacksmith in Ashenmoor is also the secret informant mentioned in three session journals.

A relational web treats your campaign as a graph. entries are nodes. entry relationships and @mentions are edges. The power is in the edges.

Two Layers of Connection

Kanka's web operates on two distinct layers, and understanding the difference is where most worldbuilders hit their first friction point.

Explicit Relations are the bones. @Mentions are the muscle. Together, they create a dual-layer system where some connections are deliberately designed and others emerge organically from play.

Solid lines are the connections you design. Dotted lines are the connections that emerge from play. Together, they build a living world.

The practical result: prep time decreases as the web grows. After 20 sessions, browsing an NPC's relations and mentions tells you more about their narrative significance than re-reading your notes ever could. The system surfaces relevant context instead of requiring you to recall it from memory. That's cross-referencing working for you instead of against you.

One more thing the web gives you: permission-aware connections. Some relations are public—your players see the political alliances between factions. Others are admin-only—they don't see the secret patron behind the thieves' guild. Kanka's permission chaining ensures that private entries referenced in public relations stay hidden automatically. You design the web once; the system handles who sees what.

Try building your first relational web — free, unlimited entries →

How Do You Build Connections?

Build connections in three stages: at creation, during play, and during review. This isn't a one-time setup task. It's a habit that compounds over the life of your campaign.

Stage 1: At Creation

Every new entry gets one explicit Relation at birth. No exceptions.

The NPC links to a Location. The Location links to a parent region. The Organization links to a Character leader. This minimum-viable connection prevents orphan entries—nodes floating in the web with zero edges, invisible to the rest of your world.

Open Quick Creator (press N from any page) to create the entry without leaving your current context. Then add one Relation before moving on.

The key constraint: never create a Relation you can't explain in-world. "Connected to" is not a valid label. Use specific, narrative labels: "Owes a Debt To," "Trained By," "Operates In." If you can't name the relationship in a sentence your players would understand, it doesn't belong in the web.

Stage 2: During Play

@mention every entry you reference in session journals, descriptions, and quest briefings. This is the lowest-effort, highest-return habit in relational worldbuilding.

Type @ in any text field. Kanka's autocomplete finds the entry. Select it. Done. The mention creates a traceable link, that entry's "Mentioned In" list now includes the document you're writing. You don't track this manually. The system records it.

After a dozen sessions, an NPC's "Mentioned In" page becomes a narrative timeline: every session journal, location description, and quest briefing where they appeared. That's auto-linking generating lore consistency without extra work.

Stage 3: During Review

Between sessions, add one or two Relations to entries that gained screen time. If a player bargained with an NPC, that NPC earns a connection to the player's character or their faction. If a location hosted a significant event, link the event to the location.

The review phase is where organic @mentions become deliberate structure. But keep it bounded:

• Add Relations only for entries that appeared in the most recent session
• Don't retroactively connect old entries unless a plot thread specifically demands it
• Limit deliberate Relations to 3–5 per entry, the @mention layer handles the rest
• Use verb phrases for labels: "Trained By," "Opposes," "Operates In" not nouns like "Alliance"

In practice, most campaigns we've seen settle into a rhythm: 5 minutes of relation building after each session. That small investment compounds into a web dense enough to prep from by mid-campaign.

Start connecting your campaign entries — free, no entry limits →

When Is the Web "Done"?

The web is never done and that's the point. A relational web grows with your campaign. Expecting a finished state is like expecting a finished story before you've run session one.

Here's how the maturity curve works in practice:

The test of web maturity: can you prep a session by browsing the Relation Explorer alone, without re-reading old session notes? If yes, the web is doing its job.

Keeping the Web Healthy

The danger in long campaigns is web decay—connections that no longer serve the narrative. Dead NPCs still linked to active factions. Archived locations still appearing in relation maps. Completed quests cluttering the active entry list.

Periodic maintenance keeps the web useful:

• Archive completed quest lines using Kanka's entry Archiving. Archived entries keep all their Relations and @mentions as historical context, but they stop cluttering your active lists.
• Use Quest status tracking (Active / Completed / Failed) as a narrative index. Completed quests mark resolved storylines. Browse their linked entries for loose threads worth revisiting.
• Review the Relation Explorer quarterly for orphan entries (nodes with zero connections). Either connect them or archive them. Dead weight in the web makes it harder to read.
• Export your campaign (JSON or Markdown for premium) periodically. The relational dataset is the most valuable artifact your campaign produces, back it up.

If the web ever feels overwhelming, the issue is usually tag taxonomy, not connection density. Simplify your tags, and the web becomes navigable again.

A sparse entry with rich relations is more useful than a detailed entry with zero connections. The connective tissue between your characters, locations, and factions is what turns a collection of notes into a living world, one where the system remembers what you'd otherwise forget.

This article is part of our Worldbuilding for Tabletop RPGs guide. For entry-specific workflows, see our guides on building locations, tracking NPCs, and managing factions.

Start building your campaign web — free, unlimited entries, full data export →

If you have any questions, join us over on our Discord! We also have more tutorials on our blog.