Solo Narrative RPG Design Research

Source: Synthesised research from four GenAI tools (Perplexity, ChatGPT, DeepSeek, Gemini) on designing a mobile-first, solo-first narrative RPG product. Original brief framed around Ironsworn/Starforged as the underlying system. Not Kenny’s personal thinking — external reference material for the Solo Narrative RPG — Thinking project node.

---

1. Executive Summary

What this product should become

The strongest framing across all four sources converges on the same category: a “Narrative Campaign Operating System” for solo play. Not a virtual tabletop. Not a prose journal with dice attached. Not an AI storyteller. Not a writing app.

Alternative framings used across sources:

• Perplexity: “solo narrative campaign OS” — guided story engine plus campaign memory system
• ChatGPT: “local-first narrative campaign operating system” — built around scenes, vows, moves, oracles, trackers
• DeepSeek: “Campaign Operating System” — rules arbitrator, memory keeper, pacing guide
• Gemini: “Narrative Operating System (NOS)” — minimises cognitive friction inherent in the player’s three-fold role as protagonist, narrator, and mechanical adjudicator

The common thread: it is a structured fiction-first play environment, closer to a specialised journalling companion crossed with a tracker and rule reference than to any existing mainstream RPG software category.

What makes solo narrative RPG apps succeed or fail

Success patterns:

• Make play easier than paper: faster access to moves and oracles, lower bookkeeping, better continuity, less rereading
• Reduce “lookup friction” — the constant need to consult rulebooks, roll dice, and manage multiple random tables breaks immersion
• Optimise for momentum, continuity, and recall, not maximum generated or written text
• Enable players to enter a flow state where the technology disappears

Failure patterns:

• Turning play into work: too much typing, too much setup, too much screen switching
• Information trapped in ever-growing transcripts
• Demanding high “narrative debt” — forcing players to write excessive prose to maintain the feeling of a campaign
• Either being too simplistic (little more than a note-taking app) or demanding excessive prose writing that leads to burnout

Community evidence is remarkably consistent: slow journalling, burnout, lack of time, and difficulty re-entering a campaign are the dominant reasons play stalls.

The biggest UX mistakes

Synthesised across all sources:

1. Excessive writing demand — forcing players into a blank page for “journaling” before they’ve processed what happened
2. Poor state recall — failing to provide context upon resuming a campaign, forcing the player to re-read extensive logs
3. Information overload — presenting too many rules, options, and stats at once on a mobile screen
4. Treating chat history as the primary game state — chat UI is linear and makes managing persistent state difficult
5. Copying VTT metaphors built for battle maps — wrong conceptual centre for narrative play
6. Forcing players to fill forms instead of taking action
7. Hiding active goals and consequences behind multiple tabs
8. Requiring too much prose to feel “proper”
9. Failing to preserve context across interruptions — mobile UX strongly supports continuous state-saving, progressive disclosure, and quick orientation cues
10. Fragmented interfaces — when a player has to switch between character sheet, oracle PDF, and note-taking app, the mental context switch consumes limited cognitive resources

Most important product principles

• Friction is the enemy — every extra tap, text field, or screen load reduces immersion and increases the chance of session abandonment
• State over prose — the application’s primary job is to manage structured game state (vows, clocks, NPCs, locations) efficiently; player prose is an optional, secondary decoration
• Resumability is paramount — the app must be designed to be opened, played for 5-15 minutes, and closed, with zero cost to re-immersion when returning days later
• Keep the current scene and current stakes visible at a glance
• Structure what players repeatedly forget or need to update, and leave the rest to imagination
• Digital tools should support creativity rather than replace it (per Shawn Tomkin’s explicit line in his Ironsworn/Starforged digital tools guide)
• Prefer a PWA-style web product first — installable, offline-capable, cross-device by design, self-hostable in spirit, easier to commercialise later than a native-first build

How this differs from traditional VTTs

Traditional VTTs (Foundry, Roll20, Owlbear Rodeo) are built around shared scenes, maps, tokens, hand-outs, actors, compendia, and often GM-centric world structures. They emphasise spatial representation — grids, tokens, lighting.

The solo narrative product centres something fundamentally different: fictional intent, consequence, and continuity. The key questions are “What am I trying to do in this scene?”, “What changed?”, “What still matters?”, and “Why should I come back tomorrow?”

The primary differentiator is the shift from “Tactical Simulation” to “Momentum Management.”

Cross-tool insight summary

Dimension	Design Insight	Architectural Requirement	UX Implementation
Logging	Players prefer bullets over prose	Structured Markdown database	Default list-view entry with optional prose toggle
Mobile context	Mobile play is interrupted play	Persistent state and session snapshotting	”Last Scene” context cue on launch
Cognitive load	Context switching kills flow	Integrated Oracle-Journal-Move UI	Bottom-anchored action bars and overlays
Long-term motivation	Narrative continuity is the primary motivator	Relational database for NPCs/Locations	Automated tagging and hyperlinking

---

2. Understanding Solo Narrative RPG Play

The psychological structure of solo play

Solo play is characterised by a unique tension between the “Author Mind” and the “Player Mind.” A single individual must simultaneously act as the protagonist, the narrator, and the mechanical adjudicator. In systems like Ironsworn and Starforged, this tension is managed through “Moves” — discrete packets of mechanics that trigger narrative changes.

How players actually play

Ironsworn and Starforged work because they package solo play into a rhythm of vows, risky actions, progress, consequences, and oracle-driven discovery. Official materials do not assume map-heavy play; instead they provide streamlined references, progress worksheets, oracle sheets, connection sheets, clocks, and scene-challenge tools. Fate Condensed reinforces the same fiction-first philosophy: outcomes should move the story forward, with success at a cost and partial success keeping events in motion rather than stalling them.

A typical turn follows a loop: envision the scene, declare an action, determine if a move is triggered, roll dice, and interpret the outcome with the help of oracles. Beginners often treat this as a creative writing prompt, producing voluminous prose. Experienced players internalise the moves and use oracles for quick inspiration, logging results in concise bullet points or structured data to maintain momentum.

How much people actually write

The practical answer: usually less than beginners expect, and less over time. Community evidence shows that “journalling” is often not polished prose at all, but a mix of shorthand, bullet points, script fragments, margin notes, voice recordings, or short post-scene summaries.

Players regularly report that long-form prose is enjoyable in small doses but slows play down when used for every beat. Several community threads explicitly recommend one paragraph per scene, checkpoint notes, or “just the parts you like writing about.” Patrick Buechner’s Soloist piece makes the same point: “journalling” can mean shorthand symbols, rough notes, doodles, or voice notes — not literary output.

Why people stop playing

The dominant killers are not rules complexity alone — they are energy cost and re-entry cost.

• Solo players describe the hobby as “too much work” when they must both play and perform their own logging, prompting, bookkeeping, and continuity management
• Others describe burnout after only a few sessions when writing volume or setup overhead outruns the fun
• Long logs become their own penalty: they preserve everything but make the useful parts harder to retrieve
• The “memory problem” is the single biggest killer of long-term games. What are my vows? Who is this NPC again? Why am I on this planet?
• Without a robust state system, players must re-read long journal entries to rebuild mental context — a process so tedious it often prevents resumption entirely

What experienced players do differently

More experienced solo players compress. They keep scene titles, checkpoint notes, single-line consequences, or brief “what changed” entries. Some write fuller prose afterwards if they still feel inspired. Others keep a fixed cap such as one paragraph per scene or a bullet list per encounter.

The pattern is consistent: raw experience comes first, polished writing second, if at all. Experienced players use “mechanical shorthand”: they roll first, interpret second, and record only the “narrative pivot.”

Experienced players also prioritise “Imagination over Automation.” They do not want a video game that plays itself; they want a catalyst that forces them to make difficult choices.

How players manage memory and continuity

Players use whatever system most quickly answers four questions:

1. Who matters
2. What happened
3. What is unresolved
4. Where to resume

That is why people gravitate to handwritten notebooks, markdown files, wiki-style notes, Discord channels, and linked vaults. In practice, players want a hybrid: enough structure to retrieve old information quickly, but enough freedom to jot down a scene without wrestling a database.

Sustainable campaigns rely on externalising the “Game Master’s Memory.” A solo player cannot hold every NPC’s motivation, every unresolved thread, and every mechanical bonus in their head simultaneously.

How oracles are actually used

Oracles are used as creative constraints, not just random generators. A solo player uses an oracle to provide the “Unexpected Input” that a GM would normally provide. The best tools allow for quick, contextual oracle rolls (e.g., “Action + Theme” tables) that inspire the next logical step without overwhelming with options.

The digital tool’s role is to reduce the time between the “Oracle Query” and the “Narrative Interpretation.”

Immersion vs speed balance

Immersion comes from meaningful consequence, not verbose description. A fast-paced, reactive game where choices matter is more immersive than a slow, beautifully written one that feels static.

Common player workflows analysed

Workflow	Pros	Cons	Sustainability
Handwritten Journal	High tactile immersion, no digital distraction	No search, slow writing, physical storage	Low (Fatigue)
Obsidian / Notion	High organisation, custom databases	High setup friction, “tinkering” trap	Medium (Fragile)
Discord Logging	Low friction, mobile-native	No mechanical integration, poor state tracking	Medium (Chaos)
Dedicated Solo Apps	High integration, low setup	Feature rigidity, data lock-in	High (Flow)

Obsidian is favoured because it stores notes as local Markdown files in a vault and supports dense linking and wiki-style organisation. Notion is used when database-style views, wikis, and structured workspace conventions are wanted. Discord gets used because channel separation provides an easy way to split scenes, lore, characters, and logs without designing a bespoke system.

The recurring lesson is not “use these tools” — it is that solo players want searchable summaries and linked entities, not giant undifferentiated text dumps. These tools succeed at state management but fail because they require heavy upfront setup and lack deep integration with the game’s specific move mechanics. The “prep-to-play” ratio is often too high for casual users.

---

3. Core Product Philosophy

What to optimise for

Optimise for the speed of the interpretive loop. The time between asking “What happens next?” and knowing the mechanical and narrative outcome should be as close to zero as possible. This is “the speed of thought” — the interface should move out of the way once an action is initiated.

Comparing interface paradigms

Paradigm	Verdict	Reasoning
Prose-heavy journaling	Fails	Maximum friction, discourages play, makes state recall impossible
Lightweight bullet logging	Succeeds	Fast, state-focused, easily scannable for resumption — the baseline
Structured narrative tracking	Succeeds as core	Moves beyond logging to actively manage game objects (NPCs, locations, vows) as living data — the target state
Chat-based interface	Fails	Linear, hard to manage persistent state, hard to recall context
Scene-based interface	Succeeds	Best for active play, supports state-management framing
Card-based interface	Succeeds	Strong for action/move selection, good mobile fit
Visual novel style	Mixed	Useful inspiration for rhythm, less so for engine
Campaign OS approach	Winning paradigm	App as dashboard surfacing current state and context-sensitive actions

What should be structured vs freeform

Element	Structured (App Managed)	Freeform (Player Managed)
Character Stats	Health, Spirit, Momentum, Supply	Personality, appearance, inner monologue
Progress Tracks	Vows, Combat, Journeys, Clocks	Sensory details of the struggle
NPCs	Relationships, status, location	Dialogue, specific mannerisms
Oracles	Random table generation and results	Final interpretation of the result

Structured: Character stats, health/spirit/supply/momentum, vow progress tracks, relationship maps, location connections, oracle results.

Freeform: The player’s narrative interpretation of oracle results and the in-character dialogue they imagine. The app should provide a small, optional text field for a “Scene Snapshot” — a 1-2 sentence summary of what just happened — not a full journal entry.

How to preserve imagination without over-automating

The app should never narrate for the player. Its job is to say: “The oracle suggests a Corrupted Official in a Vaulted Hall who wants Revenge. Your risky move was a Miss. What does this look like?”

The player’s imagination is the rendering engine; the app is the physics and RNG system that provides its inputs.

The “Signifier-First” philosophy (Gemini)

The default logging mode should be “Signifier-First.” A signifier is a short, punchy note that captures a state change: “The King is angry,” “The sword is broken,” “The fuel is leaking.” By focusing on signifiers, the player builds a web of narrative causality that the computer can track and surface when relevant. This preserves the player’s imagination by handling the logical bookkeeping of the world while leaving sensory details to theater of the mind.

Reducing friction per turn

Every turn involves declaring intent, choosing a move, rolling, interpreting. A digital tool reduces friction by:

• Automating the “Math of the Move”
• Providing “Semantic Suggestions” based on oracle results
• Triggering relevant follow-up prompts in context (e.g., if a player rolls a “Miss” on Face Danger, the app instantly offers a “Pay the Price” oracle in a pop-over)

---

4. Core Gameplay Loop

The Define → Resolve → Record → Reflect cycle

The ideal mobile-first loop is a cycle of “Define, Resolve, Record, and Reflect.” For solo play, this loop must be robust against interruptions — the “asynchronous resume” is not just a feature, it is the core constraint of the mobile environment.

1. Define — Player sets the scene by selecting a “Narrative Anchor” (current quest or location). App surfaces relevant “Tensions” (clocks or threats) associated with that anchor.
2. Resolve — Player declares intent. App provides a “Context-Aware Move Selector.” Combat moves are prioritised if in combat. Dice roll is one tap.
3. Record — Player logs the outcome. Default is a bullet point. Strong Hit highlights rewards. Miss triggers a “Consequence Flow.”
4. Reflect — App updates campaign state. Progress track ticks, momentum adjusts, NPC status changes. App prompts for “Scene Closure” summary if objective met.

Detailed loop with mechanical pivot

1. Session Resume — Player opens app, lands on Current Scene Screen (not main menu). “Previously On…” micro-summary available with one tap.
2. State of the Scene — Screen shows objective, current tension (progress clock), active NPCs/threats.
3. Declare Action — Hybrid interaction. Predominant feature is a context-sensitive action bar showing 3-4 most relevant moves. “Face Danger,” “Compel,” “Gather Information” are prominent buttons, not hidden in a menu.
4. Execute Move & Roll Dice — Tapping triggers relevant stat adds and rolls dice. Result (Strong Hit, Weak Hit, Miss) displayed instantly with clear visual feedback.
5. Consult Oracle — If result is Miss or Weak Hit requiring a twist, “Pay the Price” or “Ask the Oracle” prompt appears inline. Player taps, oracle fires off, returns result.
6. Update State — Progress track ticks, momentum adjusts, scene updates.
7. Close Scene — When objective met, app prompts for one-sentence summary, updates campaign-level state, suggests next scene.

Comparing interaction models

Model	Strength	Weakness
Chat-style	Conversational flow, intuitive	Linear, weak for state recall
Action-button	Fast, low typing burden	Can feel rigid if overdone
Hybrid (buttons + optional text)	Balanced — speed plus expression	Requires careful UI design
Structured move cards	Mechanically clear, scannable	Can feel transactional
Expandable narration	Supports depth on demand	Easy to overuse

Recommended interaction model: Hybrid cards + buttons + short optional text. Chat-like narration available but never required. One-tap moves, one-tap rolls, in-place consequence handling, extremely low typing burden, prose optional and collapsible.

Asynchronous resumption mechanics

Each interaction is a “Turn” that updates persistent state of the world (current location, active NPCs, quest progress, story momentum). The turn-based structure lets the player leave and return later, with the AI/system providing a “Recap” function based on the latest state snapshots.

---

5. UX and Information Architecture

The Limited Viewport Problem

Information architecture for mobile solo RPGs must solve the “Limited Viewport Problem” — the screen cannot show character sheet, journal, and world map simultaneously. The solution is Progressive Disclosure based on Active Context.

Screen hierarchy

Home/Launch Screen — “Resumption Interface”

• Should NOT show the whole campaign
• Shows a “Recap Card” of the last 3 entries and current “Active Objective”
• Minimises cognitive load required to restart a session

Current Scene Screen — Primary Workspace

• Persistent “Bottom Action Bar” with buttons for Moves, Oracles, Dice
• Central area is the “Narrative Feed” — vertical scroll of session’s bullets and roll results
• Always visible: current objective, scene tension/clock, active NPCs

Character Dashboard

• Accessible via side-swipe or bottom tab
• High-contrast “State Toggles” for health and resources
• Progress tracks as “Radial Gauges” or “Linear Bars” — easily tappable for increments

Campaign Dashboard

• Aggregates long-term state: vows, NPCs, locations
• Searchable, taggable
• Timeline/history view

What should be where

Visibility	Content
Always visible	Current scene objective, active stakes/clock, primary action buttons
Collapsible	Character sheet details, NPC roster, location lore
Summarised	Past scenes, completed vows, resolved threads
Searchable	Full timeline, all entities, all logged events

First-class entities

Recommended information architecture treats these as first-class entities, each with structured fields and links to scenes that created them:

• Current scene
• Vows
• Progress tracks
• NPCs
• Locations
• History/timeline

Search and summaries are the main retrieval tools — not full-text scrolling.

---

6. UI Paradigms Comparison

Strengths and weaknesses by paradigm

Paradigm	Strengths	Weaknesses
Chat UI	Good for conversational flow	Weak for long-term scanning unless paired with strong summaries and pinned state
Card UI	Excellent for action/move selection, mobile-friendly, scannable	Can feel fragmented if overused
Notebook UI	Natural for solo RPGs, supports prose	Can become too text-heavy and hard to navigate on mobile
Timeline UI	Excellent for continuity and return-after-break play	Less suited for active play
Scene-based UI	Best for active play, supports state-management framing	Needs supporting layers for history
Kanban/task-based UI	Fits vows and threads well	Not enough on its own for fiction-first play
Interactive fiction UI	Useful for branching, conditional logic	Authored branching doesn’t fit open-ended campaign
RPG dashboard UI	Useful for persistent state	Can become cluttered if it tries to show too much

Recommended combination

The best combination is a scene-based primary surface with a timeline/history secondary surface and a compact dashboard header.

Pure chat, pure notebook, or pure productivity layouts tend to miss the emotional and procedural needs of solo narrative play.

Gemini’s “Hybrid Scroll” framing: narrative exists as a vertical feed of markdown-styled bullets, with “Mechanical Cards” (Moves, Rolls, Oracles) interspersed. Allows chronological reading while maintaining mechanical scannability.

---

7. Writing vs Gameplay Balance

Why over-writing reduces enjoyment

Users consistently report that writing everything down bogs down flow, while bullets and short summaries preserve momentum.

Over-writing becomes fatiguing because it forces the player to act as both game master and novelist at every moment, increasing cognitive load and delaying the next decision.

How much narration is actually useful

The sweet spot: usually a sentence or two per meaningful beat, plus occasional richer prose only for emotionally important scenes or especially vivid moments.

The “prose as reward” pattern

The best design pattern is to treat prose as a reward layer, not a requirement. The system should explicitly legitimise bullets, placeholders, and short scene notes so players do not feel they are “doing it wrong” when they prefer brevity.

Pacing over verbosity

The product should encourage compact logs by default, with optional “expand this moment” affordances for players who enjoy writing.

What kinds of writing create emotional engagement: short, vivid, consequence-anchored notes that capture state changes. What creates fatigue: obligatory descriptive prose for every beat, forced “complete sentence” logging, blank-page anxiety.

---

8. Scene and Narrative State Design

Scenes as bounded state units

Scenes should be treated as bounded state units with a purpose, immediate stakes, and a closure condition.

A useful digital model: scene → events → consequences → structured updates. The app should not merely store a transcript; it should transform play into usable campaign memory, including progress changes, threat updates, and a one-line “why this matters” summary.

What persists, what decays

Persists permanently:

• Vows (active long-term goals)
• Ongoing threats
• NPC relationships and status
• Locations
• Discoveries
• Unresolved questions/threads
• Progress tracks and clocks

Decays / summarised after scene closes:

• Transient scene details
• Dialogue specifics
• Descriptive colour
• In-the-moment tactical state

Clocks and progress tracks should persist because they represent latent narrative pressure. Ephemeral dialogue and descriptive colour should be summarised and archived. This supports both speed during play and clarity when returning later.

Scene structure recommendations

For each scene, the app should track:

• Objective (what the player is trying to achieve)
• Threats (what’s working against the player)
• Tensions (clocks/progress that create pressure)
• NPC involvement (who’s in this scene, and why they matter)
• Unresolved threads (what’s still hanging)
• Consequences (what changed)
• Discoveries (what was learned)
• Momentum (mechanical and narrative)

---

9. Memory and Persistence

The right amount of memory

The best continuity systems are not the most detailed ones; they are the ones that make it easy to recover the right context quickly.

Players benefit most from:

• Short recaps
• Searchable entity lists
• Timeline views showing what changed (not just what was written)

Memory overload patterns

Memory overload happens when the app stores too much unstructured text without a way to collapse it into significance. The product should combine:

• Semantic-ish search
• Structured tags
• Summaries
• Chronological event log

— so players can answer “what was happening here?” in seconds.

The lean encyclopedia principle

A world encyclopedia is helpful only if it stays lean and entity-driven. Best practice: store the smallest durable truth about each NPC, location, vow, and thread, then link those entities to the scenes that created them.

How players recall old context efficiently

Recap systems should answer four questions quickly:

1. Who matters now
2. What was happening
3. What is unresolved
4. What I’m about to do

Long-term continuity practices

• Episodic memory via summaries
• Structured entity records
• Timeline view of state changes (not text dumps)
• Linked references (NPC → scenes they appeared in, etc.)
• Bookmarking key scenes and threads

---

10. Critical Features and Functions

Must-have MVP

• Campaign management
• Scene tracking
• Character sheet and core tracks
• Vow/progress tracking
• Oracle tools (with quick contextual access)
• Dice rolling
• Move reference (context-aware, not buried)
• Session summaries and quick recap
• Searchable history
• Local persistence / offline-friendly storage
• Tension clocks for scene threats and journeys

Important (Phase 2)

• NPC tracking
• Location tracking
• Relationship tracking
• Markdown support for notes
• Export/import
• Backup/recovery
• Bookmarking key scenes and threads
• Simple timeline/history
• Searchable, taggable timeline view
• Simple account system for cloud sync

Nice-to-have

• Child-friendly cooperative mode
• Reminders/notifications (only if tied to unresolved vows or pending scene prompts)
• Multiple campaign templates
• Voice input
• Custom oracle packs
• Optional visual enhancements that do not slow play
• Tightly-scoped AI for oracle inspiration (NOT narration)
• Lightweight “World Truths” reference (e.g., for child-friendly mode)

Dangerous distractions (avoid)

• Rich-text journal editor — will cannibalise play
• AI-driven game mastering that narrates player actions — destroys agency, makes the game unidirectional
• Tactical maps — wrong product category
• Token movement — same as above
• Heavy multimedia effects — slow loads, distract from flow
• Social feeds — build the play tool first
• Complex multiplayer sync infrastructure — premature
• Character portrait / image generation — adds latency, doesn’t improve gameplay loop
• Features that prioritise “content creation” over play flow

The principle

Features that sound attractive but harm gameplay flow: anything that turns the app into a place to produce content rather than play. The “writing app” temptation is the strongest version of this trap.

---

11. Existing Products and Lessons

Focused solo companions

Iron Journal and Stargazer — clearest proof that a browser-based, mobile-friendly, solo-first PWA is viable and attractive. Mobile-friendly experience, local browser storage, installability, export/import backup. Lesson: zero-account startup, local ownership, and quick tool access beat sophistication for early solo products.

Ironsworn Companion — explicit about being a digital toolkit, not a rules replacement. Designed to reduce paper waste, surface oracles quickly, log events automatically, keep play moving. Lesson: terse event capture is more valuable than ornate journalling tools in the core loop. Fails when it doesn’t evolve past a digital character sheet into a campaign manager — integrate state management, not just rolling dice.

The Augur and Pocketforge — appeal of broader control surfaces: journalling, procedural generation, custom rules, NPCs, locations, offline mode, exportable journals. Value is breadth; risk is scope creep. Lesson: borrow their useful breadth later, not their initial complexity now.

Iron Vault (Obsidian plugin) — extremely powerful because it fuses Obsidian’s note model with system-aware blocks, rulesets, tracks, and mechanics. Presents itself as something to use piecemeal rather than a single mandatory mode of play. Lesson: power users want deep control, but they also want selective adoption.

General VTTs and workspaces

Foundry VTT — outstanding self-hosted framework; the Ironsworn/Starforged implementation is praised for smooth UI, accessible moves and oracles, easy progress/asset management. But Foundry is still a general VTT built around Worlds, Scenes, Journal Entries, Actors, Items, compendia. Excellent for flexible web-hosted play; not the right conceptual centre for a mobile-first solo narrative product.

Owlbear Rodeo — intuitive, browser-based, responsive, polished. Openly defines itself around a shared play-space, battle maps, tokens, fog, drawing. Best lesson: not what to emulate, but what to avoid as a primary metaphor. Useful for mobile-friendly browser UX and low-friction session access patterns.

Obsidian and Notion — the two poles of long-term campaign memory. Obsidian gives local Markdown, vault ownership, dense linking. Notion gives docs, projects, wikis, offline-capable apps. Lesson: solo players want ownership plus retrievability. The product should deliver both without requiring the player to become a PKM enthusiast first.

AI and interactive-fiction tools

AI Dungeon — demonstrates appeal of endless narrative response and layered memory tools (summarisation, memory banks, Story Cards). Lesson: long-form narrative systems need compressed summaries and relevance-triggered recall. Danger: optimises for generated text rather than for campaign procedure and player-owned canon. Lacks meaningful, persistent consequences — produces a story you’re reading, not a game you’re playing.

NovelAI — optimised for creative writing and image generation, not procedural solo campaign play. Useful as a warning: a writing assistant is not the same product as a narrative RPG companion.

Twine — excellent for interactive, nonlinear story structures with variables and conditional logic. Lesson: scene nodes, state variables, expandable passages are useful ideas for UI. But authored branching should inspire interface rhythm, not define the engine of an open-ended campaign tool.

SillyTavern and character.ai — state-of-the-art for “pure” roleplay with AI NPCs. Character cards define personalities but lack integrated game systems. Inspiration for character card format, but must exceed these by integrating rules logic directly.

Echoes of Fate — core design principle worth noting: “strict systems first, AI second” for long-term coherence.

Commercialisation and architecture (Ironsworn/Starforged specifics)

Dataforged and Datasworn — official JSON schemas and licensed data for moves, assets, oracles, related content, with support for homebrew and third-party content. Strategically important if the project becomes public or commercial.

Licensing boundary: Textual rules data is available under Creative Commons terms, but some raster images in the Starforged data package are non-commercial. Do not design a commercial product around bundled art unless you have separate rights.

Cross-product gap analysis

The landscape shows a clear gap between rigid journaling tools and overpowered AI story generators.

Tool category	Strength	Gap
Ironsworn Companion / Iron Journal / Stargazer	Mechanics (dice, moves, oracles)	Don’t evolve into campaign managers
The Augur / Foundry VTT	Powerful, feature-rich	Over-engineered, high friction
Obsidian / Notion	Infinitely flexible	Not game-aware; player builds whole system
AI Dungeon / NovelAI	Endless narrative response	No real risk, no persistent consequence

---

12. Mobile-First Design

Thumb-friendly principles

• Primary Move Action Bar at the bottom of the screen
• All core actions (rolling, advancing scene, marking progress) achievable without adjusting grip
• Large action targets (44px minimum)
• Bottom-aligned primary controls
• Sticky bottom navigation
• Swipe-based transitions

The mobile thumb-zone model

• Easy Zone (bottom 30-40%): primary actions, moves, oracles, dice
• Stretch Zone (middle 30%): narrative feed, secondary toggles
• Hard-to-Reach Zone (top 30%): read-only information (quest name, health bars)

Mobile interaction patterns

• Haptic Confirmation — physical “pulse” when a die hits or vow completes adds sense of “weight” to digital play
• Pull-to-Oracle — pull-down gesture triggers a “Quick-Oracle” search bar
• Ambient Persistence — save after every character typed and every die rolled; OS can kill the app at any moment (incoming call, etc.)

Mobile metrics targets

Metric	Goal	Design Implementation
Typing burden	Low	Signifiers, voice-to-text, oracle insertion
Tap targets	44px minimum	Large rounded buttons for Move categories
Resumption time	< 10 seconds	Launch directly into active scene with context recap
One-handed use	> 90% of flows	Sticky bottom nav, swipe transitions

Session interruption / recovery

App state must be atomic. Closing the browser tab or app mid-roll keeps state exactly as it was. A “Session Resume” screen is the first and only thing the player sees on startup.

Low typing burden

• Buttons, sliders (for progress tracks), pre-populated options replace free-text fields wherever possible
• Voice-to-text as first-class input for “Scene Snapshot” on mobile
• Progressive detail expansion — compact summary first, dig deeper only if needed

Offline-first PWA

Non-negotiable technical requirement:

• Tiny JavaScript payload
• Server-side rendering for initial load speed
• Full functionality without internet connection
• “An app that can’t be played on a plane or in a subway tunnel is a broken tool for its core audience”

Notifications

Useful only if tied to unresolved vows or pending scene prompts. Generic productivity nags will harm the product.

---

13. Child-Friendly Co-op Mode

Architectural foundations

Architectural decisions made today that support co-op later:

• Separate narrative state from presentation — same core campaign engine supports adult solo play and simplified co-op play
• Structured entities, templated prompts, flexible scene rendering
• Future-proof — more flexible than a pure prose journal or chat log

Why Ironsworn fits children

Ironsworn’s core mechanic centres on “Yes/No/But” logic rather than complex math. Well-suited for children once UI adapts.

Visual prompting

System must allow “Card-Based Storytelling” (modeled after Storybird or Toontastic). Instead of an oracle result saying “Surreptitiously Undermine,” app shows image of a “Sneaky Shadow.”

Role distribution (parent ↔ child)

Stage	Child’s Interaction	Parent’s Interaction
Framing	Picks a “Character Card” (e.g., The Knight)	Sets the “Quest Card” (e.g., Find the Dragon)
Action	Taps the “Brave” move; shakes phone to roll	Interprets result into a story beat
Refining	Chooses from 3 visual oracle options	Logs the choice into campaign history

Simplified action UI

The “Action Bar” UI simplifies to 2-3 large, colourful, icon-driven options:

• “Sneak Inside?”
• “Talk to the King?”
• “Investigate the Noise?”

Parent makes selection, app handles dice and oracle, result is a creative prompt for parent-child discussion.

Safety and guidance

• Safety tools like the X-card or Lines/Veils — crucial for parent-child play to keep story emotionally safe
• Caregiver-approved content boundaries
• Collaborative choice selection
• AI narration as non-goal means safety risk is minimal and fully controllable via oracle tables loaded for child-friendly campaigns

Shared visual state

A child can’t parse a wall of text but understands a picture of a character and a progress bar. Scene dashboard with NPC portraits, clocks, clear objective text becomes the shared tabletop.

---

14. Product Strategy and Vision

The strongest product direction

Position the product as a “Solo Narrative Campaign Companion” or “Narrative Workspace” — not a VTT, not a notes app, not an AI chat RPG.

Category: “Structured fiction-first play environment.” Closer to a specialised journalling companion crossed with a tracker and rule reference than to any existing mainstream RPG software category.

Tone: “Play faster, remember better, imagine more” — not “write more” or “automate everything.”

What it is NOT

• Not a VTT — no tactical maps, token movement, combat simulation
• Not an AI Chat RPG — does not write the story, narrate actions, play NPCs; enforces rules and provides inspiration
• Not a writing app — it’s an “interpreting and managing” app

How it differs from AI chat RPGs

In an AI-only game, there is no real risk because the AI will often “narrate around” failure. In an Ironsworn-based product, the dice provide the “Truth” that the player (and any AI involved) must both respect.

Focused MVP

MVP (Solo-First):

• Solo-only
• Single system (Ironsworn or Starforged)
• PWA
• Local-first storage
• Character + vows + moves + oracles + current scene + terse logging + summaries + export/import

Roadmap

Phase 2 — Continuity Update:

• Richer NPC/location/relationship tools
• Timeline view
• Better recap and search
• Homebrew/custom tables
• Optional account sync
• Co-op scaffolding
• Semantic memory and automated recaps
• Turns app from tracker into “Lore-Keeper”

Phase 3 — Co-op Update:

• Simplified UI toggles
• Visual oracle support for parent-child play

Phase 4 — Commercial:

• Hosted sync (paid tier)
• World Sharing
• Possibly an “AI-Oracle” trained on player’s campaign lore for hyper-relevant prompts
• Publishing/export polish
• Broader system architecture after Ironsworn/Starforged loop is genuinely excellent

Where most projects fail

• Trying to support every possible RPG workflow
• Overbuilding visual presentation
• Putting too much of the experience into long-form text entry
• Becoming “Foundry for Mobile” instead of “Notes for Adventurers”

The project succeeds if it becomes “Notes for Adventurers” — a tool that feels as essential and invisible as a physical notebook, but with the “Magic” of a digital Game Master built into its core.

---

15. Final Recommendations

UX paradigm

Scene-based UI with a compact dashboard header and a timeline/history drawer. Or, framed differently: a scene-based shell with card-based actions, a notebook/timeline history layer, and a light vow/thread board. Avoid chat-first as the main container.

Alternative framing (Gemini): “Hybrid Scroll” — vertical feed of markdown-styled bullets with mechanical cards interspersed.

Gameplay structure

Resume → recap → intent → move → roll → oracle → consequence → update → close.

Resume into a current scene, act through contextual moves and oracles, update progress in place, close with a one-line summary plus unresolved thread.

Scene-based containers: every action housed within a scene. Closing a scene triggers automated summary that updates world state and clears “mental cache.”

Interaction model

Hybrid: cards + buttons + short optional text. Chat-like narration available but never required.

• One-tap moves, one-tap rolls
• In-place consequence handling
• Extremely low typing burden
• Prose optional and collapsible

Thumb-zone priority: all high-frequency actions (moves, oracles, dice) anchored to a bottom “Smart Bar” that changes based on active scene context.

Information architecture

• Home → Campaign → Scene as primary navigation spine
• History, search, secondary trackers accessible but not dominant
• Current scene, vows, tracks, NPCs, locations, history as first-class entities
• Search and summaries as main retrieval tools
• Contextual progressive disclosure — screen displays only what is needed for the current task; character stats one swipe away; deep lore hyperlink-only

Feature prioritisation

Build order:

1. Dice Engine
2. Character State
3. Move Action Bar
4. Oracle Integration
5. Vow Tracker
6. Scene History
7. PWA

Continuity and pacing first, power tools second. Avoid tactical simulation, heavy multiplayer, AI-authored narration until the solo loop is unquestionably good.

Persistence model

Local-first, resilient, exportable, structured around durable entities and concise scene summaries.

• Structured game objects (vows, NPCs, locations) permanently persistent and queryable
• Narrative logged as time-stamped, structured sequence of “Scene Snapshots,” not a monolithic text file
• Manual export/import from day one
• Optional sync later
• Atomic autosave — every change saved locally in real-time
• Launch experience built around “Contextual Re-entry” — summarising current state to overcome activation barrier

Product philosophy

Preserve imagination, reduce friction, make “a little progress tonight” feel easy enough that the game stays alive for months instead of dying after the first enthusiastic session.

Alternative framings worth holding:

• “Momentum over Fidelity” — prioritise speed of generating the next story beat over complexity of mechanical simulation
• “Be an invisible dungeon master who never speaks” — manages world’s physics, luck, and memory with perfect, frictionless reliability, leaving all imagination and glory to the player
• “Silent Partner” in the storytelling process

The app should help the player play a campaign for months on a phone, in short bursts, without losing the thread and without feeling obliged to write a novel. If the app makes that easy, it will have achieved something most solo tools still only approximate.

---

Source attribution notes

This synthesis preserves the strongest unique signal from each source:

• Perplexity — strongest on community evidence patterns and player workflow research; balanced framing across all sections
• ChatGPT — strongest on commercialisation/licensing (Dataforged, Datasworn, CC boundaries) and competitive analysis depth
• DeepSeek — strongest on operational precision: clear pass/fail verdicts on paradigms, sharp distinction between structured vs freeform, “speed of interpretive loop” framing
• Gemini — strongest on systems theory: “Author Mind vs Player Mind,” “Narrative Operating System” framing, “Signifier-First” philosophy, thumb-zone UX model, three-fold role framing

Where sources agreed strongly, the synthesis carries the converged view. Where they diverged on framing, both framings are preserved with attribution.