//Development Strategy

The source GDD includes platform targets, post-launch plans, and success metrics. Read literally, those sections describe a long-range release plan. For the interview build, the more useful reading is that they show how I think about scope, priorities, and validation.

▸Platform Thinking

The project is meant to be PC-first, but the prototype is built in a way that can be played in a browser and distributed as a desktop application. The design does not assume that players will only interact with it through a browser.

The game will be built entirely on the web with the Tauri framework with a Rust-based backend. The prototype is built with React and TypeScript, and the frontend with native JavaScript, WebGL, and WebAudio.

▸Success Metrics That Matter

The source GDD includes a list of success metrics that are mostly business-oriented, e.g.:

• ▪player completion rate
• ▪playstyle diversity
• ▪community creation
• ▪accessibility adoption
• ▪critical recognition

What I want to preserve from that list is the design logic behind it. These metrics are not only business outcomes. They are signs that the systems are doing the work they were meant to do.

If players finish the game, the narrative carried them. If builds diverge, the systems support expression. If assist features are used, the game is meeting players where they are instead of shutting them out.

▸Post-Launch Thinking, Reframed

The long-term plan assumes updates, expansions, and mod support. For the portfolio version, the important part is not promising a ten-year roadmap. It is demonstrating that the project has been structured with extensibility in mind.

That includes:

• ▪modular technical systems
• ▪room for community-driven content
• ▪a design philosophy that values iteration instead of one-shot perfection