How to use Codex to build a traversable space game
Codex built a space game linking flight, landing, walking and takeoff. Journey tests checked transitions while the maker judged controls and rendering limits.
developers.openai.com
Original prompt
Shared by the source author. See source notes for context.
Everything I can see should be reachable. Keep the distances real, then make travel work through scale and speed.
Reach people exploring AI agents
See placements →Evidence at a glance
Sourced account- Source author
- Thomas Ricouard
- Original account
- Read the source ↗
- Published
- Source link checked
- Reported result
- A playable space-to-surface journey was implemented and checked through automated scenes and actual controls. Human play judged feel; software-rendered tests did not measure real GPU performance.
- Human involvement
- Ricouard selected visual references, played the actual controls and judged movement and game feel beyond the agent's browser checks.
A linked account supports attribution. It does not mean we independently reproduced its result.
Report an issue with this case
Open correction emailOpens your email app with the case link included. Nothing is sent automatically.
How the agent did it
- Ricouard supplied the reachable-world requirement and selected visual references.
- Codex implemented terrain, coordinate handling and transitions from space flight to walking.
- Automated scene checks and full control-driven journeys supplemented the author's play sessions.
Thomas Ricouard used Codex with Astra to build Void Explorer, a space game whose defining requirement was that visible worlds should be reachable. The intended journey included flying to a planet, descending, landing, walking, returning to the ship and taking off again.
Ricouard chose visual references and iterated the palette while Codex implemented the game in TypeScript and Three.js. The work included moving rendering from WebGL2 to WebGPU, generating terrain in workers and using observer-relative coordinates to keep local movement precise across large distances. Terrain proxies stayed visible until more detailed replacements were ready.
Verification included named scenes and a browser test interface, but also complete journeys using actual controls. Playwright inspected state and screenshots; Vitest checked generation and coordinate contracts. Preset scenes made failures repeatable without substituting for the travel experience itself.
The result was a playable space-to-surface loop documented by its builder. Ricouard still played to judge control feel, which automated checks could not settle. He also identified limits: headless Chromium used software rendering, so those runs did not prove real GPU performance, and heightfield terrain did not support caves or overhangs. The useful evidence is a connected journey and the checks protecting its transitions.
Prompt
Original prompt
Source: OpenAI developer blog · Thomas Ricouard
Frequently asked questions
Why test a complete journey?
Preset scenes alone did not prove that flight, landing, walking and takeoff connected correctly.
What did browser checks inspect?
Game state and screenshots through a dedicated test interface.
Did headless tests establish GPU speed?
No. The headless browser used software rendering.
More details
About this account
Ricouard supplied the reachable-world requirement and selected visual references. Codex implemented terrain, coordinate handling and transitions from space flight to walking.
Vendor-published firsthand build account opened. Original prompt excerpt is from the author's explicitly edited published prompts. Headless software rendering is not a real-GPU performance measurement; terrain remains a heightfield. Original prompt excerpt.
Credit: Thomas Ricouard — OpenAI developer blog
Source published
Added to Agents In Use
Source checked
Tools and topics
Codex · Three.js · TypeScript · Vite · Playwright · Vitest
Space exploration · Journey tests
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.