Skip to content

Quick Play End-To-End Plan

Purpose

This page defines the Quick Play mode for the WPF client.

Quick Play exists so a player can get straight into gameplay without consuming story content, tutorial framing, or full hero onboarding.

The player should:

  • choose a faction
  • choose an eligible class
  • receive the correct faction passive, class mechanic, and starter loadout
  • enter a randomized three-realm run

The player should not be required to:

  • select or create a campaign hero
  • consume opening-story content
  • consume quest-authored intro content
  • step through lore-heavy builder screens

Product Rule

Quick Play does not use the player's hero.

That means Quick Play should be modeled as its own run mode rather than a shortcut into hero progression.

This is important for three reasons:

  1. it avoids spoiling story beats tied to hero or faction onboarding
  2. it avoids polluting hero progression or save slots with random testing runs
  3. it lets players sample the game loop with minimal overhead

Quick Play should be a hero-less run mode.

Recommended implementation rule:

  • campaign runs: tied to a real HeroId
  • quick play runs: no HeroId, but always require ClassId and FactionId

Do not create hidden throwaway heroes under the hood unless that becomes absolutely necessary for compatibility. That would blur progression, save ownership, and story state in ways that will be expensive to untangle later.

Required Backend Adjustment

The current run-start contract requires HeroId, ClassId, and FactionId, and the WPF client currently only sends HeroId.

For the intended Quick Play mode, the API contract should change to support:

  • HeroId optional
  • ClassId required
  • FactionId required
  • explicit run mode metadata so Quick Play runs do not collide with hero runs in active-run lookup

This matters because the current active-run repository query treats heroId = null as "latest active run for this user," which is too ambiguous for a world where hero runs and Quick Play runs can both exist.

Add an explicit run mode field, such as RunMode or EntryMode, with values like:

  • Campaign
  • QuickPlay

Then enforce these rules:

  • one active campaign run per hero
  • one active Quick Play run per user
  • Quick Play resume looks up the active run by user plus RunMode = QuickPlay
  • campaign resume looks up the active run by hero plus RunMode = Campaign

WPF Flow

Quick Play should become this flow:

  1. Main Menu
  2. Quick Play Setup
  3. Run Briefing
  4. Realm Map
  5. Combat Encounter
  6. Reward And Event
  7. Sanctuary And Recovery or Rest Site
  8. Save, resume, abandon, victory, or defeat

Current WPF implementation status:

  • the full Quick Play shell is now playable end to end in WPF
  • the main menu resumes an active Quick Play run when one exists, otherwise it opens Quick Play setup
  • the playable loop currently uses a deterministic three-realm sequence built from supported node types only
  • combat uses the shared Core combat state machine rather than a fake placeholder ruleset
  • save and resume are currently guaranteed at node boundaries rather than in the middle of combat

Quick Play Setup Scope

The Quick Play setup screen should be intentionally narrow.

Current implementation status:

  • the WPF shell now has a real Quick Play Setup screen
  • the WPF shell now has a real Run Briefing screen that consumes the saved faction and class selection
  • shared game-data DTOs now carry faction passive summary text, class innate summary text, starter cards, and starter relic placeholders into the setup and briefing flow

It should include:

  • faction choice
  • eligible class choice
  • passive and mechanic summary
  • starter deck or starter loadout summary
  • random seed display if useful for feedback
  • one clear Start Quick Play action

It should not include:

  • story text blocks
  • codex-style lore panels
  • portrait setup
  • deep name or identity authoring
  • campaign progression framing

First Concrete Milestone

The first end-to-end milestone should be:

Main Menu -> Quick Play Setup -> Run Briefing -> Realm Map -> one Combat Encounter -> Reward -> Sanctuary Save -> App Restart -> Resume Quick Play Run

That is enough to start collecting feedback on:

  • class and faction feel
  • combat readability
  • map pacing
  • reward clarity
  • recovery flow
  • save and resume behavior

Concrete Deliverables

The implementation should produce these concrete outputs:

  • add explicit Quick Play run mode to run persistence and lookup
  • make HeroId optional for Quick Play run start
  • add a real WPF Quick Play Setup screen for faction and class selection
  • add a real WPF Run Briefing screen that confirms the locked Quick Play selection before entering the map
  • ensure Quick Play applies the correct faction passive, class mechanic, and starter cards
  • build a randomized three-realm run flow with no storyline dependency
  • support Quick Play save, app restart, and resume
  • keep Quick Play progression isolated from hero story progression

Current simplifying assumptions in the playable slice:

  • map progression is deterministic and linear within each realm for now
  • unsupported authored data falls back to safe starter cards, enemies, relics, and events so the run remains playable on incomplete content sets
  • mid-combat resume is intentionally deferred; the save boundary is before entering a combat node and after resolving a node

Definition Of Done

Quick Play is considered correct when:

  • a player can start Quick Play without selecting a hero
  • Quick Play never shows story onboarding content
  • the chosen faction and class correctly shape the run
  • the run is a randomized three-realm run
  • the player can save and resume a Quick Play run cleanly
  • Quick Play data does not interfere with hero-bound campaign runs