Game Prototype Test Scope — Tactical Vertical Slice
Stage-1 review page for the smallest playable test that can prove or disprove Omega War's tactical vertical-slice fun. Alignment date: 2026-06-15. Status: review.
Review Status
This page proposes scope only. It does not create the canonical prototype-test plan and does not start implementation. If approved, Stage 2 will draft a complete working packet for review before writing research/unthinkable/game-prototype-test.md.
prototype tierfile:// safeno external dependenciescanonical output gated
Table of Contents
Known Context
| Source | Observed Context | Stage-1 Use |
|---|---|---|
research/unthinkable/tactical-vertical-slice-spec.md | Confirmed one fixed browser-first battle: UK 11th Armoured vs Soviet 2nd Guards Tank Army, one Central Germany map, 15-25 minutes, deck-as-roster plus command-post base-building, cover, suppression, capture, AI, save/pause, performance gates. | Primary scope anchor. The test plan should measure the confirmed slice rather than reopen the battle contract. |
research/unthinkable/game-genre-map.md | Must-prove items: cover/suppression/capture, build-order phasing, baseline AI, mid-battle save/pause, browser unit ceiling, deck × base legibility. | Turns the slice spec into pass/fail prototype questions. |
research/unthinkable/game-audience.md | Primary players punish dumb AI, thin campaign layers, no mid-mission saves, MP-first priorities; secondary players need roster identity and counterplay legibility. | Defines playtest observations for frustration, clarity, and replay intent. |
research/unthinkable/unit-data-schema.md | Confirmed schema separates card content from runtime unit instance state, phase band from deployment band, command-post governance from card rows. | Stage 2 should require fixture-shape checks without assigning final balance values. |
Proposed Prototype-Test Scope
One playable tactical battle, Breakthrough at Helmstedt working title, using UK/Commonwealth 11th Armoured against Soviet 2nd Guards Tank Army.
The player understands and enjoys deck identity arriving through in-battle command-post escalation, not through a passive timer.
15-25 minute browser battle where the player can win or lose, with Band A/B/C exposure, one wonder event, baseline AI pressure, save/pause, and performance logging.
Campaign map, final balance, final art/audio, multiplayer, full deck builder, cloud saves, all factions, analytics infrastructure, and production content tooling.
Required Gate: Prototype-Test Scope
Does this scope match the smallest playable test you want Stage 2 to design?
Test Questions
| Question | Stage-2 Measurement Shape | Failure Signal |
|---|---|---|
| Is the tactical fight readable and fun at company scale? | Observer notes on cover choices, suppression reactions, capture fights, visible cause and effect, first win/loss completion. | Players cannot explain why units live, break, or die. |
| Does command-post escalation make the deck feel authored? | Post-session recall: what unlocked Band B/C, why build order mattered, what the opposing build telegraphed. | Players describe the base as busywork or the bands as a hidden timer. |
| Does the AI create pressure without feeling unfair? | AI captures, contests center, escalates, retreats/repositions, uses late powers only after prerequisites. | AI ignores objectives, attacks one lane forever, or deletes the player through untelegraphed power. |
| Does the session survive browser reality? | Pause, manual save, visibility-loss autosave, reload, restart, and deterministic state restoration checks. | Reload duplicates entities, loses command-post state, or corrupts capture/resource state. |
| Is replay desire present before campaign context? | End-of-test question: would the player replay to try a different build order or preserve units better? | Players say the scenario is solved, flat, or only worth playing with campaign rewards. |
Source Plan
Stage 2 should use repository evidence only unless approval feedback requests fresh external research. The already-approved upstream artifacts are sufficient to design the test protocol because this is a validation plan for a confirmed slice, not a new market or genre sweep.
- Primary internal sources: tactical vertical-slice spec, game-genre map, audience research, game fantasy, unit data schema, proposed decks roster.
- Evidence treatment: claims will be labeled as source observation, inference, assumption, or decision impact.
- Working packet path:
research/unthinkable/_working/preliminary-game-prototype-test-research.md. - Canonical path after final approval:
research/unthinkable/game-prototype-test.md. - Task updates: only concrete implementation or playtest-prep tasks discovered in Stage 2 should be added to
tasks/todo.md; human-only recruiting/scheduling belongs intasks/manual-todo.mdif needed.
Required Gate: Source Plan
Is repo-only source coverage sufficient for the Stage-2 prototype test plan?
Assumptions and Confidence
| ID | Assumption | Confidence | What Would Change It |
|---|---|---|---|
| GPT-A1 | The confirmed tactical slice should be treated as fixed input, not redesigned during prototype-test planning. | High | User asks to reopen battle contract or faction pair. |
| GPT-A2 | The riskiest fun question is deck × command-post escalation legibility, not raw combat alone. | High | Approval feedback moves priority to combat feel or performance only. |
| GPT-A3 | Repo-only sources are enough for this scope because upstream market and genre work is already confirmed. | Medium | User requests fresh comparable playtest-method research. |
| GPT-A4 | A valid prototype test must include AI and save/pause, even if the combat loop could be mocked faster without them. | High | User chooses to narrow scope to a combat sandbox spike. |
Required Gate: Assumptions
Which assumption treatment should Stage 2 use?
Interactive Preview
Ephemeral preview only. This is a review aid for the planned playtest flow, not production code.
Stage 2 Preview / Expected Review Format
If this Stage-1 scope is approved, Stage 2 will produce a working packet and update this page with the full rendered substance. Expected sections:
- Research Scope Approved with approved scope, source plan, output paths, and caveats.
- Prototype Scope with exact scenario boundary, session length, fixtures, non-goals, and instrumentation notes.
- Core Test Questions with fun, clarity, replay, AI, save/pause, and performance hypotheses.
- Playtest Script with moderator setup, player tasks, interruption/save drill, and post-session interview prompts.
- Observation Checklist for command-post escalation, cover/suppression, capture behavior, AI pressure, UI comprehension, and replay intent.
- Success Criteria with pass/concern/fail thresholds and cut/keep/amplify decisions.
- Evidence Matrix mapping every major recommendation to repo evidence, inference, confidence, assumption status, and decision impact.
- Proposed Canonical Artifacts & File Changes before any canonical write.
- Final Artifact Approval Gates for Stage 3 readiness.
Required Gate: Stage-2 Review Format
Does this expected Stage-2 review format match what you want to evaluate?
Approval Gates
Required Gate: Artifact Destination
Approve the Stage-2 working packet and eventual canonical artifact paths?
Required Gate: Proposed File Changes
After Stage-1 approval, may Stage 2 write only the working packet and update this same review page and index?
Required Gate: Post-Approval Route
After the canonical prototype-test plan is later approved, what route should be recorded?
Compile Responses
Answer any gate or select section feedback, then compile YAML. Partial responses are allowed and remain revision requests until every required gate is answered with no unresolved negative feedback.