Formula Forge

An open source, Linux-native, open-wheel racing game

Comment 1

Inspiration

I loved playing Beach Buggy Racing, but it is not available natively on Linux. That made me wonder if I could build a racing game that captured the same fun while taking the project in a direction closer to another interest - F1.

Modern licensed F1 games are also paid, closed-source products, and Linux players have relatively few native alternatives. I wanted to create something open source that Linux users could build, play, inspect, and improve. Formula Forge also became an experiment: how far could I push Sol toward building a complete 3D racing game with a focus on subjective qualities such as handling, speed, responsiveness, and visual feel.

What it does

Formula Forge is a native Linux, open-source formula racing game. Players can choose a circuit, car, and race distance, then enter either a solo time trial or a full race against AI opponents.

The current build includes:

  • Five circuits
  • Five car liveries
  • A six-car racing grid
  • Manual sequential shifting
  • Controller and steering-wheel input
  • Lap timing
  • Track-limit behavior
  • Collisions
  • Competitive AI opponents

The vehicle model accounts for combined tire grip, aerodynamic downforce and drag, load transfer, trail braking, engine braking, high-speed understeer, and surface changes. The goal is to feel convincing and rewarding without requiring licensed cars or championship branding.

How we built it

With a lot of Sol-high.

I treated Codex as an active engineering partner rather than a one-shot code generator. Formula Forge is written in C++20 and uses SDL3 for input and audio, raylib for real-time 3D rendering, and Blender's Python API for its asset pipeline. Codex helped design and implement the driving model, race flow, AI, rendering, UI, input handling, procedural audio, asset generation, validation tools, and documentation.

The development loop was highly iterative. I would describe a target experience, run the game, explain what felt wrong, and ask Codex to diagnose the underlying system. When natural-language feedback was not precise enough, we built tools that made it precise. Deterministic physics and race audits measure acceleration, braking, shifting, grip, collisions, AI pace, checkpoints, and lap progression. Visual capture tools render repeatable frames for inspection. A persistent JSONL agent-play protocol lets a model control the game, advance the simulation, read telemetry, and request screenshots. Blender scripts generate editable .blend sources, runtime .glb files, previews, and metadata, while separate verification scripts check dimensions, required objects, animation contracts, track geometry, and clearances.

The combination of conversation, executable tests, telemetry, and visual feedback allowed Codex to work on problems that would otherwise be too subjective to specify reliably.

Challenges we ran into

The first major challenge was visual quality. Early assets were assembled procedurally from simple spheres and cuboids. They were enough to prove the gameplay loop, but they did not look like a cohesive 3D racing game. We moved asset production into Blender and used its Python API to generate reproducible cars, drivers, circuit environments, garage scenes, and loading artwork. This preserved the speed of code-driven iteration while producing editable source assets and proper runtime exports.

The second challenge was communicating drivability. Feedback such as "the car feels slow," "turn-in is too sharp," or "the AI does not attack the corner" is meaningful to a player but ambiguous to a coding agent. We translated that feedback into measurable behavior: speed envelopes, stopping distances, steering response, tire-budget usage, gear selection, corner approach speed, apex behavior, track-limit excursions, and lap stability. Once Codex could observe those signals programmatically, it could diagnose problems and verify changes instead of guessing.

Tracks introduced another layer of difficulty. A circuit must look plausible while its centerline, road width, elevation, barriers, runoff, checkpoints, rendering, and collision geometry all agree. Automated track audits became essential for catching false intersections, bad clearances, incorrect turn direction, and visual or physical misalignment.

Accomplishments that we're proud of

The biggest accomplishment is that Formula Forge is a working game rather than only a prototype or visual demo. It has a complete selection-to-race loop, responsive controls, time trials, races against AI, results, restart and pause flows, authored 3D assets, and handling that feels recognizably like a high-downforce formula car.

I am particularly proud of the development infrastructure behind it. Codex can do more than edit the source: it can run deterministic audits, drive the game through a machine-readable protocol, inspect telemetry and captured frames, and use those observations to guide another iteration. The same checks protect completed gameplay systems while graphics and game design continue to evolve.

The project also runs natively on Linux, supports gamepad, and steering-wheel input, and remains fully open source. That makes it both a playable game and a foundation other developers can study or extend.

What we learned

GPT-Sol is considerably more capable than I initially assumed, especially when it is given a way to observe the consequences of its work. The limiting factor was often not whether the model could solve a difficult problem, but whether I had described the problem in a form it could test and reason about.

The most effective pattern was to give it harder problems, identify exactly where it became stuck, and then build a programmatic way for it to obtain the missing feedback. A vague handling complaint became telemetry and deterministic tests. A visual complaint became repeatable screenshots. Asset quality became a Blender pipeline with validation. Track correctness became a geometry audit.

I learned that working with Codex is less about repeatedly asking for more code and more about designing a productive feedback loop. When the agent can build, run, observe, measure, and verify, it can push much further than it can from a prompt alone.

What's next for Formula Forge

The immediate priorities are more circuits, more original cars and driver identities, richer environments, improved materials and lighting, and a fuller soundscape. I also want to continue refining the handling with feedback from more players and a wider range of controllers and steering wheels.

Longer term, the SDL3 and raylib foundation should make Windows and macOS builds possible. Formula Forge is currently developed and tested on Linux, so cross-platform support will be added only when those builds can be tested honestly. Other future goals include expanded race formats, stronger AI racecraft, setup options, better accessibility, and a contributor-friendly pipeline for adding community-created cars and tracks.

Built With

Share this project:

Updates