Use Codex /goal To Build a Fully Functional Game In One Prompt

Open Terminal and run:

codex features enable goals

This turns on the Goals feature for Codex. You can use `/goal` from Terminal or inside the Codex app. For browser games, we prefer the Codex app because Codex can open the app, click around, use the browser, and verify that the thing actually works on screen.

The important shift is that `/goal` is not a normal prompt. A normal prompt asks Codex to do a task once. A goal gives Codex an objective, a checklist, and permission to keep working until the evidence says the job is done.

Pro tip: Do not use `/goal` just because a task feels big. Use it when you can define a finish line. "Make this better" is a weak goal. "Build a playable HTML demo, run it locally, test controls, and report what passed" is a strong goal.

Start with a game idea that can be described in a few sentences. You do not need a huge design document. You need rules Codex can verify.

Here is the kind of prompt that works:

/goal I want a top-down endless surfing game where you gain points for jumping waves and lose by crashing into rocks. Use HTML and test it; I just want a playable demo.

That prompt is short, but it has the pieces Codex needs:

• a visible format: a top-down browser game
• a core action: jumping waves
• a scoring rule: gain points for clean jumps
• a failure rule: lose by crashing into rocks
• an output bar: a playable demo
• a verification instruction: test it

If your idea is harder to explain, pause before you send it to Codex. Ask ChatGPT to rewrite the idea in 100 words or less with objective tests. If ChatGPT cannot do that cleanly, the task is probably too large or too subjective for one goal.

Pro tip: Good `/goal` prompts spend more words on success criteria than vibes. Codex can work toward "spacebar jumps, score increases, collision ends the game, restart button works." It cannot reliably work toward "make it addictive" without more concrete signals.

You can paste a simple goal directly, but better prompts give Codex a sharper loop. Use this structure:

/goal Build a small browser game called Endless Surf Carver.

Game idea:
- Top-down endless surfing game.
- The player moves left and right through wave lanes.
- The player gains points for jumping waves cleanly.
- The player loses by crashing into rocks or obstacles.

Acceptance criteria:
- The game runs locally in the browser.
- Keyboard controls work.
- Score increases when the player successfully jumps waves.
- Collision or failed movement can end the run.
- There is a clear game-over state and a restart action.
- Test it in the browser and summarize what passed.

Constraints:
- Keep it as a playable demo.
- Use simple HTML, CSS, and JavaScript unless the current project already uses a framework.
- Do not add unrelated features.

This is more efficient than sending five follow-up prompts later. The goal already tells Codex what to build, what not to build, and how to decide whether it is finished.

You can still keep creative room in the prompt. The point is not to micromanage every color or animation. The point is to make the core loop measurable.

Pro tip: Put constraints at the bottom. Codex tends to overbuild when a prompt sounds open-ended. A line like "Keep it as a playable demo" prevents the agent from turning a five-minute exercise into a full game engine.

Once you send the prompt, Codex translates the request into a plan. You will usually see a checklist with steps like inspecting the project, implementing the game, running it, testing it, and completing the goal when the evidence matches the requirements.

This is the main advantage of the Goal feature. It gives Codex a reason to keep going after the first draft. If a test fails, the browser does not load, or the interaction is broken, Codex can keep working through the issue instead of waiting for you to notice and ask again.

For a small browser game, the run should usually take a few minutes. You can follow along while Codex edits files, starts a local server, opens the browser, and checks whether the game works.

You are still supervising. If Codex starts drifting into unrelated features, interrupt with a direct correction. If the project gets too broad, narrow the definition of done.

Pro tip: Watch for the first plan, not every line of code. The fastest way to save tokens is to catch a bad plan early. If the checklist does not mention testing, controls, scoring, and a failure state, correct the goal before Codex spends time building the wrong thing.

When Codex says the goal is complete, test the game yourself. Move the player. Jump. Score points. Crash. Restart. Make sure the basic loop actually matches the prompt.

If something is broken, do not go back to vague prompting. Give Codex another goal with the exact failure or improvement.

For example:

/goal Improve the Endless Surf Carver demo by adding distinct animations for every action the user can take.

Acceptance criteria:
- Moving left or right has a visible lean or carve animation.
- Jumping has a clear lift and landing animation.
- Crashing has a distinct impact or wipeout animation.
- Restarting resets all animation state.
- Test the game in the browser and summarize what changed.

That prompt works because it names the gap and gives Codex a way to prove the fix. "Make it feel better" would probably waste more tokens. "Add distinct animations for every action" gives the agent a checklist.

This same method works for non-game tasks. The key is to describe what success looks like in a way Codex can inspect, run, compare, or score.

Pro tip: Follow-up goals should be smaller than the original goal. Use the first goal to get a working version. Use later goals to improve one thing at a time: controls, visuals, tests, accessibility, performance, or copy.