Developer guide · Codex game workflow

Long-running game projects with Codex

A prompt-first sequence for establishing an achievable visual direction, building a focused playable slice, and asking Codex to create a standing game-director goal. The goal maintains checkpoints, releases, roadmap, and changelog as the game develops.

Step 1 · Start the game

Set the direction, then build.

Edit the bracketed lines and paste the first prompt. Codex shows a few achievable gameplay states and proposes the systems before building. React to those, then use the short follow-up.

Why concepts first

MiniTown started with an empty plot, a first developed block, and a living town. Those states gave the first slice a concrete visual target.

I want you to create a game with me.

Idea: [one-sentence game idea]
Player fantasy: [who I am and what I get to do]
Core action: [the action that should feel good first]
Vibe: [visual, audio, pace, mood]
References: [games, films, images, sounds, or genres]
Avoid: [things that would make it feel generic or wrong]
Target: [browser / desktop / touch / controller]

Turn this into a focused game direction yourself. Make reasonable technical and gameplay decisions without asking me to design every system.

Before building, use $imagegen to generate a few gameplay concepts showing meaningful states of this same game—for example the starting state, the first satisfying moment, and a developed state.

Keep the camera, visual language, scale, and UI consistent across the concepts. Make them look like playable screens, not promotional art. Keep every image technically achievable with the simple models, sprites, generated art, and rendering you can actually build. Show enough variation in recurring buildings, characters, vehicles, or props that the world will not feel repetitive.

Show me the concepts and explain the proposed gameplay systems. Then stop so I can react before you build the slice.

Use the approved concept direction and proposed systems to build the first playable vertical slice.

Build the smallest 5–10 minute slice that proves the vibe, controls, camera, core action, feedback, one meaningful choice, one pressure state, and one payoff. Stay close to the established camera, visual language, and gameplay states. Keep the design on rails; do not add broad progression, large content catalogs, multiple modes, or secondary systems yet.

Create and maintain whatever roadmap, changelog, versioning, tests, debug routes, and project notes you need. Do not ask me to create or manage files.

Run it, play it, test it, and show me the playable build. Stop before expanding so I can react to the actual game.

Step 2 · Play and react

Give feedback on the build.

Describe what you felt while playing. Codex turns that feedback into one focused, tested change.

“Movement is too floaty. I want more weight.”

“Combat is readable, but hits do not feel rewarding.”

“Keep the empty VHS mood. Do not turn this into an action game.”

“The map needs more reasons to explore, not more UI.”

Play the current build before changing it.

My feedback: [say what feels wrong, missing, too strong, too weak, too generic, or especially good]

Interpret that feedback against the original game idea. Find the single biggest mismatch, fix it as one focused checkpoint, and verify the change in real gameplay on the target inputs and viewport.

Preserve what already feels right. Do not add unrelated breadth. Update the project history and show me the improved build.

Step 3 · Set the long-running goal

Ask Codex to set the goal.

Once the first slice has a clear direction, paste this prompt. Codex reviews the game, proposes a goal for it, and asks about the few choices that still need your input.

Codex managesArchitecture · checkpoints · tests · roadmap · changelog · versions

Approved authorityCommit · push · deploy · verify · continue

Human choicesGame promise · taste · boundaries · exceptional external changes

Inspect this game as it exists now, then create the right long-running Codex goal for it.

Before creating the goal:
1. Read the full repo, history, current roadmap/changelog, and prior validated checkpoints.
2. Run and play the latest build yourself.
3. Summarize the game's player promise, strongest qualities, weakest areas, and current technical risks.
4. Propose the goal in plain English and ask me only about unresolved taste or product choices.

The goal you create must make you the game's technical and gameplay director. It must:
- preserve the established fantasy, feel, art, audio, controls, and design decisions;
- resume from the latest verified checkpoint instead of restarting ideation;
- begin every cycle by playing and identifying the highest-leverage player-visible weakness;
- implement one bounded, meaningful improvement at a time;
- validate the real rendered game, not only tests or code;
- keep the approved gameplay concepts as visual references; when a visual gap becomes the main weakness, compare the current build with the relevant concept and use that comparison to choose the next checkpoint;
- maintain the roadmap, changelog, version history, and human-readable devlog yourself;
- prefer depth and polish over adding parallel systems or checklist content;
- be authorized to version, commit, push, deploy, and verify each checkpoint once its quality gates pass;
- update the companion website after every shipped checkpoint;
- continue choosing and shipping the next checkpoint without routine approval.

The goal should stop and ask only before changing the core game promise, crossing an explicit no-go boundary, spending money, adding a paid service or secret, changing access or ownership, taking an irreversible action, or shipping something it cannot verify.

Once I approve your proposal, create the goal and begin. Craft it from this game; do not return a blank template.

See an example of the goal Codex might create

Continuously improve this game as its technical and gameplay director.

Start from the latest verified build. Preserve the player fantasy and established feel. For each checkpoint: play the current game, identify the most important player-visible weakness, implement one bounded improvement, validate it in real gameplay, update the roadmap/changelog/devlog, version it, commit, push, deploy, verify live, then select the next checkpoint.

Keep the approved gameplay concepts as visual references. When the main weakness is visual, compare the matching rendered state with the relevant concept and use the visible gap to choose the next checkpoint.

Prefer depth, clarity, feel, reliability, accessibility, and performance over breadth. Do not add new systems from checklist symmetry. Continue without routine approval inside the standing mandate. Pause only for a changed game promise, cost, new external service, access/ownership change, irreversible action, or an improvement that cannot be verified.

After the goal is approved

How a checkpoint runs.

Each checkpoint starts from the current build and ends with a verified release plus a short update.

CodexActionProof before continuing

PLAY

Run the current local and deployed build.

Observed issues, ranked by player impact.

CHOOSE

Select one meaningful weakness.

A bounded checkpoint with clear acceptance checks.

BUILD

Make the smallest complete improvement.

Working code and reproducible coverage.

VERIFY

Play the rendered game with the target inputs.

Evidence that the change works without regressions.

SHIP

Version, commit, push, deploy, and check the build live.

A playable release and an updated log.

REPEAT

Choose the next issue from what the build shows.

The next focused checkpoint.

Within the approved goal.

Codex can commit, push, and deploy a verified checkpoint without asking again. It pauses when the work crosses the agreed boundaries.

Step 4 · Ask for the companion

Add a companion site.

This prompt asks Codex to publish the playable build beside a short record of what changed, what is in progress, and what comes next.

PLAYNOWNEXTLOG

Create and maintain a companion website for this game using Sites.

The page must let visitors:
1. PLAY the latest verified build immediately.
2. See what Codex is improving NOW and why it was chosen.
3. See the next three human + Codex curated ideas, in order.
4. Read a short, human-friendly LOG of shipped checkpoints: what changed, what play taught us, and what comes next.
5. See concise proof for each release: version, real-play validation, and deployed status.

Read the game repo, history, roadmap, changelog, and releases yourself. Create any data export or internal files you need; do not ask me to maintain them.

After every shipped game checkpoint, update and deploy this companion site automatically. Keep raw technical detail available but make the default log readable by players.

Step 5 · Run the stream

Continue the same task.

Use the same Codex task and active goal. Each session continues from the latest verified checkpoint.

Resume the active game-director goal in this same task.

Work in complete checkpoints: play the latest verified build, choose the highest-leverage improvement, implement it, validate the real game, update the project history and companion site, version, commit, push, deploy, verify live, and continue to the next checkpoint.

Do not stop for routine approvals inside the standing mandate. Stop only at the goal's explicit boundary conditions or when no safe verified progress is possible.

When Codex pauses

A change to the core game promise or explicit no-go.
A paid service, secret, account, or spending decision.
An access, ownership, or public-sharing change.
A destructive or irreversible action.
A checkpoint it cannot safely test or verify.

Within those boundaries, the goal continues through verified checkpoints.

From the task history

Concept → implemented.

Left: generated direction. Right: a real captured build. These are four actual comparisons, not generated “after” images.

01 · First playable slice

Phantasy Codex Adventure

The forest camera, action framing, and HUD rails carried into the first playable build.

02 · Inventory · v0.39

Phantasy Codex Online

The equipped rail, item grid, detail pane, and salvage flow became working UI.

03 · Mid-project visual pass

Backroom Center: Corrupted

This target was generated from a live frame during polish. The right frame is a later local pass, not the hosted checkpoint.

04 · Cozy night state

MiniTown

The isometric grid, warm windows, roads, and tool rail stayed legible in the built night state.

Playable projects

Games behind the workflow.

Four deployed projects made with this checkpoint-based approach. Open a build to see the results.

01Phantasy Codex Adventure

A standing goal moved the game through small, verified, deployed checkpoints.

Open game ↗02Phantasy Codex Online

A related project kept the established feel while developing its own gameplay loop.

Open game ↗03Backroom Center: Corrupted

Precise play feedback gave each atmosphere and interaction pass a clear target.

Open game ↗04MiniTown

Concept states set the direction before a playable town and its night pass were built.

Open game ↗