What you'll learn: How to worldbuild reactively — expanding only where players push — instead of burning out before session 1 Kanka features used: entry hierarchy, Relations, @mention system, Permissions, Dashboards, Journals Time to complete: 15 minutes to set up your starting structure

Worldbuilding for Tabletop RPGs: Start Small, Build What You Need

The number one reason GMs abandon worldbuilding projects is they built too much before anyone sat down to play. The conventional advice to design your pantheon, sketch your continents, write your creation myth, front-loads months of creative work before a single session happens. Most campaigns never survive contact with players anyway.

This is the "Worldbuilder's Trap": the belief that a world has to be complete before it can be used. The opposite is true. The most resilient campaign worlds are built reactively by expanding only where players push, deepening only where the story demands.

Session 1. The party arrives in the starting village. A player asks: "What god does this village worship?" You haven't built a pantheon. You improvise: "Solara, goddess of the hearth." Three sessions later, a cleric player asks about Solara's rival deity, and you can't remember whether you said "Solara" or "Solaris," or what domain you implied.

The problem isn't that you improvised. It's that you had no system to capture the improvisation and connect it to everything else.

This guide covers the methodology that prevents two common failure modes, overbuilding and losing continuity, by using a relational entry system that grows with your campaign instead of demanding everything upfront.

What Should You Build First?

Build the smallest playable unit: one location, three NPCs, and one conflict. Everything else can wait.

This method works in concentric circles:

Each circle's entries reference the previous circle's entries. The blacksmith in Circle 1 was born in the mining town in Circle 2. The mining town's economy depends on trade routes controlled by the empire in Circle 3. Building outward deepens existing connections rather than adding disconnected content.

Use Location entries with nesting for Circle 1: the starting settlement as parent, key buildings as children. Link NPCs to those Locations via Relations ("Owner," "Patron," "Guard"). Create a single Quest entry for the starting hook and link its instigator and relevant locations as quest elements.

The discipline: name things immediately, detail them later. A location called "The Thornwood" with no description is more useful than no location at all. A Character entry with nothing but "Innkeeper" in the Type field is enough to start.

Circle 1 should take no more than 60 minutes. If an entry has zero connections after two sessions, set it aside, it's not a living part of the world yet.

For the full walkthrough on spatial structure such as how deep hierarchies go, when to create new locations, how uploaded maps connect to your entry hierarchy, see How to Organize Fantasy Locations: Hierarchies That Scale. For the NPC creation pattern that makes every character findable and connected from birth, see NPC Management for Game Masters.

How Do Details Stay Connected?

The difference between notes and a living, breathing world is that a world knows its own connections. A document full of NPC profiles is static. You have to remember that the blacksmith's daughter joined the thieves' guild, that the guild operates out of the abandoned temple, that the temple was abandoned because of the plague 40 years ago. In a flat note system, those connections exist only in your head.

In a relational system, updating one entry ripples context to every connected entry. When you write that Mira trained under Grandmaster Torvald, both Mira and Torvald reflect that connection. Open Torvald's page during prep and you see that Mira is his student without searching.

This is the core architectural principle: entries reference each other, not just coexist. Each new entry increases the context density of every entry it touches. Prep time decreases over time because the web does the memory work.

Two tools make this work:

Relations with custom labels ("Trained Under," "Rival Of," "Operates In") and Mirror Relations enabled, so every connection is automatically bidirectional. The Relation Explorer visualizes the full connection web during prep revealing narrative threads you didn't consciously plan.

@mentions in every text field. Type @ followed by any entry name in session journals, descriptions, or quest briefings. Every @mention creates a traceable reference: the "Mentioned In" interface shows everywhere an entry appears across the entire campaign wiki. Lore consistency scales beyond human memory.

Session 8. A player asks: "Didn't that merchant say he was from the same village as the guard captain?" You type the merchant's name, see his Relations tab: yes, "Former Neighbor" relation to the guard captain, linked to the village of Ashenmoor. You also notice Ashenmoor was recently tagged "Status:Threatened." The merchant hasn't heard the news. You have a plot hook you didn't plan because the system surfaced the connective tissue that made it possible.

Don't create connections you can't justify in-world. Relational clutter is worse than relational sparsity. For the full workflow on building, labeling, and maintaining entry relations at scale, see How to Link Characters, Locations, and Plot Into a Living Web. For applying this specifically to political factions, see How to Build Factions That Drive Conflict.

What Should Players See?

Players should see exactly what their characters have discovered, no more, no less. The biggest UX mistake GMs make with digital tools is treating them as either fully private or fully public. The answer is granular: entry-by-entry, section-by-section, session-by-session.

The permission layer transforms a GM's personal wiki into a collaborative worldbuilding tool. Done well, players browse the campaign wiki between sessions, re-read what they know, discover connections between things they've encountered, and feel a growing sense of mastery over the world. But they never see the secret patron behind the thieves' guild.

The key pattern: public entry + private Articles = mystery that players can engage with without spoiling. A Character entry is visible, players see the NPC's name, appearance, role, but an Article titled "True Allegiance" on that same entry stays admin only. The fog of war holds.

Use "View As" member switching before each session to experience the wiki from any player's perspective. This catches accidental reveals.

Reveal permissions progressively: after a major story beat, flip an Article from private to visible. The wiki becomes a record of discovery, not just a reference. For the complete guide to building a player-facing wiki experience with dashboards, organization, and the structural reasons players avoid wikis see Why Don't Your Players Use the Wiki You Built?

Try this in your own campaign → Per-entry permissions work on the free tier.

How Do You Keep It Organized?

Organization in worldbuilding isn't about folders it's about retrievability. The goal is finding any piece of your world in under 10 seconds during a live session. That changes the design principle: organize by context, not just by type.

Two organizational layers survive long campaigns:

entry types handle the "what." Characters, Locations, Organizations, Quests, Kanka's built-in taxonomy means you never decide where an NPC "goes." A Character is always a Character. A city is always a Location. This structural clarity eliminates "where did I put that note?"

Tags handle the "why." Tags are the cross referencing layer that connects entries by narrative relevance. Tag an NPC, a Location, and a Quest with "Arc:TheDragonWar" and you've created an instant filter showing everything relevant to that storyline regardless of entry type.

Use 3–5 tags per entry maximum. Create a tag taxonomy early: "Arc:[Name]", "Status:[State]", "Faction:[Name]" as prefixes prevent sprawl. Configure dashboard widgets with filtered entry lists, a "Current Arc NPCs" widget, an "Active Quests" widget, a "Seed Notes" widget. The dashboard becomes the session-prep command center.

When Does Worldbuilding Happen?

The best worldbuilding happens in three distinct moments: before session 1, during sessions, and between sessions. Most advice focuses on pre-campaign building. In practice, a lot of meaningful worldbuilding happens reactively.

Moment 1: The Seed Phase (pre-campaign). Build Circle 1. Set up the starting location, three NPCs, one quest. Establish your tag taxonomy. Time: 60–90 minutes.

Moment 2: The Capture Phase (during sessions). A player asks a question you haven't prepped. You improvise an answer. The discipline is capturing that answer immediately, press 'N' or click Quick Creator to create a seed entry in under 10 seconds. Name, type, one tag, done. Then write @ and the entry name in your session journal to link it to its narrative origin. Speed matters more than completeness.

Moment 3: The Weave Phase (between sessions). Spend 15–30 minutes doing three things: flesh out seed entries from last session, add Relations between new and existing entries, review "Mentioned In" lists for key NPCs to spot emergent connections.

The critical insight: Moment 2 feeds Moment 3, which enriches Moment 2 of the next session. The more you capture, the more connections emerge. The more connections exist, the easier improvisation becomes. Prep time should decrease per session as the relational web grows.

The test: can you prep the next session using only your campaign wiki, without re-reading raw session notes? If yes, the system is working. Session prep gets shorter every week because the web is doing the recall for you.

For the concrete 5 step repeatable workflow that turns this rhythm into a 30 minute habit, see How Do I Prep a Session in 30 Minutes?

What Does a Living World Look Like?

A living world is one where the GM is surprised by their own creation. Not because they forgot what they wrote but because the connections between entries surface narrative possibilities they didn't consciously plan. The merchant's hometown is threatened. The cleric's deity has a rivalry with the faction's patron god. The abandoned temple is linked to the same plague that orphaned two NPCs in different cities. None of these were designed. They emerged from the accumulation of relational decisions made over months of play.

After 10, 20, 50 sessions, the campaign wiki isn't a reference document, it's an emergent narrative engine. The entry relationships have grown dense enough that prep means browsing connections, not inventing from scratch. The question shifts from "what should happen next?" to "what wants to happen next, given everything that's already connected?"

This is where reactive worldbuilding proves its value. A pre-built world has the depth its creator imagined. A reactively built world has the depth its players demanded, which means every detail is load-bearing, every NPC is relevant, every location has been touched by play. There's no dead content.

Use the Relation Explorer and Campaign Wide Connections Web as primary prep tools in mature campaigns. Browse the visual web for underused connections, orphaned entries, and narrative threads. The relational dataset is the most valuable artifact your campaign produces.

The living world depends on connection density. For the detailed guide on building, labeling, and maintaining that web from your first entry to your hundredth session, see How to Link Characters, Locations, and Plot Into a Living Web.

Start building your world for free, no entry limits →

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