# Codename What-a-chess — development plan toward Steam

Version: 1.0  
Date: 21 August 2026  
Status: in development, playable vertical slice  
Engine: Godot 4.7, GL Compatibility  
First release target: Windows PC / Steam

## 1. Project statement

Codename What-a-chess is a tactical roguelite about launching a squad of meeples across a chessboard. The player aims a volley, uses ricochets to damage enemy chess pieces and collect resources, places objects on the board, survives the enemy turn, and reshapes the build between waves.

The project combines:

- the readable geometry of a chessboard;
- physical volley / breakout gameplay;
- predictable chess-piece movement rules;
- resource routing and positional decisions;
- build crafting through meeple types, dice and shop cards.

The goal is to turn the current combat system into a compact standalone PC game and release it on Steam. No release date will be announced before external playtests validate the final scope.

## 2. Current foundation

The current project already includes:

- a 3D board, camera and occupancy model;
- aiming, launch, ricochets and squad return;
- pawn, rook, bishop, knight and queen enemies;
- six waves, HP scaling and victory/defeat flow;
- columns, resource sources and dice;
- three-resource economy;
- a between-wave shop and upgrade cards;
- nine meeple types with special effects;
- ×1–×4 combat speed;
- HUD, combat messaging, damage numbers and VFX;
- automated tests for the main gameplay systems.

The internal roadmap records M0–M18 as complete and 543 passing tests at the last full verification point. Tests must be rerun for every release candidate.

The next major feature is the player's own chess-piece layer: placement, movement, volley bonuses and dedicated cards.

## 3. Product hypothesis

The core value is not passive ricochet spectacle. It is a repeated planning loop:

1. read threats on the board;
2. choose a launch point and trajectory;
3. route meeples through resources, dice and vulnerable targets;
4. survive the enemy move;
5. change the build in the shop;
6. return with a different solution.

The main validation question is whether ricochets plus chess rules create enough meaningful decisions to make players start another run after completing or losing the first one.

## 4. Design principles

- Every volley communicates a tactical intention: damage, resource, position, setup or survival.
- Chess rules create predictable pressure rather than hidden randomness.
- A new card or meeple changes how the player solves the board, not only the damage number.
- High-speed combat remains readable at ×4.
- Failure explains the mistake and returns the player to a new attempt quickly.

## 5. Scope boundaries

The initial Steam scope does not include online multiplayer, PvP, a user editor, console ports, a large narrative campaign or unlimited procedural content.

Windows is the first supported platform. Linux, macOS, controller support and Steam Deck claims are added only after implementation and device-level validation.

## 6. Roadmap

Estimates are planning ranges, not public release promises.

### R0. Stabilize the vertical slice — 2–4 weeks

- Resolve the repeated wall/obstacle contact loop at extreme board columns.
- Gate impact effects to contact entry and control effect lifetime.
- Profile and stabilize large volleys at ×4.
- Recheck first-wave pacing against the reference.
- Create a reproducible stress scene and baseline performance counters.
- Complete repeated full six-wave runs without soft locks.

Gate: deterministic outcomes at ×1 and ×4, no runaway contact loop, green automated tests, clean runtime logs, and stable 60 FPS on the selected baseline PC in the expected worst-case volley.

### R1. Player chess pieces — 4–6 weeks

- Place black chess pieces as tactical barriers.
- Let enemy movement interact with player pieces.
- Select and legally move one player piece per turn.
- Preview legal cells and consequences.
- Add volley bonuses and chess-specific shop cards.
- Complete the deferred builder-meeple interactions.

Gate: the new layer creates positioning decisions, legal moves are readable without explanation, board occupancy stays authoritative, and at least three external testers understand the mechanic unaided.

### R2. Persistence, menus and parity — 3–5 weeks

- Versioned save/load and migration handling.
- Main menu, pause, restart, exit confirmation and settings.
- First-run onboarding for the volley, enemy turn, resources, dice and shop.
- Final reference/parity pass.
- English and Russian localization.
- Full clean-profile playthrough.

Gate: safe save recovery, working settings, a comprehensible first volley, and a complete six-wave run in both languages.

### R3. Product slice and final-scope decision — 4–8 weeks

- Run 15–30 external playtests.
- Measure time to first volley, wave completion, defeat causes and shop choices.
- Validate replay intent and build variety.
- Decide the final run length and content target.
- Tune difficulty, economy and synergy frequency.
- Add content only when it strengthens validated decisions.

Gate: move into full-release scope only when players understand the loop and want another run. If replayability is weak, improve build variety before increasing content volume.

### R4. Steam demo and Coming Soon page — 3–5 weeks, parallel with R3

Product work:

- Windows x86_64 export preset and clean release build;
- app icon, versioning and crash/log location;
- clean-install test on a machine without Godot;
- separate demo save namespace;
- a demo with a clear ending and wishlist call to action.

Steam work:

- Steamworks onboarding and AppID;
- short and long description;
- capsule art, screenshots and a gameplay trailer;
- honest supported-feature and language lists;
- store-page review and Coming Soon publication.

Steam requires a Coming Soon page to be public for at least two weeks before release. Store presence and product builds use separate review checklists; schedule at least seven business days for each review path and possible revisions.

### R5. Alpha, beta and release hardening — 4–6 weeks

- Closed alpha with 20–50 players.
- Severity/frequency-based bug triage.
- Balance pass from real playthroughs.
- Resolution, aspect-ratio and input-device matrix.
- Low/mid/high PC performance matrix.
- Save migration, clean install, update and rollback rehearsals.
- Accessibility pass for UI scale, color cues, screen shake and readability.

Gate: no blocker or critical bugs, reproducible run completion, 95% of test sessions reaching gameplay without technical help, stress-scene frame time within budget, and store copy matching the build.

### R6. Steam release candidate — reserve at least 2–3 calendar weeks

- Upload a mostly final default-branch build.
- Complete the build checklist after store presence review.
- Resolve Valve feedback.
- Freeze the launch build and verify packages, OS support, pricing and discount settings.
- Run a final smoke test through the Steam client.

Gate: approved store page and build, mandatory Coming Soon period complete, successful launch on every declared OS, and every advertised feature present in the build.

### R7. Launch and the first 30 days

- Monitor crashes, reviews and community feedback.
- Fix blocker/critical issues first.
- Publish concise patch notes.
- Review onboarding and difficulty patterns after the first week.
- Decide between a content update, balance update or quality pass only after the launch cohort stabilizes.

## 7. Validation plan

Automated coverage:

- board occupancy and coordinates;
- enemy and player-piece movement rules;
- turn state machine;
- collision outcomes at ×1 and ×4;
- damage, debuffs and special meeples;
- shop prices, purchases and card effects;
- save versioning and migration;
- deterministic balance formulas.

Runtime smoke tests:

- new game to first volley;
- every wave and shop transition;
- victory, defeat, restart and load;
- wall and edge-column stress volley;
- alt-tab, resolution and fullscreen changes;
- clean install and update over an older build.

External playtests should observe whether players understand the first move, read enemy threats, understand volley power, distinguish resources and meeples, make deliberate shop choices and want to begin another run.

## 8. Metrics

Technical:

- frame time at ×1 and ×4;
- contacts per meeple per physics frame;
- active particle/effect count;
- memory after a complete run;
- crash-free sessions;
- save/load failures.

Product:

- time to first volley;
- first-wave and demo completion;
- run duration and defeat cause;
- card and meeple selection frequency;
- second-run start rate;
- wishlist conversion after the Steam page exists.

Synthetic data, internal tests and real player metrics must always be labelled separately.

## 9. Main risks

| Risk | Signal | Response |
| --- | --- | --- |
| Collision/VFX cost at ×4 | repeated contacts and frame spikes | deterministic resolution, entry-only effects, stress scene |
| Chess layer overloads the volley | players cannot predict legal moves | previews, gradual onboarding, external tests |
| The build feels like a tech demo | one run is interesting, the next is not | prove build variety before adding content |
| Scope growth | new systems start before core risks close | milestone gates and explicit non-goals |
| Store copy overpromises | advertised feature missing from build | verify every line against the release candidate |
| Save breakage after updates | older profile fails to load | versioning, migration tests and fallback |
| Visual noise | player loses threats and outcomes | feedback hierarchy and effect budget |

## 10. Milestone Definition of Done

A milestone closes only when:

1. the mechanic is checked against the reference or documented as a deliberate new decision;
2. reusable objects remain scene-first with explicit Inspector references;
3. upward and sibling communication remains signal-first;
4. all variables have explicit types;
5. no new mega-manager or mixed responsibility is introduced;
6. targeted automated tests pass;
7. affected scenes pass runtime validation;
8. the owner reviews and accepts the result;
9. documentation and roadmap status are updated;
10. the next milestone waits for acceptance.

## 11. Immediate next actions

1. Freeze a baseline build and stress scene.
2. Fix the edge-column contact loop and repeated impact effects.
3. Re-run the full six-wave game at ×1 and ×4.
4. Complete M19 player-piece placement.
5. Test chess-layer readability externally.
6. Continue into movement and chess cards only after that gate.
7. Prepare a pitch, capsule brief and Steam Coming Soon backlog in parallel.
8. Do not announce a release date before the R3 decision gate.

## 12. Official references

- Godot 4.7 documentation: https://docs.godotengine.org/en/4.7/
- Godot Windows export: https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_windows.html
- Steamworks Getting Started: https://partner.steamgames.com/doc/gettingstarted?language=english
- Steam Coming Soon: https://partner.steamgames.com/doc/store/coming_soon?l=english
- Steam Release Process: https://partner.steamgames.com/doc/store/releasing?language=english
- Steam Review Process: https://partner.steamgames.com/doc/store/review_process?language=english
- Steam Deck testing: https://partner.steamgames.com/doc/steamhardware/loadgames

This is a working plan. Scope and estimates are revised after milestone reviews and external playtests.