Skip to content

Production Roadmap

Current Project State

EchoSpire is best described as strong technical pre-production moving into early production.

The current state is:

  • engine foundation: strong
  • gameplay framework: strong
  • deterministic and simulation thinking: strong
  • tutorial slice: credible
  • content breadth: early
  • MVP client: not yet validated
  • production readiness: partial

What Is Already Working Well

  • shared core gameplay architecture
  • modular combat model and effect pipeline direction
  • seeded determinism suitable for simulation and debugging
  • serious test discipline relative to project stage
  • meaningful tutorial slice proving more than isolated subsystems
  • admin and API direction that can scale with content volume

Highest-Priority Gaps

1. Shipping Client Validation

The console layer proves architecture, but the real player-facing WPF MVP client still needs to validate readability, interaction feel, flow, and presentation quality for a Windows-first paid preview.

2. Content Scale

The project needs to move from tutorial-complete to campaign-complete.

The major missing content areas are:

  • deeper card pools
  • relic breadth
  • events and encounter variety
  • single-realm sector progression structure
  • meta progression
  • hero progression implementation and XP economy
  • rival hero content and faction-conflict encounters
  • deterministic gameplay AI and operational AI integration
  • endgame content shape

That content gap now explicitly includes:

  • authored mainline faction quest arcs
  • hero progression choices up to level 10 and their XP pacing
  • rival hero encounters for faction conflict
  • policy-driven simulator expansion and live-site agent workflows
  • difficulty escalation that keeps pace with hero growth

3. Progression And Persistence Hardening

Save and restore, run continuity, and edge-case recovery need to be treated as production work, not cleanup work.

4. Analytics Loop Completion

Telemetry capture exists conceptually, but analytics, simulation reporting, and balance workflows need to become a usable loop.

5. Canonical Documentation Discipline

The project needs a stable single source of truth for rules, content direction, and terminology. This official doc set is the first step in that process.

The next milestone should be a shipping-quality vertical slice.

For the short list of immediate follow-up work, see Current Next Steps.

That milestone should include:

  • a real WPF client implementing the intended player loop
  • a polished tutorial-to-first-campaign segment
  • reliable save, load, and resume behavior
  • at least one usable balance review loop backed by simulation output
  • production-style UI for combat, map, rewards, shop, and event flow
  • integration points for later presentation upgrades even if assets remain placeholder

Immediate

  1. replace the remaining code-seeded tutorial backfill with Admin/API-owned authoring and validation now that runtime tutorial launching is API-first and quest-driven
  2. bring up the hosted early-dev tester environment and validate the full docs plus admin plus api path
  3. extend the first real WPF MVP client shell from connectivity and hero-shell scaffolding into a game-like player flow: startup loading, opening story, main menu, hero builder, run briefing, then combat or map or reward presentation using the API surface that already exists
  4. keep structured local telemetry active in the WPF client so UX debugging, API timing review, and failure triage remain cheap during MVP iteration
  5. define the WPF-to-Core and future Unity migration seams so the MVP client remains presentation-only and the later presentation rewrite is bounded
  6. harden save, restore, and progression state behavior around immutable content snapshots, stable user ownership, hero-state promotion rules, and explicit save-schema migration rules
  7. finish simulation analytics endpoints and reporting views
  8. improve admin-side validation and content safety tooling
  9. maintain this official documentation layer as the current canonical source
  10. define campaign structure, XP progression economy, and rival hero data contracts in production-ready detail
  11. define the canonical gameplay event, effect result, trigger batch, and UX event contracts
  12. define the first effect-module manifest schema and compatibility rules
  13. finish shared type-specific authoring DTOs and validation for each rift type and move the new Admin tutorial, quest, and rift editors off JSON-assisted persistence where appropriate
  14. define gameplay AI policy contracts and live-site agent evidence flows

Next

  1. build the first campaign-complete content set beyond tutorial scope
  2. expand enemies, relics, events, and single-realm sector progression
  3. implement meaningful meta progression
  4. add stronger AI policies for better balance simulation

After That

  1. optimize onboarding, UX clarity, and presentation quality in WPF for the paid preview, or migrate to Unity if the product proves itself and the presentation upgrade is justified
  2. finish replacing placeholder sample-art bindings and generic business-app chrome with packaged official assets and a composable game UI kit
  3. add stronger CI, operational monitoring, and migration workflows
  4. expand replayability and endgame content

Documentation Maintenance Rule

When a design decision is promoted from experiment to canon, update the relevant file in docs/official.

Do not treat docs/gpt54 or the top-level multi-model outputs as the canonical reference once a topic has been promoted here.