How to Make a Good Game with AI: Before Claude Code or Codex
AI can build a working game. Your design makes it understandable and worth playing. Start with one moment, clear signals and feedback your player can feel.
Before asking Claude Code or Codex to build your game, decide what someone should experience while playing it. A game can run without errors and still leave the player confused. That is a design problem, and generating more features will not automatically fix it.
This guide adapts the first lesson in my Build Games with Claude Code and Codex series. We follow two simple situations: finding a key in a locked room, and moving a crate to reach a high ledge. Both can become satisfying games when the player understands enough to form an idea and try it.
1. Choose a moment the player can experience
“Make a mysterious room” gives your AI a mood, but very little direction. What should the player actually do? What makes that action matter?
In our room, the player feels trapped, searches for a key and feels relief when the door opens. In the level, the player cannot reach the ledge, notices a movable crate and feels clever when they use it as a step. Each has a problem, an available action and a result worth reaching.
You can begin with a moment like this even if your larger idea includes a whole world. Build the part that lets someone experience it. The rest has a clearer purpose once that works.
2. Make the next thing to try readable
You know the key is in the drawer. A new player only sees a desk. If the drawer has no handle, it can look like scenery. Give it a brass handle that catches the light. Let the crate stand apart from the wall and wobble when touched.
These signals show what can be interacted with without giving away the solution. A handle suggests “I open”; it does not tell the player what is inside. A wobble suggests “I move”; the player still has to connect the crate to the ledge.
Decoration also communicates. A flashing light might look like a countdown, while a bright barrel can invite interaction. When those signals lead nowhere, the player follows a trail you did not intend. Save the strongest signals for things that matter.
3. Let the player test their own idea
The satisfying part is the connection: “Could the key be in that desk?” or “Could I use this crate to climb up?” Give the player a way to test that thought immediately, and let them recover from an unsuccessful attempt.
You do not need branching dialogue or an enormous map to create this feeling. A racing player can try slowing down before a corner. A music-game player can listen to a note and choose the matching key. The action should express an idea, and the result should help them understand whether it worked.
4. Give the action a clear answer
A key silently disappearing into an inventory leaves the player wondering whether they collected it. A short jingle, a glint and an inventory change confirm what happened. The crate can scrape as it moves and stop with a thud against the wall.
Failed actions need an answer too. A locked door can rattle and show a short “Locked” message. Silence may look like a broken control.
Choose effects that communicate the change. If everything shakes and flashes, the important response becomes difficult to notice. The goal is a readable conversation between the player and the game.
5. Watch someone play without coaching
Give the prototype to someone who has not heard your explanation. Watch where they pause, what they try and what they think happened.
Perhaps they find the key but cannot use it because your game requires an unexplained inventory step. Perhaps they notice the crate but do not know a button must be held to push it. Fix the point where their understanding diverges from yours. Using the key automatically at the door or showing a small “Hold to push” prompt may solve the problem.
Ask what they felt as well as what they did. Solving a puzzle quickly does not automatically make it too easy; they may have enjoyed figuring it out. Change one thing, then let someone test again.
Your first design brief for Claude Code or Codex
Answer these four questions before you request a build. They give you something concrete to test instead of judging the result only by how polished it looks.
- What do I want the player to feel?
- What should they notice?
- What idea can they try?
- How will the game answer?
Turn the brief into one playable prototype
Here is a starting prompt using the locked-room example. It is a build brief, not a promise that an assistant will get every detail right on the first attempt. Run the result and test each behaviour before adding more.
Build a tiny browser-game prototype in HTML, CSS and JavaScript.
Experience: the player searches a locked room and feels relief when they escape.
Goal: find a key and open the exit.
Signals: a drawer handle catches the light; decoration is visually quieter.
Actions: click the drawer to search, then click the door to try the key.
Feedback: show the drawer opening, confirm key collection and make the exit visibly open. If the key is missing, the door should respond clearly.
Finish: show a win state and a working restart button.
Use simple shapes first. Build only this room. Explain how to run it, and give me a checklist to test movement or interaction, the locked door, key collection, winning and restarting.What to check before adding more
Keep a working copy. Play through the whole loop, then ask a fresh player to try it. You are ready to expand when they can recognise the goal, try an action, understand the response and finish without you explaining the answer.
If you already have a game, use this process on one scene that feels flat. You do not need to restart. Pick the moment, improve its signals and feedback, then see what a real player does.