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 →What happened
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.
Reported by Thomas Ricouard — OpenAI developer blogHow 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.
Where a person stepped in
Ricouard selected visual references, played the actual controls and judged movement and game feel beyond the agent's browser checks.
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 4 Sept 2026
Source checked 14 Oct 2026
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.