ArcanaKit

ArcanaKit needed to support authored adventures that could branch dynamically while still behaving predictably across solo and multiplayer sessions.

At the same time, creators needed tools for building campaigns, adventures, scenes, encounters, routes, and outcomes—without exposing players to the complexity underneath.

The architecture therefore needed to separate authored content, published content, player state, multiplayer session state, combat state, and character progression, while still letting those systems interact cleanly at runtime.

ArcanaKit content is modeled as structured data rather than hardcoded application flows. The core hierarchy is Campaign → Adventures → Scenes → Outcomes / routing.

Browser-based React authoring tools let creators define campaigns, adventures, scenes, encounters, routing, narrative outcomes, and reusable content. Narrative routing supports deterministic routes, player-driven choices, group voting, and branching outcomes.

The player-facing React Native app interprets authored content instead of embedding individual adventures in the application. That lets the product grow through content without requiring a new app release for every story.

Creators work against mutable draft content. For an Adventure, the root document represents the current draft, draft scenes live with that structure, and published versions are stored separately—keeping the same conceptual footprint while isolating runtime content from ongoing edits.

Campaigns and Adventures are separate entities and are versioned independently. A Campaign can point to specific published Adventure versions, which matters because the same Adventure may be reused across multiple Campaigns.

When a session begins, it resolves against published campaign and adventure versions rather than following mutable drafts. A creator can keep editing tomorrow’s version of an Adventure without changing the story an active player session is currently playing.

ArcanaKit supports solo and group play using the same authored content. Multiplayer sessions maintain shared state for the active scene, player participation and readiness, group decisions, voting, combat state, active characters, and progression through the adventure.

Firestore real-time synchronization lets clients respond to shared session changes while keeping authored content and player/session state conceptually separate. The harder problem was not wiring listeners—it was defining ownership boundaries for join/rejoin flows, readiness gates, turn state, group decisions, and deterministic transitions.

Combat is not a hardcoded minigame—it is another reusable platform system. It includes turn state, player and enemy combatants, initiative, front/back positioning, abilities, HP/MP, status effects, party-size scaling, and deterministic outcome handling.

The same authored adventure can transition into combat and then return to narrative routing based on the result, without special-casing story structure in application code.

The browser-based React editor is where the architecture has to stay understandable. Creators manage campaigns, adventures, scenes, encounters, routes, outcomes, and published versions—so the underlying model has to map to something people can reason about.

A flexible narrative system is only useful if creators can see how scenes connect. That pressure shaped both the data model and ongoing work toward flow visualization for adventure structure.

ArcanaKit has been an opportunity to work across the full lifecycle of a complex product: turning ambiguous product ideas into reusable architecture, balancing creator flexibility against runtime predictability, and building systems that can grow through content rather than application complexity.

Status Active development / testing