Making an AI Game from Scratch (02. Vertical Slice)
The first step from an idea to something playable.
Now we turn the idea into the smallest playable game and watch it gradually become what we want it to be.
Use a stronger AI model for this step whenever possible.
We need a capable model to turn an abstract game design into a small game prototype—one that lets us find problems quickly.
First, plan the first vertical slice from the game outline.
What is a vertical slice? It is the smallest playable piece of a game.
It is one minimal game flow: start the game → play the game → end the game.
Now ask AI to plan the first vertical slice from Game Design Outline.md. Copy the following and send it directly to AI.
Based on `Game Design Outline.md`, plan the first vertical slice and produce a planning document: `Vertical Slice Plan.md`.
## The only goal
The outline’s sentence describing “what appears on screen in one iteration and what the player can do” is the goal of this slice.
Do not expand it. Do not add anything “while we are at it.”
## Step one: read the non-goals first (before planning)
Read the outline’s non-goals list. If any part of the plan conflicts with it, say so immediately.
## Step two: plan
### 2.1 System breakdown
List the systems needed to implement that sentence. Usually there should be two or three.
More than four means it is too large: reduce the sentence and tell me what you reduced it to.
Principle: divide by state ownership. Every piece of state has one and only one owner;
other systems affect it indirectly through commands or events. Do not divide by UI screen or feature noun.
Keep each system under 400 Chinese characters. State clearly: its responsibility in one sentence / the state it owns / what it does not handle.
### 2.2 Implementation order (important—do not omit)
Give the implementation order for these systems, subject to one hard condition:
**After each system is completed, the game must still launch and show something.**
Do not produce an order where “all three must be finished before it can run for the first time.”
For every step, state what will appear on screen when it is done.
If no system can show anything until another is complete, it should be split up or deferred.
### 2.3 Acceptance criteria
In one sentence, describe what I can see and operate on screen.
It must be something I can verify with my own eyes.
It cannot be a statement such as “the system works normally” or “the core loop runs.”
### 2.4 Starting point
Identify the file implementation should start with. Give its exact path and a one-sentence responsibility.
Do not write the file’s contents; another agent will do that later.
### 2.5 Backlog
Put every other system here, one line per responsibility.
Do not specify state, dependencies, scope, or interfaces.
## Question rules
- Ask at most three questions per round, and only questions that must be answered before planning can continue.
- Every question must include your default answer and a one-sentence reason.
- If I do not reply, proceed with the default and record it as an ADR task.
- Do not ask items on the [confirm through playtesting] list. This prototype is precisely what will validate them.
- Do not simply agree with me. If the slice is too large, an assumption is questionable, a conclusion in the outline is unworkable in implementation, or an approach from a reference project does not suit us, say so directly.
## Do not write
- Code, pseudocode, or function signatures
- Architecture diagrams
- A complete event inventory (events emerge during implementation)
- Interfaces between modules that do not yet exist
- Extension points, abstraction layers, or any design “for the future”
- Long explanations of technology choices (state what was chosen in one line)
## Size
Keep the whole plan to three pages or fewer. More means you are writing implementation details.
## Output
After confirming that no unresolved issue remains, wait for me to reply “confirmed,” then output the planning document.
Use only sections 2.1 through 2.5 above; do not add other sections.