PixelGameCraft

ChatGPT Game Development Prompts: 12 That Actually Work

2026-09-14 · by ruofan

ChatGPT Game Development Prompts: 12 That Actually Work

Honesty note: these are prompts I actually use in my daily game dev loop (Merge Fish 2048, a Phaser + Vite project). The pattern that makes them work: give the AI context, one concrete task, and the constraint upfront — that’s the discipline from my AI workflow applied to prompt-writing.

TL;DR

  1. A good game-dev prompt = context + one task + constraint. “Make it faster” fails; “This tween eases in 600ms, it feels slow; suggest 3 durations with the tradeoff” works. The AI is a fast junior dev; prompt like you’d brief one.
  2. Five job types cover most of game dev: scaffold (build a scene/system), modify (change one behavior), debug (explain then fix), review (find problems, don’t rewrite), write-docs (legal/descriptions/README).
  3. Prompts fail for three reasons: no context (AI invents your stack), multiple tasks (changes become unattributable), and asking for output instead of analysis (AI’s default design is average — prototyping discipline).
  4. The most valuable prompt is “explain, then propose” — it turns the AI from a code generator into a design partner, and it’s the one beginners skip.

The 12 prompts (copy-paste, adapt the brackets)

Scaffolding

  1. New scene:

“In this Phaser 3 + Vite project (scene structure in src/scenes/), create a [LevelSelect] scene: [4x4 grid of level buttons, each unlocks by localStorage key ‘level__unlocked’]. Match the existing scene pattern — boot loads assets, menu has a start button. Show the pattern: config, scene class, registration in main.js.”

  1. New system:

“Design a [combo/streak system] for a 2048-style merge game. Requirements: [streak counter resets on non-merge move, +10% score bonus at 5+]. Show it as a plain JS module in src/game/ (no Phaser imports — it’s testable logic), then the integration points in the Game scene.”

  1. Config file:

“Refactor the game constants (board size, tween durations, storage keys) out of src/scenes/Game.js into src/config.js. List exactly what moves where; don’t change any behavior.”

Modifying

  1. One-behavior change:

“The merge tween currently eases in 600ms. It feels slow. Propose 3 (duration, easing) options with the feel tradeoff of each; I’ll pick one — change only that one thing.”

  1. Input handling:

“Add swipe detection to the Game scene: pointerdown/pointerup with a 30px threshold and a 200ms tap window. Use the pattern already in src/utils/. Don’t touch other scenes.”

Debugging

  1. Explain-then-fix:

“In this Phaser game, merging two tiles sometimes spawns a duplicate. Read src/game/Board.js — explain the most likely cause (don’t fix yet), then propose 2 fixes with the tradeoff of each.”

  1. Performance:

“The game drops frames during level transitions. Look at src/scenes/Game.js and src/scenes/Aquarium.js — list the top 3 likely frame costs per scene, ranked, with the fix for each. Don’t apply anything yet.” (frame budgeting)

Reviewing

  1. Architecture review:

“Review src/game/Board.js as if you’re a senior engineer: correctness bugs, edge cases I’ve missed, and anything that would break under 200 levels. List problems by severity. Do NOT rewrite the file.”

  1. Asset/legal double-check:

“Here’s my asset list with licenses (Kenney CC0, jsfxr Unlicense, AI-generated). Flag any that can’t go in a commercial game, and what to add to a CREDITS.md.” (license reality)

Writing

  1. Description/metadata:

“Write a 150-char store description for [a merge game about fish evolution]. Two variants: one portal-style, one itch-style. No hype words (‘amazing’, ‘epic’); factual, benefit-led.”

  1. Docs from code:

“Write a README for this project: what it is, how to run (npm run dev/build), the scene map, and where new scenes get registered. From the files in src/.”

  1. Policy draft (human-reviewed):

“Draft a privacy policy for a game that [stores only localStorage on-device, shows rewarded ads via portal SDK]. Match our existing policy structure. Mark every bracketed placeholder for me to verify.” (privacy template)

Why these work (the pattern behind them)

Every prompt above shares the same skeleton:

  1. Context first: “In this Phaser 3 + Vite project…” — the AI stops inventing your stack.
  2. One task: one scene, one system, one behavior — not three.
  3. Constraint upfront: file location, no-Phaser-in-logic, “don’t rewrite”, “change only that one thing.”
  4. Analysis before code (prompts 6-8): “explain, then propose” beats “fix it” — you keep the design judgment (where AI ends).
  5. Human gate: everything AI writes is a candidate; verify before commit (the 5 discipline rules).

Pitfalls

  1. “Write me a game” — too big; the AI produces a generic mess. Decompose into scenes/systems (structure).
  2. No context — “add a score system” without the project = AI guesses your stack, wrong 80% of the time.
  3. Batching changes — two changes at once = you can’t tell what broke or what worked (one-change rule).
  4. Letting AI rewrite on review — review prompts that end in “fix it” lose the analysis you paid for; say “don’t rewrite.”
  5. Trusting output without running it — AI code compiles 90% of the time and is wrong 20%; run, then test (verification habit).

Bottom line

The 12 prompts cover the daily loop: scaffold, modify, debug, review, write — each built on context + one task + constraint, with “explain, then propose” as the highest-leverage pattern. Prompts fail on missing context, batched tasks, and skipping analysis. The tool generates candidates; your judgment selects and verifies. That’s the prompt-writing side of the full AI workflow — and it’s why a solo non-expert ships a real game in 2026.

Related Posts