# Fleeting — completion plan

## The standing prompt

> You are the lead development partner for Fleeting, a 1–4 player cooperative expedition game. Build the smallest playable proof of the central promise: the carrier never stops, players detach to gather what the fleet needs, and every recall asks whether one more risk is worth it. Work in vertical slices. Keep gameplay rules deterministic and data-driven, measure every playtest, protect accessibility and mobile/Steam constraints from the beginning, and expand content only after the current loop meets its acceptance test. At every milestone, state what is proven, what remains uncertain, what William must decide or experience, and the safest next build.

This prompt is a product constraint, not permission to add uncontrolled scope. New ideas enter the feature board and must earn a place through a test.

## Definition of done

Fleeting is complete when it offers a stable, accessible 1–4 player journey with:

- a satisfying pod flight model on keyboard, controller, and touch;
- a carrier that advances through readable, winding expedition sectors;
- detach, gather, trade/raid/ally, recall, defend, repair, and refit loops;
- online co-op with reconnect plus useful autonomous buddies;
- a complete homeward campaign with replayable route variation;
- Steam and mobile releases with platform-appropriate UI, performance, saves, and compliance;
- a sustainable SoundDeck and MotionDeck content pipeline with editable sources and reproducible exports.

## Build sequence

### Phase 0 — Product truth and tooling

**Prove:** The team can explain the game in one sentence and test one uncertainty at a time.

- Maintain the workbook, terminology, decision log, feature board, and test archive.
- Lock asset naming, versioning, license metadata, and export manifests.
- Establish private source control, Cloudflare playtest deployment, automated tests, and release notes.

**William decides:** tone, emotional promise, acceptable difficulty, and reference boundaries.

**Exit:** a stranger understands the promise and can open the current build from a URL.

### Phase 1 — Flight-feel prototype

**Prove:** A pod is enjoyable before it has progression or content.

- Tune thrust, rotation, inertia, boost cost, wall response, camera, trail, and hit feedback.
- Prototype contextual tutorial prompts and four-button communication.
- Add controller and touch input spikes.

**William does:** repeated 5–10 minute feel tests and chooses among recorded handling variants.

**Exit:** 80% of first-time players deliberately reach, collect, and dock within three minutes.

### Phase 2 — Cooperative heartbeat

**Prove:** Splitting up and answering a recall creates the intended conversation.

- Build one moving carrier, one maze sector, fuel, four pods, one swarm, and fast pod replacement.
- Add host-authoritative networking, local bots, reconnect, and latency simulation.
- Measure return timing, role switching, fuel clarity, and idle time.

**William does:** host two- and four-player sessions and choose the recall warning language/timing.

**Exit:** most returns are deliberate; late returns are understood risks rather than confusion.

### Phase 3 — Vertical slice

**Prove:** One short journey produces memorable consequences.

- Three planet postures, refit slots, one-run relics, pod loss, one companion, and a run ending.
- One polished biome with production-quality sound, animation, UI, onboarding, and accessibility.
- Save/profile model, run seed, balance telemetry, and content validation.

**William does:** approve the visual/audio language and decide which consequences define the game.

**Exit:** external players ask to start another run and can explain why their fleet became distinct.

### Phase 4 — Production engine and content factory

**Prove:** The team can add good sectors and assets faster without breaking the game.

- Move the proven prototype into Godot 4 with deterministic rule modules and data resources.
- Build route grammar, encounter authoring, validation, replay capture, and automated smoke tests.
- Add SoundDeck and MotionDeck game-project manifests and repeatable runtime export profiles.

**William does:** review weekly builds and rank content by player value rather than novelty.

**Exit:** a new encounter can be authored, reviewed, exported, integrated, and tested without code changes.

### Phase 5 — Alpha to platform beta

**Prove:** The whole campaign is stable, balanced, and comfortable across target devices.

- Campaign arc, full biome set, matchmaking/lobbies, accessibility suite, analytics, crash reporting.
- Steam Input, achievements, cloud saves, store build; mobile touch, performance, suspend/resume, store compliance.
- Closed alpha → public demo → platform beta with explicit quality gates.

**William does:** make scope cuts, lead community feedback, approve store presentation, and protect the core promise.

**Exit:** performance, retention, crash rate, onboarding, and multiplayer reliability meet written release gates.

### Phase 6 — Launch and stewardship

- Ship only after a rollback-tested release candidate and support plan.
- Treat balance changes as hypotheses with before/after measurements.
- Feed reusable audio, animation, UX, networking, and production lessons back into the three workspaces.

## Weekly collaboration rhythm

1. **Choose one uncertainty.** Never begin with “add more content.”
2. **Write the pass signal.** Decide what evidence changes the plan.
3. **Build the smallest playable test.** Keep it releasable.
4. **William plays and reacts.** Feel and intent are primary data.
5. **Record telemetry and observation.** Neither is sufficient alone.
6. **Decide keep, tune, remove, or retest.** Update scope and assumptions.
7. **Ship a playtest URL and changelog.** The current truth stays accessible.

## Immediate next decisions

- Pick the desired pod handling: nimble, drifty, or heavy.
- Decide whether players aim weapons independently from flight.
- Choose the first recall threat: swarm, tunnel collapse, or boarding party.
- Set the intended first-session length and failure harshness.
- Decide whether the first network test is peer-hosted online, local shared-screen, or both.