TTRPG Usage Guide
Ishvana was built by someone who also writes tabletop RPG setting books. Welcome to Tikor is the flagship — a 500+ page Swordsfall RPG setting book covering cultures, nations, factions, deities, and everything a game master needs to run the world. That creator kept hitting the same wall with existing writing tools: they were good for prose, but they had no idea what to do with mechanics, stat blocks, probability math, or the cross-references between an NPC’s narrative description and their game-mechanical representation. The Magic System module is a direct response to that wall. TTRPG designers are a first-class audience for Ishvana, and the whole toolchain from Magic System to Character Sheet Designer was built with the awareness that some of its users are writing campaign setting books, not just novels. This page walks through the workflow.
The three things a TTRPG writing project needs
Section titled “The three things a TTRPG writing project needs”A TTRPG setting book has three distinct kinds of content, and the gap between them is what kills most writing-tool workflows.
Narrative content — the cultures, the history, the factions, the cosmology, the NPCs’ personalities. This is prose, and any writing tool can handle it.
Mechanical content — the rules, the stat blocks, the abilities, the probabilities, the character sheets. This is structured data, and most writing tools can’t handle it at all — authors end up maintaining mechanical content in a separate spreadsheet or in the dedicated game system’s own software (Roll20, Foundry VTT).
The bridge between them — the references in the narrative to the mechanical content, and the references in the mechanical content back to the narrative. When a setting book describes a faction’s leader, that leader needs a stat block. When a stat block exists for that leader, the narrative description needs to match their mechanics. And as the book gets revised, both sides need to stay in sync.
The bridge is the thing nothing else does well. Ishvana’s Magic System module is specifically designed to BE that bridge. Every stat block lives on a lore entry. Every lore entry can be referenced from prose with automatic entity detection. Every change to a stat block is visible everywhere the entry is mentioned. The RulesLawyer agent reads the bridge in both directions and flags contradictions.
The workflow
Section titled “The workflow”Here’s how a TTRPG setting book actually gets built in Ishvana, end to end.
1. Start with a ruleset
Section titled “1. Start with a ruleset”Import a preset if your system is based on an existing framework — D&D 5e, Pathfinder 2e, Fate Core — or start from scratch if you’re building your own. The Rulesets page walks through the details. At this stage you’re making design decisions: what stats does the system track, what formulas derive from them, what abilities characters can learn, what dice notation the resolution mechanic uses.
Don’t try to get everything right the first pass. Build a minimum viable ruleset — the core stats, the core resolution mechanic, a handful of sample abilities — and expand it as you need.
2. Define categories and templates
Section titled “2. Define categories and templates”Categories group your stats visually. Physical, Mental, Social, Magic — whatever organization your system uses. Templates decide which stats apply to which kind of entity. Characters might get all six core stats; creatures might get a simplified three-stat block; items might get only a weight and a cost.
This matters because it determines what stat block shape a new lore entry gets automatically. The moment you create a new “character” entry in your setting book’s Legendry, the template decides which stats it gets pre-populated with.
3. Build your setting book in the Legendry
Section titled “3. Build your setting book in the Legendry”Now you’re writing the narrative content. Cultures, factions, nations, history, cosmology, NPCs. For NPCs specifically, you’re creating lore entries of type “character” — and because your ruleset has a template for characters, each NPC gets a stat block automatically. You fill in their Strength, Dexterity, Constitution, whatever your system tracks, and the formula engine computes their derived values on the fly.
This is the phase where you’re doing the most cross-work. You’re writing prose descriptions of characters, and in the same interface you’re assigning them stats. The two sides live next to each other. A beta reader reviewing a specific NPC can see both the prose and the stat block in a single view.
4. Design character sheets
Section titled “4. Design character sheets”When the characters are fleshed out, the Character Sheet Designer generates printable sheet layouts linked to the stat blocks. You describe the layout in natural language — “a front page with ability scores and skills, a second page with inventory and spells” — and the designer generates a CSS Grid layout. Refine it with follow-up feedback until it looks right.
Once a sheet template exists, you can generate a per-NPC instance for every character in your campaign by linking it to their lore entry. Each instance pre-fills from that NPC’s stat block.
5. Probability analysis for balance
Section titled “5. Probability analysis for balance”Run probability analysis on the core resolution mechanic, the power curves for character advancement, and the opposed-roll math for your combat system. The probability analyzer tells you whether your system’s numbers actually produce the feel you want. This is the step that kills under-tuned or over-tuned mechanics before you commit to them.
A system where the entry-level character hits DC 15 on a 45% success rate is very different from one where they hit it 75% of the time, and the difference is invisible until you run the numbers.
6. Draft the book’s prose sections
Section titled “6. Draft the book’s prose sections”The narrative chapters of the setting book — the world overview, the faction descriptions, the history — are written in Ishvana’s editor like any other prose. Entity detection picks up your NPC mentions and links them to their Legendry entries. When a reader clicks a character name in the prose, they land on that character’s entry with the stat block right there.
7. RulesLawyer pass
Section titled “7. RulesLawyer pass”Before publishing, run RulesLawyer on every chapter that references mechanical content. It catches contradictions between prose and stat blocks — “this character is described as casting a spell that requires Intelligence 15, but their stat block has Intelligence 12.” The check is advisory, not authoritative, but it surfaces the class of issues that are hardest to catch manually.
8. Export
Section titled “8. Export”Ishvana doesn’t yet have a dedicated TTRPG book publishing pipeline — Bookmaker is oriented toward novel publishing. For setting books, the current workflow is to export individual chapters as formatted documents, assemble them in an external layout tool, and produce the final PDF there. The Character Sheet Designer can print sheets directly.
Where Welcome to Tikor fits
Section titled “Where Welcome to Tikor fits”Welcome to Tikor is the creator’s own TTRPG setting book, built partly with Ishvana and partly as the proof-of-concept that drove feature decisions. If you’re looking at how a finished setting book uses this toolchain, it’s the reference implementation. The book has a narrative half (cultures, nations, deities, history) and a mechanical half (character creation, the Swordsfall d10 system, stat blocks for key NPCs) and the two are cross-referenced throughout.
Features that exist in Ishvana specifically because Welcome to Tikor needed them:
- Multiple rulesets per project. The Swordsfall RPG has a core ruleset and an experimental “advanced” ruleset; both needed to coexist without clobbering each other.
- Dice outcome bands. Swordsfall uses qualitative d10 outcome bands rather than pure numerical success/failure, and the ruleset editor needed to support that.
- Extra fields on templates. Character concepts in Swordsfall include non-numeric fields like “Patron Pantheon” and “Culture of Origin” that aren’t stats but needed to live on the stat block.
- RulesLawyer narrative mode. Catching prose that said “weak character” when the stat block said Strength 18 was a real problem in drafts, and the narrative check mode was built to catch it.
If you’re using Ishvana for TTRPG work, you’re in good company — the tool was shaped by that use case.
Where Ishvana isn’t the right tool
Section titled “Where Ishvana isn’t the right tool”A few cases where a TTRPG designer might want something else:
- Full VTT integration. Ishvana is a writing studio, not a virtual tabletop. If you want to run live sessions with dice rolling, grid maps, and turn-based initiative, you want Foundry VTT or Roll20. Ishvana’s output can feed those tools, but the play experience happens somewhere else.
- Extremely large character libraries. If your setting has thousands of NPCs and you’re generating stat blocks procedurally, Ishvana can handle it, but some dedicated TTRPG database tools may be faster for bulk operations. Ishvana’s strength is the quality of each individual entry, not bulk throughput.
- Systems with highly unusual mechanics. If your system doesn’t use stats, formulas, or dice in a recognizable shape — a purely narrative-driven system like Ten Candles, or a card-based mechanic — the Magic System module is less useful. You can still use Ishvana for the prose, but the mechanical side won’t have much to do.