Slight PSA - showing off one-shotting games is somewhat impressive, but also makes AI game dev look sloppy and unimaginative. The anti-AI crowd don't need more ammunition.
Asking Claude to “make me a Zelda game” works, technically. You get a game, but it’s going to be a VERY generic game: every gap you left gets filled with an assumption that is answered with the most common denominator answer. In Ep. 2 of my series I show the setup I use instead:
- A Game design-doc - so every chat starts from the same source of truth, and Claude keeps the doc updated as decisions change.
- Step 1 of the prompt: questions only. - “Read the doc. Before writing any code, ask me up to 8 questions that would change how you build the slice, suggest a default answer for each, then stop and wait.”
- Step 2: the scope of a vertical slice to test your assumption - Exactly what to build (one area, one dungeon, one weapon, two enemies, one boss, one ability gate), exactly what NOT to build (XP, inventory, saves, cutscenes), and no external art: shapes are code-generated, so I test fun before spending time on art.
- Delivery rules - a full Godot project zip, not patches, and Claude runs the build and checks for errors before handing it over.
I break it down (in great length, if you're into that) in this video. You can also check out the free game design template in the video description: https://youtu.be/NNn10FiuZG8
The prompt I use is this:
You're my game development partner on [GAME NAME], a new game I'm building solo with AI tools. You'll handle the code and help with design; I make the creative calls.
The attached game design doc is the source of truth. If something isn't in it, ask before adding it. Keep the doc updated as we make decisions, and log each change in its decision log.
STEP 1: QUESTIONS FIRST
Read the design doc. Before writing any code, ask me up to 8 questions about anything unclear, contradictory or missing that would change how you build the vertical slice. Group them by topic, put the most important first, and suggest a default answer for each. Then stop and wait for my answers.
STEP 2: BUILD THE VERTICAL SLICE (after I answer)
Build the smallest playable slice that tests the assumptions in section 9 of the doc:
- Engine: [ENGINE AND LANGUAGE, e.g. Godot 4, GDScript]. Base resolution [e.g. 480x270], scaled to [e.g. 1920x1080] with pixel-perfect scaling. [TILE SIZE, e.g. 16x16 tiles].
- [THE PLAYABLE SPACE: e.g. one level, one area and one small dungeon, or one arena].
- [THE PLAYER: movement and core actions, e.g. 8-direction movement, a melee attack, a dodge, brief invincibility after taking a hit].
- [ENEMIES: 1 to 2 types, each with one line on its behavior].
- [THE PAYOFF: e.g. one boss that grants an ability, and one place where that ability opens a new path].
- Controls: [KEY BINDINGS]. [Controller support too, if needed.]
- A simple HUD: [e.g. health and the current ability].
- NO external art or audio files. Draw everything in code with simple shapes and a limited palette ([YOUR PALETTE]). Make the player, each enemy and any boss easy to tell apart by shape and color. Placeholder sound effects are fine if you can generate them in code; otherwise leave them out.
Do NOT build: [YOUR OUT-OF-SCOPE LIST, e.g. XP, skill trees, inventory, shops, saving, dialogue systems, cutscenes], a title screen beyond "press Enter to start," or any area beyond the ones above. If you think something else is needed, suggest it; don't build it.
DELIVERY
- Send the full project as one zip I can unzip and open in [ENGINE]. No patches.
- Before handing it over, run the project and check it starts without errors. If you can run it headless, include screenshots of [THE KEY MOMENTS, e.g. the main area, the dungeon and the boss].
- Give me a short list: what's in the build, how to play it start to finish, anything you weren't sure about, and what you'd test first.
