Skip to content

Aelghar Interactive — Branch Overview

What This Branch Is

This is the Interactive design branch of Aelghar. It inherits the complete base design (world, economy, combat, guilds, skills, towns, expeditions, board system) and adds one rule on top:

Every activity that would passively resolve over time instead requires a minigame. Minigame score modifies the probability of the outcome.

The base project docs remain the source of truth for all world, system, and content design. This branch documents only what changes or is added: the minigame system, security model, probability integration, Phaser 3 implementation, and the mapping of each activity to a specific minigame.


Core Principle

Aelghar base: submit action → wait → server resolves → result arrives.

Aelghar Interactive: submit action → play minigame → score submitted → server applies modifier → server resolves → result arrives.

The server still controls all outcomes. Minigame score adjusts probability, not values. A perfect score cannot guarantee a drop. A zero score cannot guarantee failure on a trivial task. The modifier is bounded.


What Does Not Change

Everything in the base docs:

  • World, regions, towns, villages
  • All 57 skills and their band effects
  • Expedition system, settlement flow, stat writes
  • Board orders, crafting recipes, market mechanics
  • Guild system, governance, town simulation
  • D1 schema (this branch adds 3 tables on top)
  • Auth, sessions, security baseline
  • Cloudflare architecture, wrangler config

What Changes

Area Change
Activity submission Must attach a valid minigame_session_token to every mutating action
Settlement pass Reads minigame_score from the validated session and applies probability modifier
New D1 tables minigame_session, minigame_result
New API routes Issue session, submit result
New client routes /minigame/:type — Phaser 3 scene per minigame type
New Worker validation Session token check before any board accept, craft, gather, or trade action

Engine Choice: Phaser 3

All minigames are built with Phaser 3. Reasons:

  • Free and open source (MIT-compatible)
  • Runs entirely in the browser — no server component for rendering
  • Embeds cleanly in a SvelteKit page via a <div> mount point
  • Well-documented, stable API
  • All 12 minigame types in this branch can be built start-to-finish with Phaser 3 primitives: Tweens, Time.addEvent, Input.Pointer, Input.Keyboard, GameObjects.Graphics, GameObjects.Group, GameObjects.Sprite

Security Model Summary

The minigame runs client-side. The server cannot watch the player play. The security model works by:

  1. Server issues a signed challenge token with a deterministic seed and timing constraints
  2. The minigame uses the seed to generate its content — same seed = same content, always
  3. Client submits score + duration + event hash
  4. Server validates: signature, duration bounds, score plausibility, event hash derivation from seed
  5. Score is bounded — server caps the modifier regardless of submitted score
  6. Modifier affects probability, not values — even a "perfect" cheat only shifts odds

Full spec: see Minigame Architecture and Security.


Build and Deploy

Build:

python -m mkdocs build --config-file mkdocs-interactive.yml 2>&1 | Select-Object -Last 5

Deploy (separate Pages project):

wrangler pages deploy site-interactive --project-name aelghar-interactive