Prompt Patterns That Actually Work for Game Dev

Module 8 · Lesson 3 · ~25 min · collect and reuse

There's a widening gap between "I asked Claude to build me a game and it made a mess" and "I spent 20 minutes with Claude and shipped a feature." The gap is almost entirely in how you frame the request. Below are the prompt patterns I reach for weekly.

Pattern 1: "Build me X from this spec"

Worst possible: "make a card game."
Mediocre: "make a card game where you spell words."
Good: writes a 5-line spec inline.

Build a Card scene for Lexicon Duel.

Requirements:
- Scene root: Control (needed for hand layout with HBoxContainer)
- Two children: TextureRect "Background", Label "LetterLabel"
- Script exports a CardData resource; _ready() populates the label
  and tints the background by letter rarity
- Signal `tapped(card: Card)` emitted on _gui_input for left click / tap
- When selected: modulate Color(1.3, 1.3, 0.8). Track in `var selected: bool`

Match the existing code style in scripts/ — typed GDScript, snake_case.

This prompt works because: it names the exact node types, lists signals explicitly, and references an existing convention. Claude has no ambiguity to resolve. Output is usable as-is.

Pattern 2: "Run and diagnose, don't fix"

Separating diagnosis from action is the single most underused AI dev move.

Run the project via the Godot MCP. Play the duel for about 15 seconds
of simulated input — just print-dump whatever happens. Report back:

1. Any errors or warnings
2. The final state of the DuelController (state, player_hp, enemy_hp)
3. Whether get_tree().get_node_count() exceeded 200 at any point

Do NOT edit any files. Just report.

Why: Claude is eager to help. Left alone, it'll "fix" things you didn't want fixed. Explicit "no edits" keeps the first pass diagnostic. Then you decide the fix.

Pattern 3: "Refactor in place, no new files"

In scripts/duel_controller.gd, the _on_state_entered function has
grown to 80 lines. Extract each match arm into a private method
`_enter_`. Keep behavior identical — no logic changes.
Don't add new files, don't change signals, don't change the enum.

The constraints ("no new files", "don't change signals") prevent scope creep. Claude will not touch anything you didn't authorize. Review the diff, accept.

Pattern 4: "Generate art with explicit style"

PixelLab (and most image-gen models) reward specific style language. Vague: "a sword." Specific:

Generate via PixelLab:
- Subject: a medieval-fantasy short sword, hilt wrapped in leather,
  small sapphire in the pommel
- Style: 32x32 pixel art, orthographic top-down view, clean outlines,
  limited 16-color palette, readable silhouette at 1:1 scale
- Background: transparent
- Save to res://assets/weapons/short_sword.png

Then generate 3 variations with different gem colors (ruby, emerald,
topaz). Name them accordingly.

Match style language across all your assets or they'll look like they belong to different games. Consider writing a "style guide" section in CLAUDE.md — one paragraph of style language — and referencing it in every art prompt.

Pattern 5: "Plan before you code"

For anything touching multiple files or a new subsystem:

I want to add daily challenges — each day there's a specific starting
letter pool and a target score. Before writing any code:

1. Propose the architecture (which new files, which existing files
   change, which signals)
2. Identify the hardest piece
3. Flag any assumptions you're making about existing code
4. Stop. Wait for me to review.

This surfaces disagreements before they become a 400-line diff. Claude is good at planning, sometimes better than at coding. Separate the two steps.

Pattern 6: "Use the MCP, not guessing"

A trap: Claude will sometimes describe what would happen instead of using the MCP to actually check. Be explicit:

Don't guess at the current scene tree. Use the Godot MCP to open
the project and inspect it. Tell me exactly which nodes exist under
MainScene and what scripts they have.

Tools beat guesses. If you suspect Claude is guessing, say so.

Pattern 7: "Delete, don't add"

The default AI failure mode is adding code. Sometimes the right move is less code.

Look at scripts/card.gd. The selection logic uses both a `selected`
bool and a `State` enum with just two values (NORMAL, SELECTED).
Pick one. Delete the other. Update all callers.

Frame deletion as the goal. Claude is perfectly capable of removing code when you tell it to.

Pattern 8: "The quick one-shot"

Not every request needs a spec. For truly small things:

In scripts/shake.gd line 14, change DECAY from 5.0 to 8.0.

File + line + exact change = zero ambiguity. Takes 2 seconds. Don't turn this into a four-paragraph prompt.

Meta-pattern: the lightweight commit rhythm

Having AI help shifts your git rhythm. Commit more often, smaller:

A clean git history is your safety net. Don't skip it because "I'll squash later." You won't.

Anti-patterns

Build your prompt library

Keep a file prompts.md in your project. When a prompt works really well, paste it in. After a month you have a personalized prompt library that's worth its weight in dev hours.

# prompts.md
## New card data
Create a new CardData resource at data/cards/<name>.tres with:
- letter: 
- rarity: 
- point_value: 
- effects: []
Match the style of existing .tres files in data/cards/.

## New enemy
Create data/enemies/<name>.tres extending EnemyData ...

Parameterize with angle-bracket placeholders. Paste, substitute, run.

Do this now

  1. Pick two patterns above that match what you struggle with most. Draft a prompt for each using your actual current task.
  2. Run them against Claude. Note which worked first-try.
  3. Save the winning versions into prompts.md.
← Previous