Skip to content

WPF UX Flow Map

Purpose

This page defines the current Windows-first UX flow for the EchoSpire WPF shell.

It exists to do four practical things:

  • remove setup and login plumbing from the visible player experience
  • define the first screen sequence we are designing toward
  • give every planned screen a stub and an asset intake folder now
  • define where official assets live versus where reference material belongs

UX Rule

The player-facing shell should not expose API base URLs, login forms, or environment setup widgets as part of the main experience.

For the current preview pass:

  • the client should bootstrap into the configured default preview account automatically
  • connection and retry behavior should happen inside the shell
  • if bootstrap fails, the shell should show player-facing recovery language rather than infrastructure controls
  • later account work should be integrated into the real product UX, not parked as side-panel tooling

Flow Map

flowchart TD
    A[Startup Loading] --> B[Opening Story]
    B --> C[Main Menu]
    C --> D[Hero Builder]
    C --> E[Run Briefing]
    D --> C
    E --> F[Combat Encounter]
    F --> G[Realm Map]
    G --> H[Reward And Event]
    H --> F
    H --> G
    G --> I[Sanctuary And Recovery]
    I --> C
    A -. global access .-> J[Settings And Accessibility]
    B -. global access .-> J
    C -. global access .-> J
    E -. global access .-> J
    F -. global access .-> J
    G -. global access .-> J
    H -. global access .-> J
    I -. global access .-> J

Screen Stubs

1. Startup Loading

  • Purpose: present the game identity cleanly while the shell becomes ready
  • Needs to answer: what game is this and is the client about to become interactive
  • Official assets: assets/ui/screens/startup-loading
  • Samples: assets/ui/screens/startup-loading

2. Opening Story

  • Purpose: deliver the canonical fall of the Aevum Spire before the first interactive choice
  • Needs to answer: what broke, why the Great Houses exist, and what role the player is about to take on
  • Official assets: assets/ui/screens/opening-story
  • Samples: assets/ui/screens/opening-scene

3. Main Menu

  • Purpose: combine hero selection, continue-run context, and create-hero entry into one stable home screen
  • Needs to answer: which hero should I use, can I continue, and where do I go to create a new one
  • Official assets: assets/ui/screens/main-menu
  • Samples: assets/ui/screens/main-menu

4. Hero Builder

  • Purpose: shape faction, class, identity, and placeholder art intent
  • Needs to answer: what am I committing to if I create this hero
  • Official assets: assets/ui/screens/hero-builder
  • Samples: assets/ui/screens/hero-builder

Immediate Asset Needs

For the next concrete WPF pass, these are the minimum official assets needed to make the first three screens feel intentional instead of placeholder-heavy.

Startup Loading

  • logo lockup for the game title
  • one approved background illustration or atmosphere plate
  • loading indicator treatment
  • optional short-tip or flavor-line treatment

Folder targets:

  • assets/ui/screens/startup-loading/backgrounds
  • assets/ui/screens/startup-loading/logos
  • assets/ui/screens/startup-loading/tips

Opening Story

  • five act key images with safe text-overlay composition
  • one motion-comic panel treatment for text legibility
  • act progression treatment and skip or continue controls

Folder targets:

  • assets/ui/screens/opening-story/backgrounds
  • assets/ui/screens/opening-story/overlays
  • one menu background treatment
  • navigation chrome or highlight treatment
  • hero-card frame and selected-state treatment
  • empty-state illustration or ornamental treatment

Folder targets:

  • assets/ui/screens/main-menu/backgrounds
  • assets/ui/screens/main-menu/navigation
  • assets/ui/screens/main-menu/hero-cards

Hero Builder

  • one hero-builder background or panel-backdrop treatment
  • faction icon set
  • class icon set
  • portrait frame treatment
  • placeholder portrait pack until final art exists

Folder targets:

  • assets/ui/screens/hero-builder/backgrounds
  • assets/ui/screens/hero-builder/faction-icons
  • assets/ui/screens/hero-builder/class-icons
  • assets/ui/screens/hero-builder/portrait-frames
  • assets/heroes/portraits/placeholders

4. Run Briefing

  • Purpose: confirm the selected hero and frame the next run entry
  • Needs to answer: continue or start, with what visible stakes and modifiers
  • Official assets: assets/ui/screens/run-briefing
  • Samples: assets/ui/screens/run-briefing

5. Combat Encounter

  • Purpose: present tactical state, action choices, and readable consequence
  • Needs to answer: what is happening now, what can I do, and what will it cost
  • Official assets: assets/ui/screens/combat-encounter
  • Samples: assets/ui/screens/combat-encounter

6. Realm Map

  • Purpose: show route choice, node affordance, and campaign pressure
  • Needs to answer: where can I go, what does each node imply, and why should I care
  • Official assets: assets/ui/screens/realm-map
  • Samples: assets/ui/screens/realm-map

7. Reward And Event

  • Purpose: resolve outcomes and set up the next decision point
  • Needs to answer: what changed, what can I take, and what comes next
  • Official assets: assets/ui/screens/reward-event
  • Samples: assets/ui/screens/reward-event

8. Sanctuary And Recovery

  • Purpose: handle save visibility, rest, recovery, and utility actions in one intentional place
  • Needs to answer: how do I pause, recover, or step away without losing context
  • Upgrade services belong here as a recovery branch: authored rest nodes expose upgrade options directly, and broader sanctuary nodes expose them as part of available services
  • Official assets: assets/ui/screens/sanctuary-recovery
  • Samples: assets/ui/screens/sanctuary-recovery

Optional sub-screen if the service list becomes too dense:

  • Upgrade Services
  • Purpose: focus card upgrades, repair or recalibration previews, and confirm or cancel decisions without overloading the broader recovery screen
  • Official assets: assets/ui/screens/upgrade-services
  • Samples: assets/ui/screens/upgrade-services

9. Settings And Accessibility

  • Purpose: give global utility controls a proper home instead of scattering them across dialogs
  • Needs to answer: how do I tailor readability, feedback, and controls for this player
  • Official assets: assets/ui/screens/settings-accessibility
  • Samples: assets/ui/screens/settings-accessibility

Asset Structure

All approved assets live directly under assets/ with subfolders for each category:

  • assets/cards — card frames, icons, and art
  • assets/factions — crests, banners, leader portraits
  • assets/heroes — class portraits, nameplates
  • assets/ui — backgrounds, components, fonts, icons, logos, overlays, screens
  • assets/references — inspiration, paintovers, moodboards

Current screen-facing paths that the WPF shell already references:

  • assets/ui/screens/*
  • assets/ui/icons
  • assets/ui/backgrounds
  • assets/heroes/portraits
  • assets/ui/screens/*
  1. Drop screenshots, inspiration, or paintovers into the appropriate assets/ui/screens/<screen-name> folder.
  2. Adjust the corresponding WPF stub until the intended layout and information hierarchy feel right.
  3. Promote approved deliverables into assets/ui/screens/<screen-name> or another official asset folder.
  4. Replace placeholder visuals in the shell with official assets only.

Current State

The WPF shell now supports this direction in three concrete ways:

  • session bootstrap happens automatically with the configured preview account
  • API location and explicit login widgets are removed from the main UX
  • every flow-map screen has a visible stub surface or live slice in the shell plus a matching asset folder