TOOLS DEVELOPMENT / MAPS & LORE
Worldkeeper
Worldbuilding, AI authoring,
and token-efficient lore export.
Worldkeeper is a desktop worldbuilding application with integrated AI tools for developing lore, generating page structure, and writing individual sections. Its structured lore export is specifically designed for AI token efficiency, using shared definitions, inheritance references, and scoped context.
An interactive map, an entity hierarchy, a block-based wiki, and a relationship graph supply the world data behind those tools. A separate browser viewer presents the world to readers.
AI-assisted authoring.
Token-efficient lore context.
AI is integrated into Worldkeeper’s content workflow and its data pipeline. Authoring tools can generate page structure and prose, while the lore exporter prepares the world’s information specifically for use as model context.
MEASURED RESULT / FULL SAVED WORLD
27.0% fewer tokens
30,379 tokens saved across the same 211 entities and 211 wiki pages.
Vaeldros saved snapshot · 2 November 2026 · tiktoken 0.14.0 / o200k_base
How the comparison was measured
Both exports use the same frozen saved snapshot, restored through Worldkeeper’s official loader. The baseline runs the real exporter with four representation optimizations disabled in an isolated benchmark build: shared chart explanations are repeated inline; inherited prose is expanded at each inheriting city; inherited climate fields and periods are expanded; and empty headings are retained.
Checks cover all 211 entities: matching chart values, properties, entity links, resolved inheritance, and the remaining lore text. The optimized export is also checked against the unchanged official exporter. Both outputs include the same image-reference IDs, with 124 image assets verified and no missing images.
The count covers the full YAML text. Image bytes, sidecar contents, chat framing, and image-input token costs are excluded. Both versions include the full world: no lore is truncated and no context-scope reduction is counted.
A second tokenizer, cl100k_base, measures 113,427 → 82,680 tokens (27.1% fewer). These are results for this saved world and these four optimizations; savings vary with the lore and tokenizer.
Generate structure and content
AI tools suggest tabs and section headings, generate text for selected blocks, rewrite existing selections, and fill empty sections. Queued generation carries earlier section results forward as context for later sections.
Control the context
Context can cover one entity, its parent, a subtree, or the world. Link-following settings expand the selection, and required inheritance sources are included so referenced facts remain available.
Multiple model providers
ChatGPT, Claude, and local Ollama integrations share the authoring workflow. Responses stream into the application through provider-specific native commands and a shared frontend interface.
Inspect context and usage
The context system exposes the assembled lore and an approximate token estimate. Provider-reported token usage is tracked separately when available, distinguishing an estimate from measured request usage.
ENGINEERING DETAIL / LORE EXPORT
Represent the world with fewer repeated tokens.
The export converts authored content into structured lore, with explicit references and shared definitions. Its token-efficiency work addresses repetition in the data as well as how much context is selected for a request.
Shared chart models
Identical resolved chart explanations are stored once in a model registry. Each chart references that definition and retains its own values. Different descriptions remain separate, preserving differences in units, scales, and author notes.
Inherited facts and overrides
Shared context points to its named source instead of repeating the same explanation in every entry. Climate export preserves source references and local overrides; explicit unknown and no-inheritance states remain meaningful.
Content-aware compaction
Empty headings and excess blank lines are removed. Chart values are extracted as structured data, and entity links are deduplicated and resolved to names.
Self-contained scoped context
Selected context includes required inheritance dependencies and a chart-model registry for the included entities. This reduces irrelevant material while keeping the definitions needed to interpret the selected lore.
Image-based maps and
editable territory geometry.
The map uses Leaflet with a simple, image-coordinate reference system. Locations, borders, and labels are positioned against the world map’s dimensions. This supports illustrated fantasy maps without requiring them to use a real-world geographic projection.
Map navigation and entities
Pan and zoom across the map, select markers, and open their wiki entries. Entities can exist in the hierarchy without a map position; mapped locations and non-spatial lore use the same underlying content system.
Shared territory borders
Territory tools edit points and shared boundaries between neighbouring regions. Realms and provinces use borders and automatic territory labels, with inherited realm colours connecting their visual presentation.
Landscape-following detail
Landscape paths add detail between border guide points. The system stores the guide geometry separately from the displayed landscape path, allowing boundaries to be refitted after edits.
Tiled viewer maps
The browser viewer can load a multi-resolution tile set in place of the full map image. A map-aligned overview sits beneath detailed tiles during zooming. The editor and untiled maps retain an image-overlay path.
Entities, content blocks,
and explicit relationships.
Locations, characters, factions, populations, languages, events, and other world elements are stored as entities. A parent hierarchy provides organisation, while wiki pages hold the detailed content associated with each entry.
Block-based wiki
Entries contain tabs and typed blocks: text, headings, images, video, infoboxes, callouts, expandable sections, and columns. The renderer handles each block type, keeping page structure separate from its presentation.
Linked templates
Wiki, tab, and chart templates provide reusable structures. Linked instances support synchronisation; optional live sync propagates edits through debounced updates.
Relationship graph
Connections are stored separately from the parent hierarchy. Each edge references a source entity, a target entity, a relationship type, and an optional note. Types define forward and reverse labels, such as “Member of” and “Has member”, or a symmetric label such as “Related to”.
Charts and timelines
Dedicated blocks include pie and bar charts, bell curves, radar charts, scatter plots, heatmaps, timelines, and climate profiles. A chart registry connects block types with their supporting logic, including conversion into structured lore for export.
A desktop editor with
a separate browser viewer.
The interface is built with Vue 3 and TypeScript, with Pinia managing application state. Tauri provides the desktop shell and access to native functionality through Rust commands. Vite builds the editor frontend and the separate viewer entry point.
Project persistence
The .wk project format serialises entities, wiki pages, connections, templates, map references, and configuration. Saved data carries a version for migration. The hierarchy is computed from entity parent relationships rather than saved as a second independent tree.
Native integration
The desktop application uses Tauri interfaces for file access, project open/save dialogs, HTTP requests, and shell integration. Native provider commands and event listeners also support streamed AI responses.
Scoped AI context
Lore context can be assembled for an entity, its parent, a subtree, or the whole world. Link-following controls expand the selected context. Integrations support ChatGPT, Claude, and local Ollama models, with generated context passed into the conversation.
Editor and reader modes
Authoring tools and the browser viewer have separate application entry points. The viewer presents the exported map and wiki data without the desktop editing controls, with desktop and mobile layouts.
Web presentation and
structured lore output.
Worldkeeper produces two distinct kinds of output: an interactive web presentation and a structured representation of the world’s lore. Each uses the application’s world data, with different handling for public presentation and authoring information.
Static viewer publishing
The publishing workflow builds the viewer and packages its map and wiki content for Cloudflare Pages. Generated map tiles provide the viewer’s tiled map path when available.
Public content filtering
A shared sanitisation step removes secret text blocks and internal template descriptions from public output. Secret blocks are removed from the exported data, including nested columns and tabs.
Structured lore export
The lore exporter supports YAML, JSON, and Markdown. It converts content blocks, relationships, chart data, and inherited lore into a representation that can be read outside the application.
Headless export
An official command-line framework loads saved world data through the application’s loading and migration path and runs the shared lore export command. It verifies the export and reports entity and image counts.
PROJECT FOCUS
Spatial editing.
Structured content.
Connected world data.
Worldkeeper combines these systems in one application: a map for spatial relationships, a hierarchy for organisation, a graph for explicit connections, and reusable blocks for presenting the detail.