Your Game: Driving the Build Yourself

• The game was too ambitious — student spent three days on a menu system and never got to gameplay
• The student described the game in vibes ("a fun puzzle game") and the AI built a different game each time it was asked
• Files grew to 600 lines and the AI started forgetting what was in them
• An early bug was patched over instead of fixed; later features built on the broken patch
• No `ModelTester` was written, so bugs only surfaced through gameplay

• A small, well-defined game finished early, then polished
• A written spec the AI can be re-grounded on
• A playable vertical slice within the first hour
• Scoped prompts that name the file and method to change
• A `ModelTester` extended with each new behavior

"Pac-Man with four ghosts that each have different personalities, fruit bonus items, multiple levels, a high score table, and power pellets that let Pac-Man eat ghosts."

Five major systems. Each one is a multi-day project. None of them are the core game.

"Pac-Man eats pellets in a fixed maze. One ghost chases him by moving toward his current cell. Game ends when all pellets are gone (win) or the ghost touches Pac-Man (lose)."

One entity type beyond the player. One rule per system. Win and lose conditions both stated. This is the MVP.

# Frogger — Spec

## Gameplay
A frog crosses a road and a river. The road has
cars; getting hit costs a life. The river has logs;
the frog must ride them to cross. Three lives.
Reach the top to win the level.

## Model — FrogModel.java
- frog x, y (grid coords)
- lives (int, starts at 3)
- score (int)
- 5 lanes, each a List<LaneObject>
- gameState: PLAYING / WON / LOST

## View — FrogView.java
- draws frog as green square
- draws each lane (cars red, logs brown)
- draws lives count and score top-left
- draws "GAME OVER" / "YOU WIN" centered

## Controller — FrogController.java
- arrow keys move frog one cell
- Swing Timer ticks every 100ms
- on tick: advance lanes, check collisions
- R key restarts after game over

## "Done" for this week
Frog can cross both road and river. Lives work.
Win and lose screens appear. R restarts.
      

• Each layer's data is enumerated
• "Done" is concrete and testable
• Stretch features are not here — they go in a separate section if at all
• Short enough to paste into a prompt as context
• Specific enough that the AI cannot drift into building a different game

1. Spec the game — one page, in README.md
2. Generate three class shells — Model, View, Controller, compiles, opens window
3. Get one entity drawn — the player, in the right place
4. Get one input working — arrow keys move the player
5. Add the timer — one Model thing updates each tick
6. Add the core mechanic — collision, scoring, whatever the game is about
7. Add win and lose conditions — game cannot run forever
8. Add restart — R key resets state
9. Now add features and polish

• Names one file
• Names one method
• Forbids changes elsewhere
• Returns a snippet, not a rewrite

• The AI adds Swing imports back to your Model
• It renames a method you've been using for the last hour
• It "helpfully" rewrites a method you didn't ask it to touch
• It references a method that doesn't exist in your file
• It forgets a rule from your spec ("the frog moves with the log")
• It produces code that compiles but does the wrong thing

• Re-paste the spec (or, in agentic tools, point at README.md) at the top of important prompts
• Paste the actual file when the AI's mental model is off — or in agentic tools, tell it to re-read the file
• Ask for diffs, not whole files — easier to review, less drift
• Read every change before accepting it — pasting in chat, or approving a diff in agentic tools
• Start a fresh chat / new agent session when the AI is arguing with its own earlier wrong answer

• One file is over 300 lines
• The AI forgets fields you added an hour ago
• You have to scroll to find anything
• One concept (Ball, Brick, Ghost) appears in dozens of places

• An Entity class for things with x, y, width, height
• A Sprite class for image-loading logic
• A Level class for level layout data
• A Sound helper for audio
• An InputState class held by the Controller

• Title screen with the game name and "Press SPACE to start"
• Pause key (P) that freezes the timer
• One sound effect on the most important event (hit, score, death)
• Persistent high score — read and write a single int from a text file
• A clean death and restart cycle — game over, R restarts, no leftover state

• Custom fonts
• Animated sprites with multiple frames
• Particle effects
• Settings menus
• Difficulty levels (unless this is the core mechanic)

Low-leverage polish takes hours and rarely shows up in a 5-minute demo.

// in GameView
public void paintComponent(Graphics g) {
    super.paintComponent(g);
    for (Alien a : model.getAliens()) {
        g.setColor(Color.GREEN);
        g.fillRect(a.x, a.y, 30, 30);
    }
}
      

// in GameView
private Image alienSprite;

public GameView(GameModel model) {
    this.model = model;
    try {
        alienSprite = ImageIO.read(
            new File("assets/alien.png"));
    } catch (IOException e) {
        e.printStackTrace();
    }
}

public void paintComponent(Graphics g) {
    super.paintComponent(g);
    for (Alien a : model.getAliens()) {
        g.drawImage(alienSprite,
            a.x, a.y, 30, 30, null);
    }
}
      

• Loading every frame. If ImageIO.read is inside paintComponent, your game will run at 2 FPS. Load in the constructor.
• JPG instead of PNG. JPG has no alpha channel — you'll get a white box around your sprite. Always use PNG.
• Size mismatch. A 64×64 sprite drawn at 30×30 may look fuzzy. Either pick assets near your grid size, or scale explicitly with drawImage(img, x, y, w, h, null).
• File not found. Run your game from the project root, not from src/. The path is relative to where Java was launched.

Many OpenGameArt downloads are sprite sheets: one PNG with many frames in a grid. Using them requires img.getSubimage(...) and a frame counter for animation.

For a Week 3 MVP, use single-image-per-entity. Treat sprite-sheet animation as a stretch goal after the game is fully playable.

• The interview that produced your spec
• The spec-dump prompt that started the build
• A scoped-edit prompt for one of your features
• A debugging prompt with the stack trace
• One prompt where the AI was wrong, and what you did
• A refactor prompt (if you did one)
• A test-extension prompt for ModelTester

• Copy the prompt verbatim
• One sentence on what the AI produced
• One sentence on what you changed and why
• If it was wrong: what was wrong, how you noticed, what you did instead