Since the launch of ChatGPT Astra, my feed on X (formerly Twitter) has been full of posts about people building games with Codex. I’ve always been interested in building a game, but my previous attempts have never been particularly successful. Seeing what other people were creating, I decided to give it another go.
I wanted to capture something I still enjoy about classic arcade racers: fast cars, loose surfaces, and the satisfaction of holding a slide through a corner.
Using Codex and ChatGPT Astra, that idea became DUSTLINE, an original 3D rally game built with Three.js, TypeScript and Vite. The interesting part was the process after the first playable version: driving it, noticing what felt wrong, and turning that feedback into the next change.
Starting with a clear brief
The opening request set the direction:
Build a complete playable browser-based 3D arcade rally racing game inspired by the feel of classic 1990s arcade rally games such as Sega Rally, but using entirely original code, assets, branding, cars, tracks, UI, sounds, and visual design.
The game must run in a modern desktop and mobile browser.
The full brief covered a lot, but its central requirements were straightforward:
- One original rally car and a complete circuit.
- A third-person chase camera and forgiving arcade handling.
- Drifting, different road surfaces, and AI opponents.
- Laps, checkpoints, timing, and race positions.
- Keyboard, touch, and gamepad controls.
- A modular codebase with handling values that could be tuned easily.
The driving model was the priority. The car needed to slide in one direction while travelling in another, then recover from that slide smoothly. A realistic vehicle simulator was not the goal.
From specification to something playable
Codex created a plain TypeScript application using Three.js for rendering and Vite for development and production builds. There was no React layer or full vehicle physics engine.
The first implementation established the world, the car, surface detection, steering, and the chase camera. The remaining systems followed: five opponents, three-lap races, ordered checkpoints, a HUD, menus, dust, skid marks, and synthesized audio.
The game developed its own identity: DUSTLINE, the Kestrel RS rally car, and the fictional Bracken Ridge circuit. Cars, scenery and track geometry were generated in code, avoiding a dependency on externally modelled assets.
A private browser link made the game available to try. That changed the conversation. Instead of describing a hypothetical racing game, I could react to the one in front of me.
The live game’s chase camera, race HUD and Bracken Ridge circuit.
The first drive revealed the real work
My early feedback was direct:
Make AI cars more competitive, it is currently too easy.
I also asked for more drift, better vehicle collisions, improved road and dirt surfaces, blended transitions, and slightly bigger jumps.
Those requests exposed limitations in the first implementation. The AI braked conservatively and tended to slow behind other cars. Vehicle collisions used a small circular approximation that did not properly represent the bumpers.
Codex revised the AI’s pace and passing behaviour, introduced oriented body collision bounds, and added controlled rotation from impacts. Road rendering gained asphalt grain, gravel detail, muddy wheel tracks, and gradual surface transitions. Jump behaviour moved toward a gravity-based airborne arc.
Simulation tests gave us useful comparisons. After that first competitive-AI revision, solo laps were approximately 1:40–1:44, compared with roughly 2:05–2:22 previously. That did not prove the game was fun, but it showed that the opponents were measurably quicker.
Better cars, then better handling
The original cars were functional but visibly basic. I asked for more realistic models.
The revised Kestrel gained shaped body panels, wheel-arch openings, sloped glazing, pillars, mirrors, wipers, alloy spokes, projector headlights, and more detailed rally trim. Body parts were grouped by material to limit rendering overhead across the six cars.
Handling needed more iteration. I asked for additional oversteer, then a 20% speed increase, and eventually a maximum speed of 130 MPH.
One useful detail emerged here: increasing a configuration value called “maximum speed” does not necessarily make the car reach it. Acceleration, drag and rolling resistance interact. Codex adjusted those together and added tests for actual terminal speed, followed by a test confirming the later 130 MPH limit.
More drift was not the whole answer
Eventually I said the physics still did not feel quite right. Increasing oversteer had made the car slide more, but that alone did not recreate the satisfying balance I wanted.
I supplied a Sega Rally gameplay video as a reference. Codex inspected sampled frames, including dirt sections and later bends. That provided visual context, although it could not reveal the player’s inputs or Sega Rally’s internal physics.
The next revision changed the handling approach:
- Rotation built progressively through a damped yaw response.
- Simplified weight transfer changed front and rear grip under braking.
- Throttle retained more momentum through a controlled slide.
- Counter-steering received a faster response.
- The chase camera moved closer and followed travel direction more.
This was an original approximation of the desired feel, not a recreation of Sega’s physics. It also showed why short feedback loops matter: “more oversteer” and “more enjoyable drifting” are not necessarily the same request.
Playing found problems that builds could not
Some of the most useful prompts were small bug reports.
Cars appeared to fly over the grass. They were using the road’s elevation even where the surrounding terrain sloped down. The fix sampled the rendered ground triangles beneath each car.
The starting grid flashed. The checkered line used separate tiles close to the road surface. Codex removed that potential depth conflict by drawing the pattern directly into the road material.
Cars drove through trees. Collision bounds were added around all 800 tree trunks, scaled to their size and positioned on the terrain.
I also asked for an even closer camera. That was a small adjustment, but it mattered to the sense of speed and connection to the car.
Making the race configurable
The next request was to add sliders for lap count and AI difficulty while preserving the current defaults.
Codex implemented a Race Settings menu with 1–10 laps and Easy through Expert difficulty. The defaults remained three laps and Standard, with Standard preserving the existing AI tuning. Settings were saved locally, and race-time records were separated by lap count and difficulty.
That revision passed its build and 18 automated tests. The Race Settings menu is now available in the published browser game.
Race Settings in the published game, showing the default three laps and Standard difficulty.
What this process taught me
Codex could implement and test changes quickly, but I still had to judge the experience. A passing build cannot tell you whether a slide feels satisfying, whether the camera is too distant, or whether the opponents are enjoyable to race.
Our automated checks covered speed limits, drift recovery, checkpoints, collisions, jumps, AI laps, model geometry, and configurable race settings. They provided useful guardrails. They were not a substitute for browser playtesting or real-device performance testing, which remained incomplete.
The initial brief gave the project structure. The follow-up prompts gave it direction. Each drive produced a more specific observation, and each observation became a concrete change to try.
That is what made this an interesting way to build a game: a continuing conversation between the code, the tools, and how the game actually felt to play.
DUSTLINE was deployed to Cloudflare Pages, making it easy to share and play directly in a browser.