The earlier 72-hour 3D game article explored a workflow involving AssetHub, Blender, Unreal Engine, and Claude Code. What would a practical version using ChatGPT and Codex look like?
I would begin with a small, playable objective. Use ChatGPT to make the design explicit, let Codex work on the project in manageable steps, then test the result in the engine. The example here is a fictional game called Night Market Hunt. This is a proposed development workflow, not a completed case study or a promise about how many hours it will take.
Give each tool a clear job
For this workflow, ChatGPT is the planning partner: narrow the idea, discuss rules, and review player feedback. Codex handles project work: inspect files, implement changes, and run available checks. These are working roles, rather than exclusive product capabilities.
ChatGPT can use supplied files and context; Codex provides development workflows including code review and terminal tools. Actual access depends on the environment and permissions. See the official ChatGPT guide and Codex developer documentation.
The engine remains the place where the design meets reality. A description of responsive movement cannot tell you whether moving around a stall actually feels good.
1. Define a complete one-minute experience
Night Market Hunt needs a player, a small market, five collectible objects, and an exit. Collect all five, reach the exit, see a completion screen, and restart.
Keep the first build deliberately narrow:
- Windows desktop, keyboard controls.
- One small plaza with three stalls and a readable route.
- A capsule-shaped placeholder player.
- WASD movement and a fixed elevated camera.
- Five objects, each counted once.
- A counter, a completion message, and a restart button.
- No jumping, enemies, inventory, multiplayer, or open world.
Leaving out jumping removes another movement and collision problem from the first milestone. Add it later only if it improves the game.
Start with this ChatGPT prompt:
Write a one-page brief for Night Market Hunt.
Use Godot 4.x, Windows desktop, WASD movement, and a fixed elevated camera.
The player collects five objects and then reaches the exit.
Include the core loop, scene list, controls, victory condition,
five observable acceptance criteria, and features excluded from version one.
Flag unanswered design questions. Do not add combat or multiplayer.
Review the answer before implementation. Is one minute an expected play length or a hard countdown? Those choices require different rules. Resolve that ambiguity yourself.
2. Prepare a real engine project
This example uses Godot to illustrate a scene-and-script workflow. If you already work comfortably in Unreal or Unity, apply the same task structure there.
Godot's first 3D game tutorial covers movement, collisions, interactions, and interface basics. It also notes that 3D is more complex than 2D. Newcomers should learn the engine fundamentals before asking an agent to extend a project they cannot inspect.
Install the editor, prepare Codex and Git, and create a separate game folder. Record the actual engine version rather than telling Codex to use “the latest.” Create a basic 3D project in the editor, save its main scene, and confirm that it runs.
Save the agreed design as GAME_BRIEF.md. Planning in a ChatGPT conversation does not automatically place those decisions in a separate Codex project; save or attach the relevant material explicitly.
3. Write down the project rules
Place an AGENTS.md file in the game repository. Codex supports project instructions through these files; the official AGENTS.md guide explains their discovery rules.
For this game, useful instructions would be:
Use GAME_BRIEF.md and the installed Godot version as the project reference.
Use GDScript and avoid Godot 3 APIs.
Start with primitive shapes; do not add plugins or external assets yet.
Complete one playable feature at a time.
Read existing files before changing them.
Preserve working input bindings, scene references, and resource paths.
Separate file checks, engine execution, and human playtesting in reports.
Mark anything not actually run or played as unverified.
These are instructions for the game project, not configuration for this website. Commit each working milestone so there is a known playable state to return to.
4. Build a graybox before adding artwork
A graybox replaces finished art with planes, blocks, and simple colors. It lets you test space and movement without importing an asset pipeline first.
Give Codex a small initial task:
Read GAME_BRIEF.md, AGENTS.md, and the existing Godot project.
Implement only the graybox level, WASD movement, and fixed camera.
The player must move, remain inside the arena, and collide with stalls.
Diagonal movement must not be noticeably faster than straight movement.
The camera must show the player and main route.
Do not add collectibles or finished artwork.
Report changed files, checks actually performed, and editor checks I must do.
A possible Godot 4 structure uses CharacterBody3D for the player, static collision bodies for obstacles, and later Area3D for pickup detection. Treat that as an implementation direction to check against the project, rather than a ready-made scene.
Walk into walls, move diagonally, slide around stall corners, and follow the entire route. If the basics fail, decorating the scene will make diagnosis harder.
5. Implement pickups, then completion
First implement one collectible: touching it removes it and increments the counter exactly once. Verify it before placing all five. Then add the exit and restart flow.
A useful task includes the edge cases:
Implement five collectibles, the counter, the exit, and restart.
Each object must increment the counter only once.
Entering the exit too early must show how many objects remain.
After all five are collected, entering the exit shows completion.
Restart restores the player, all collectibles, and the 0/5 counter.
The completion screen stops movement and repeated victory events.
Preserve the existing movement and collisions. Provide playtest steps.
Try entering the exit with one item missing, touching it repeatedly after winning, and collecting everything again after a restart. A victory message alone does not establish that the state transitions work.
6. Turn player feedback into reproducible tasks
Discuss “this feels confusing” with ChatGPT. Give Codex a concrete reproduction when asking for a fix:
In the market scene, walk from spawn to the collectible behind the left stall.
The counter occasionally jumps from 0/5 to 2/5 after one pickup.
Expected: each object adds exactly one.
Check for duplicate signal connections or repeated pickup events.
Explain the identified cause, make the smallest fix,
and check normal pickup, repeated contact, and restart.
For a design problem, such as an exit that players cannot find, share a screenshot and observations with ChatGPT. Ask for three small changes and their likely effects. Choose one before asking Codex to implement it.
Changing the lighting, camera, route, and movement speed simultaneously makes it hard to learn what helped. A screenshot supports discussion of composition; it does not prove that a moving camera or collision response works. A recording, logs, and clear reproduction steps often provide better evidence.
7. Replace artwork only after the loop works
Now introduce stall models, materials, lighting, and sound. Use assets you made or have appropriate permission to use, and check the provenance and usage conditions of generated material too.
Replace one stall first. Check scale, orientation, materials, and collision before replacing the others. A visible table might have a collision shape that blocks the entire path; a new model might hide an existing pickup. Walk the route again after each asset category changes.
Character models introduce rigging and animation work, so keeping a capsule in the prototype is reasonable. Blender can help prepare models when necessary, but it is not a compulsory first step.
MCP is optional. Codex supports external MCP tool connections, but that does not mean a Godot or Blender service is already configured. Direct editor operations require suitable tooling. Otherwise, Codex edits the accessible files and you perform the editor actions.
8. Check, export, and test outside the editor
Keep three separate records: file and resource checks, actual engine runs, and human playtests. Do not describe “no reported script errors” as “the game is fun.”
If your Godot editor executable is available as godot in the terminal, run this from the game project root:
godot --headless --path . --import
It waits for resource imports and exits. Inspect the logs, then run the game normally. This check does not validate camera visibility, player understanding, or a complete playthrough. On Windows, use the editor executable's actual path if you have not configured a command alias.
Next, install export templates matching the editor version, configure a Windows export preset, and create the output directory. If the preset is named Windows Desktop, export with:
godot --headless --path . --export-release "Windows Desktop" builds/night-market.exe
The preset name must match the project configuration. The official command-line reference documents these options and requirements. Keep any required companion files and share the complete export folder.
Launch that exported build outside the editor. Test movement, collection, early exit entry, victory, restart, and quitting again. If possible, give it to someone who has not seen the brief, without explaining the route first. Record where they hesitate or ask what to do next.
That produces something useful to iterate on: a prototype another person can actually play. ChatGPT helps make the decisions explicit, Codex helps turn those decisions into project changes, and repeated playtests tell you which changes deserve to stay.
