Arcanum · How It Works · 2026

From narrative intent to
structured, playable logic.

Arcanum doesn't ask creators to build systems. It asks them to describe story intent — and converts that intent into a deterministic, testable, stateful experience automatically.

01 — The Five Action Templates

Every action a player can take originates from one of five templates. Each template hides an entire system behind a single narrative prompt. The creator chooses the template — the engine generates everything else.

01

Simple Choice

The creator defines two or more options. The system creates one branch per option and generates placeholder destination nodes automatically. No dice. No stats. Pure narrative decision — the most accessible entry point.

Example: "Open the door" / "Walk away quietly" / "Call for help"
→ System creates 3 transitions + 3 placeholder destination nodes
No dice · No stats · Structure only
02

Risk / Luck

The creator writes the action description and names the outcomes. The system applies hidden probability logic using a dice roll. The creator names the narrative outcomes — the engine determines how they resolve.

Example: "Sneak past the guard"
→ Rule: 1d20 · Fail (1–8) · Success (9–18) · Critical (19–20)
1d20 hidden probability · 2–3 outcome bands auto-generated
03

Skill Check

The creator picks a stat key and a difficulty level. The system binds the roll to the player's current stat value and evaluates against a difficulty class. The creator sets Easy / Medium / Hard — never the DC number.

Example: "Pick the lock" · Dexterity · Hard
→ Rule: 1d20 + dexterity ≥ 15 · Fail / Success / Critical
Stat-bound roll · DC 8 / 12 / 15 / 18 · Creator sets intent not numbers
04

Fight / Challenge

The creator sets a difficulty level. The system creates Lose / Win / Critical branches and wires health effects automatically. Multi-outcome combat requires zero manual rule definition from the creator.

Example: "Battle the dungeon guardian" · Hard
→ Lose: health −4 · Win: health −1 · Critical: bonus loot added to inventory
Combat-ready · Health effects auto-wired · 3 outcomes always generated
05

Advanced / Custom

Full access to the rule system: custom dice definitions, multi-condition DSL expressions, manual effect groups, and priority ordering. Power features revealed only when explicitly accessed — invisible to all other templates.

Example: has_sword == true AND luck > 3 → unlock "Hidden Path" transition
health <= 2 OR has_bandage == true → trigger "Last Stand" branch
Custom dice · DSL expressions · Full control · Always optional

02 — The Resolution Chain

Every playable action in Arcanum resolves through the same deterministic chain. Nothing is arbitrary. Every branch exists because a rule produced a named outcome — and every outcome wires to a named destination with optional conditions and effects.

resolution_chain.json · "Pick the lock" — Skill Check (Hard)action: { id: "action_041", label: "Pick the lock", template: "skill_check", node_id: "node_023" } ↓ rule: { type: "stat_check", dice: "1d20", stat: "dexterity", difficulty: "hard" // DC 15 — creator never sees this number } ↓ outcomes: [ { label: "failure", range: "1–10", priority: 1, target: "node_024" }, // "The lock holds" { label: "success", range: "11–19", priority: 2, target: "node_025" }, // "The door opens" { label: "critical", range: "20", priority: 3, target: "node_026" } // "Hidden passage found" ] ↓ transition (on success): { condition_group: { logic: "all", items: [ has_lockpick == true ] }, effect_group: [ { key: "rooms_explored", op: "increment", val: 1 }, { key: "has_lockpick", op: "set", val: false } // item consumed on use ], access_type: "free", target_node: "node_025" }

02.1 — Transition Evaluation Order

When a player reaches a transition, the engine evaluates four checks in strict order. This prevents paywalls from appearing before structural or state eligibility is confirmed.

1

Structural validity

Does the transition have a valid target node? Is the source node reachable? Are all required fields populated?

2

State conditions

Does the player's current state satisfy all items in the condition group? Logic mode: ALL conditions must pass, or ANY one condition must pass.

3

Access / paywall state

Is the transition marked as paid? If so — does the player own this transition? If not, show the locked state with purchase option.

4

Traversal + effects

If all checks pass: apply the effect group to player state, move to target node, record the State Snapshot.

03 — The Player State Engine

Every player session carries a live state object — a map of all declared variables and their current values. Four types of state, each serving a distinct narrative and mechanical purpose.

session_state.json · session_id: "sess_771" · player_id: "p_991"// ── Stats: integer values used in rule evaluation ───────────────────── stats: { health: 12, // decremented by fight outcomes — reaching 0 triggers "defeat" ending dexterity: 8, // bound to skill checks → "pick lock" resolves as 1d20 + 8 vs DC 15 luck: 3, // used in risk/luck templates and custom expressions strength: 6 // fight difficulty modifier for the current combat template }, // ── Flags: boolean story markers ───────────────────────────────────── flags: { has_sword: true, // enables "fight" action in node_019 has_lockpick: true, // required condition on transition to node_025 met_the_merchant: false, // gates merchant dialogue branch in node_031 accepted_quest: false // continuity flag — affects ending node evaluation }, // ── Inventory: item references ──────────────────────────────────────── inventory: [ "torch", "lockpick", "ration_x2", "rusty_key" ], // ── Counters: numeric progression markers ──────────────────────────── counters: { rooms_explored: 3, tension_level: 2, // increments on failed checks — triggers mood shift at 5 days_elapsed: 1 }, current_node: "node_023", snapshot_at: "2026-04-01T14:22:00Z"
📊

Stats

Integer values. Bound to rule evaluation — skill check rolls add the relevant stat to the dice result. Modified by fight outcomes and effect groups.

🚩

Flags

Boolean story markers. Gate transitions and dialogue branches. Set by effect groups when significant story events occur. Never exposed to players unless creator marks them visible.

🎒

Inventory

Item reference lists. Items added and removed via effect group operations. Item presence evaluated in condition groups to gate transitions.

🔢

Counters

Numeric progression markers. Incremented or decremented by effects. Enable tension systems, day tracking, resource management, and milestone detection.

04 — The Validation Engine

The validation panel runs continuously as the story grows. Four categories of issues — each with severity levels and jump-to-node navigation. Click any issue to teleport directly to the source node.

CategoryIssue TypeSeverityDescription
Structuralmissing_start_nodeErrorStory has no node marked as start. Cannot be published or entered by players.
Structuraldead_end_not_endingErrorNode has no outgoing transitions and is not marked as an ending. Player is stranded.
Structuralunreachable_nodeWarningNode cannot be reached from the start node via any transition path. Orphaned content.
Structuralmissing_targetErrorA transition references a target node that does not exist or has been deleted.
Logicoverlapping_outcome_rangesErrorTwo outcome bands share the same dice range. Result is ambiguous at resolution time.
Logicundefined_state_keyErrorA condition or effect references a state key not declared in State Definitions.
Logicimpossible_conditionWarningCondition can never be true given declared state type (e.g. boolean > 3).
Contentplaceholder_unfinishedWarningNode is still in placeholder status. Published stories cannot contain unfinished nodes.
Contentmissing_mediaWarningNode content_type is image or video but no media URL is set.
Continuitycontinuity_warningInfoA visually-relevant state variable changed without a corresponding scene update detected downstream.

05 — Test Mode

Creators can play their story at any stage of production. Test sessions are fully isolated from live player sessions — no test data ever appears in player analytics or story statistics.

Force Outcomes

Override any rule resolution — force Failure, Success, or Critical on any action regardless of dice roll or stat value. Test every branch without grinding through probability.

🔬

State Override

Set any stat, flag, counter, or inventory item to any value mid-session. Test edge cases, conditional branches, and ending conditions without replaying the full story.

Jump to Node

Teleport to any node in the graph without playing through it. Test deep branches in seconds, not minutes. Essential for large stories with 100+ nodes.

Rollback

Return to any previous State Snapshot. Replay decision points without restarting the session. The full session history is preserved and browsable during testing.

06 — The Data Model

Arcanum's data model has 12 core objects with clean separation between story structure, playable state, creator workflow state, and test state. Designed for validation, scale, and future versioning.

ObjectRoleKey Fields
StoryRoot container for all nodes and logicid, title, start_node_id, status, monetization_mode, visibility
Story DefaultsInitial state for a new player sessionstarting_stats, starting_inventory, starting_flags, starting_counters
NodeOne scene, step, or narrative unitnode_type, status, content_type, placeholder_summary, position_x/y
ActionSomething the player can attempt from a nodelabel, action_template_type, display_order, is_hidden
RuleThe resolution logic attached to an actionrule_type, dice_definition, difficulty_level, skill_key, custom_expression
OutcomeA named possible result of resolving a rulelabel, min_value, max_value, priority
TransitionMovement from one node to another after an outcomesource_node_id, outcome_id, target_node_id, access_type, condition_group_id, effect_group_id
Condition GroupConditions required for a transition to be availablelogic_mode (all/any), condition items: state_key, operator, expected_value
Effect GroupState changes applied when a transition is takeneffect items: state_key, operation (set/increment/decrement/add_item/remove_item), value
State DefinitionA declared state variable used in the storykey, state_type, value_type, default_value, visibility_mode, visual_relevance
State SnapshotResolved player state at a given momentsession_id, snapshot_data (map), current_node_id, created_at
Player SessionOne player's run through a storysession_type (live/test), current_node_id, ending_node_id, ending_type