{"cover":"/content/images/2026/10/9e08d4941150-social-background.png","hero":"/content/images/2026/10/5febc720f2c6-nullg-rl-hero.png","heroes":{"59ab1e54b3a5386e6900ca8678d4e839":"/content/images/2026/10/b1e12503f058-nullg-rl-full-preview.png","7b367212a739706ba4e3e9b999bec15d":"/content/images/2026/10/5febc720f2c6-nullg-rl-hero.png"},"kind":"project-blog","logo":"/content/images/2016/08/projectable-me-4.png","nav":[{"id":"62e854d471683dea63488bcbca5c6188","label":"Home","url":"/","sortOrder":0},{"id":"1bc84fb15620acd635df7735a0b8ddd8","label":"Projects","url":"/projects/","sortOrder":1},{"id":"3207e2fec51d66d2a5b3d8d04feb9dd8","label":"Sim Racing","url":"/tag/sim-racing/","sortOrder":2},{"id":"59115afd52e59a74faa4b386e00ae3fa","label":"About","url":"/about-me/","sortOrder":3}],"page":1,"pageBody":{"id":"6211ca72834fd58a7bec95de2d4d45cc","siteId":"projectable","projectId":"ae4bdb66da6dc1729a263a475e1cdbe3","kind":"blog","title":"Blog","slug":"","markdown":"","html":"","navOrder":1,"status":"published"},"perPage":10,"posts":[{"id":"59ab1e54b3a5386e6900ca8678d4e839","siteId":"projectable","slug":"nullg-reinforcement-learning-journey","title":"Teaching NullG to race: the reinforcement-learning journey so far","markdown":"[NullG](https://projectable.me/projects/nullg/) now has a reinforcement-learning pipeline that can train a pilot in the native racing simulation, export its learned controls into the game, and record complete races for review. The latest footage follows that work into weapon combat: preserving a learned driver while training decisions about when and how to use its inventory.\n\nGetting here has involved several changes of direction. Road observations, steering, rewards, exploration, Turbo handling and combat timing have each needed their own experiments. A useful race raises the next question: which part of the system produced that behaviour, and does it hold up on another circuit?\n\nThe [NullG YouTube playlist](https://www.youtube.com/playlist?list=PLaR-_mRLlb6E) follows the progression through recorded driving and combat runs. This post explains the engineering behind those videos, the external projects informing the approach, and the repeated work between longer training sessions.\n\n## A pilot that drives through the game’s controls\n\nNullG’s starting point is its own C++ racing simulation. Python training tools communicate with isolated native workers, each running a race with the engine’s physics, pickups, weapons and race rules. Gymnasium provides the environment interface, and PyTorch with [Stable-Baselines3 PPO](https://stable-baselines3.readthedocs.io/en/master/modules/ppo.html) provides the main training implementation.\n\nA policy is the neural network that turns observations into controls. Its companion during training, the critic, estimates the return expected from a state. PPO collects experience with the current policy, then makes bounded updates to those networks. In NullG, that experience comes from the same native simulation used by gameplay.\n\nThe pilot receives structured observations: its motion and health, connected road geometry ahead, nearby racers, available pickups, visible projectiles, inventory and previous controls. This gives development direct access to questions such as how far the pilot can see into a corner and how it represents lateral movement across the road.\n\nThe outputs correspond to familiar inputs: throttle, analog steering, left and right airbrakes, pitch and weapon commands. Decisions arrive at 30 Hz through the normal player-input path, while the session advances at 60 Hz with the selected source physics cadence. Movement is held between decisions; weapon commands follow the engine’s input timing.\n\nOnce trained, the actor exports into a compact `.ngpolicy` package. A native C++ evaluator reads the observations and produces controls inside NullG. Python remains part of the development workflow, while the exported pilot runs in the engine. Package metadata records the observation contract, model identity and supported configuration, making the training-to-game handoff inspectable.\n\n![](/content/images/2026/10/b1b8220f350c-nullg-rl-full-title-preview.png)\n\n*The latest recorded evaluation race, presented through NullG’s cinematic replay exporter. The driving policy and the replay camera are separate systems.*\n\n## External projects that shaped the approach\n\nRacing RL already has a substantial body of practical work. NullG uses those projects as references for particular engineering decisions, adapting the ideas to an anti-gravity racer and a native engine.\n\n[Sony AI’s Gran Turismo Sophy training account](https://ai.sony/blog/how-to-train-your-race-car) is a reference for building a varied training regimen. Solo driving, interaction with traffic and specialised situations each contribute useful experience. For NullG, that encourages deliberate coverage of circuits, traffic conditions and difficult states, with several kinds of practice available during development.\n\n[TMRL](https://github.com/trackmania-rl/tmrl), the TrackMania reinforcement-learning framework, is useful for its treatment of real-time control, observation histories, analog actions and off-policy learning. It helped motivate a controlled SAC steering comparison alongside PPO. NullG’s native worker supplies a different integration path, while the timing and control questions transfer well.\n\n[Linesight](https://linesight-rl.github.io/linesight/build/html/main_objects.html) provides another TrackMania reference, including its IQN-based approach and explicit reference-line geometry. Its value here is the care given to defining progress and training coverage. [Learn-to-Race](https://github.com/learn-to-race/l2r) adds a useful autonomous-racing environment and baseline perspective: conventional and learned controllers can be compared through a clearly defined task.\n\n[CAPS](https://ai.bu.edu/caps/) informs the smooth-control studies. Action variation and the frequency content of motion provide ways to examine steering quality. That sits alongside a separate question about exploration: the sampled actions used while learning and the deterministic controls used by an exported actor can behave differently.\n\n[NeuralKart](https://github.com/rameshvarun/NeuralKart) supplies a practical reference for searching for useful driving actions and learning from them. NullG adapts that principle using native snapshots from states reached by its own learner. [DAgger](https://proceedings.mlr.press/v15/ross11a.html) gives the broader rationale for collecting corrective examples where the learner actually drives, as successive actions change the states it encounters.\n\nThese references contribute different pieces: curriculum design, control timing, progress geometry, smoothness, baseline comparisons and corrective data collection. NullG combines them with its existing simulation, input and replay systems.\n\n## Giving the driver useful information\n\nEarly work established the loop from observation to action, followed by closer examination of what the network was actually receiving. That led to an audit of observation scaling, feature connectivity, road preview and the steering adapter.\n\nScaling deserves attention because a number can be technically present yet convey very little useful variation after normalisation and clipping. The corrected foundation uses explicit physical scales and identity normalisation for its observation contract. Checks also trace new features through to the network inputs, so a change to the observation layout has a verifiable effect on the model being trained.\n\nRoad guidance then became more explicit. The pilot receives road-forward directions, heading error, longitudinal and lateral velocity, displacement across the road, curvature and available clearance. Connected-road projection gives those measurements a continuous position along the route, including the neighbourhood of section boundaries and qualified junctions.\n\nThat same care applies to progress rewards. Canonical road distance and high-water accounting make forward progress meaningful across the track’s connected geometry. Pickups and boost pads have their own bounded contributions. A reward can then describe a useful driving objective with a clear relationship to what happened on the circuit.\n\nSteering also moved to a native analog contract, with 513 signed positions available through the XL input adapter. A controlled comparison could then ask about the observation design while holding the control protocol and experience budget steady. Another steering study compared PPO and SAC under the same restricted auxiliary controls. Those experiments narrowed individual design choices before the full driver took on more responsibilities.\n\n## The repeated work between longer runs\n\nThe development record across October 15–20 contains an ongoing cycle of collecting races, reviewing telemetry, making a focused adjustment, and testing the resulting policy again. This has occupied a substantial part of the RL work alongside the training itself.\n\nSeveral strategies needed revisiting. Increasing a steering-change penalty could make sampled inputs look quieter, so review expanded to the policy’s mean output and the ship’s actual heading and lateral motion. Longer road preview and different brake commitment were tested separately. Exploration settings were examined alongside deterministic native inference, giving both the training behaviour and the exported driver a direct comparison.\n\nTurbo made preservation especially important. A steering change affects the trajectory from which Turbo is used, even when the weapon-control weights stay identical. Naturally earned Turbo states therefore became part of the review panels and corrective training anchors. Useful speed, health, recovery and the rest of the race all contribute to judging the manoeuvre.\n\nThe corrective-driving work took another route. Native snapshots preserve a state reached by the learner, then development tooling tries small steering interventions from that same state. Accepted examples become training labels, with unchanged actions retained as anchors. Focused work on Gare d’Europa and Odessa Keys added longer follow-through checks and preservation samples from the other circuits.\n\nEach revision brought additional work around the optimiser: reconstructing states, verifying the replayed baseline, collecting examples, fitting a bounded update, exporting the actor and running complete races. Longer safety follow-through was added to examine the consequences beyond a promising short steering branch.\n\nThe time involved can be described concretely from the run receipts. Three completed combat jobs alone—the eight-hour run on October 18, the four-hour run on October 19, and the latest four-hour continuation—account for **more than 16 hours of training wall time**. Short comparison arms, earlier driving work, evaluation races, corrective searches and media production add to that. Those three jobs branch from selected earlier checkpoints, so their durations describe compute spent across experiments rather than sixteen uninterrupted hours on one policy.\n\nThe records establish those training durations. Reading references, inspecting footage and revising the tools also take development time; that human work has no consolidated hour counter in the run receipts. The visible pattern is a sequence of experiments and adjustments over several days, with longer jobs following more focused checks.\n\n## From driving practice to racing and combat\n\nThe driving foundation gave the pilot room to practise navigation, traffic, pickups and earned Turbo. Combat then introduced a different timing problem: choosing an action now can affect another racer several seconds later, and that exchange can change the final placing.\n\nThe approach evolved toward training the weapon outputs and critic while freezing the actor’s driving features and movement outputs. That lets the combat experiment build on an existing driver. Weight checks verify the protected parameters, while complete races show how the new combat choices affect the resulting trajectories.\n\nThe objective also became explicitly placement-first. Race outcome has the dominant reward, with bounded auxiliary credit for effective combat and useful pickups or pads. Shot count by itself receives no bonus. The critic and credit-assignment settings then become important parts of learning when a weapon opportunity is worth taking.\n\nExperiments examined longer credit assignment, combat reward weighting and critic calibration. Calibration fits the value estimate to returns collected from the retained policy, while preserving the actor. Opportunity starts reconstruct naturally reached situations with offensive inventory and nearby opponents, giving the learner more practice around decisions that may be relatively sparse in ordinary races.\n\nThe latest configuration combines ordinary races with ten-second combat opportunity windows. These windows start from verified native states and collect fresh actions from the current policy. Their training cutoff is handled separately from a race finish or elimination, preserving the meaning of the full-race objective.\n\nTraining opposition has expanded too: original XL opponents, a retained learned challenger, and mixed fields provide different contexts. The active development rotation is Talon’s Reach, Sagarmatha, Gare d’Europa and Odessa Keys.\n\n## What the latest four-hour continuation did\n\nThe latest completed continuation began at the earlier combat run’s hour-two checkpoint. Four CPU workers added **6,639,616 decisions**, moving the checkpoint counter from **32,651,264 to 39,290,880**. That number belongs to this checkpoint lineage; it is separate from the experience collected across all the other experiments.\n\nThe run preserved the driving parameters and continued learning weapon outputs and the critic. Its recorded settings retained a placement-first objective, gamma 1.0, GAE lambda 0.95, combat reward scale 1.0 and 300-decision opportunity windows. In practical terms, the experiment concentrated on combat choices while retaining the driver’s learned control function.\n\nHourly checkpoints made it possible to compare behaviour during the continuation. The subsequent review covered six policies, with 48 standard evaluation races per policy and additional cross-play and confirmation panels. [RLiable’s evaluation guidance](https://research.google/blog/rliable-towards-reliable-evaluation-reporting-in-reinforcement-learning/) informs this emphasis on paired conditions, multiple seeds and the distribution of results.\n\nThe final checkpoint won 18 of its 48 standard-panel races and finished 31. In the additional 24-race confirmation panel, it won 9 and finished 15. Different intermediate checkpoints had different strengths, so the review retains those trade-offs for the next decision. A cinematic race shows the driving and combat in detail; the larger panels establish the context for interpreting it.\n\n![](/content/images/2026/10/b1e12503f058-nullg-rl-full-preview.png)\n\n*Recorded Gare d’Europa gameplay from the final checkpoint. The cinematic director follows racing interest and weapon exchanges across the field, including opponents as well as the learned racer.*\n\n## Watch the latest races\n\nThe videos make the development easier to follow alongside the technical account. Earlier driving updates show the broader training progression; the latest full race and Short focus on racing with weapons. The learned pilot occupies slot 0 in the latest full race, while automatic cinematic cameras also cover other racers and exchanges.\n\n### Learning to fight: the complete Gare d’Europa race\n\nThis complete three-lap race comes from the final checkpoint of the latest four-hour continuation. It runs for approximately three minutes, with native race audio and cinematic presentation.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/__kpDHYbsCg\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n[Watch the full Gare d’Europa race on YouTube](https://youtu.be/__kpDHYbsCg).\n\n### Learning to race and fight: the Short\n\nThe latest Short offers a compact look at the racing and combat work.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/lTbLUj1QKt4\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n[Watch the racing and combat on YouTube](https://youtu.be/lTbLUj1QKt4).\n\n### Earlier training footage: update 3\n\nThis earlier upload is titled “NullG - 8 hour AI driving training 3 (reinforcement learning)” and forms part of the playlist’s training record.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/fkUTwW2p_8k\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n[Watch training update 3 on YouTube](https://youtu.be/fkUTwW2p_8k).\n\n### Earlier training footage: update 2\n\nThe preceding “NullG - 8 hour AI driving training 2 (reinforcement learning)” upload provides another point in that recorded progression.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/9ddeaoyyIY4\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n[Watch training update 2 on YouTube](https://youtu.be/9ddeaoyyIY4).\n\n## Following the next experiments\n\nThe work now has a native training loop, portable in-game policies, corrective driving tools, combat-focused continuations and recorded evaluations to guide further changes. The next direction is to build on the checkpoint comparisons: keep race outcome central, improve the usefulness of weapon decisions, and preserve driving quality across the four-circuit rotation.\n\nThe [reinforcement-learning project page](https://projectable.me/projects/nullg/reinforcement-learning/) describes the engine integration. The [YouTube playlist](https://www.youtube.com/playlist?list=PLaR-_mRLlb6E) follows the training through the races themselves, with the full recordings providing context for each shorter highlight.","html":"\u003cp\u003e\u003ca href=\"https://projectable.me/projects/nullg/\" rel=\"nofollow\"\u003eNullG\u003c/a\u003e now has a reinforcement-learning pipeline that can train a pilot in the native racing simulation, export its learned controls into the game, and record complete races for review. The latest footage follows that work into weapon combat: preserving a learned driver while training decisions about when and how to use its inventory.\u003c/p\u003e\n\u003cp\u003eGetting here has involved several changes of direction. Road observations, steering, rewards, exploration, Turbo handling and combat timing have each needed their own experiments. A useful race raises the next question: which part of the system produced that behaviour, and does it hold up on another circuit?\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://www.youtube.com/playlist?list=PLaR-_mRLlb6E\" rel=\"nofollow\"\u003eNullG YouTube playlist\u003c/a\u003e follows the progression through recorded driving and combat runs. This post explains the engineering behind those videos, the external projects informing the approach, and the repeated work between longer training sessions.\u003c/p\u003e\n\u003ch2\u003eA pilot that drives through the game’s controls\u003c/h2\u003e\n\u003cp\u003eNullG’s starting point is its own C++ racing simulation. Python training tools communicate with isolated native workers, each running a race with the engine’s physics, pickups, weapons and race rules. Gymnasium provides the environment interface, and PyTorch with \u003ca href=\"https://stable-baselines3.readthedocs.io/en/master/modules/ppo.html\" rel=\"nofollow\"\u003eStable-Baselines3 PPO\u003c/a\u003e provides the main training implementation.\u003c/p\u003e\n\u003cp\u003eA policy is the neural network that turns observations into controls. Its companion during training, the critic, estimates the return expected from a state. PPO collects experience with the current policy, then makes bounded updates to those networks. In NullG, that experience comes from the same native simulation used by gameplay.\u003c/p\u003e\n\u003cp\u003eThe pilot receives structured observations: its motion and health, connected road geometry ahead, nearby racers, available pickups, visible projectiles, inventory and previous controls. This gives development direct access to questions such as how far the pilot can see into a corner and how it represents lateral movement across the road.\u003c/p\u003e\n\u003cp\u003eThe outputs correspond to familiar inputs: throttle, analog steering, left and right airbrakes, pitch and weapon commands. Decisions arrive at 30 Hz through the normal player-input path, while the session advances at 60 Hz with the selected source physics cadence. Movement is held between decisions; weapon commands follow the engine’s input timing.\u003c/p\u003e\n\u003cp\u003eOnce trained, the actor exports into a compact \u003ccode\u003e.ngpolicy\u003c/code\u003e package. A native C++ evaluator reads the observations and produces controls inside NullG. Python remains part of the development workflow, while the exported pilot runs in the engine. Package metadata records the observation contract, model identity and supported configuration, making the training-to-game handoff inspectable.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/b1b8220f350c-nullg-rl-full-title-preview.png\" alt=\"\"\u003e\n\u003cp\u003e\u003cem\u003eThe latest recorded evaluation race, presented through NullG’s cinematic replay exporter. The driving policy and the replay camera are separate systems.\u003c/em\u003e\u003c/p\u003e\n\u003ch2\u003eExternal projects that shaped the approach\u003c/h2\u003e\n\u003cp\u003eRacing RL already has a substantial body of practical work. NullG uses those projects as references for particular engineering decisions, adapting the ideas to an anti-gravity racer and a native engine.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://ai.sony/blog/how-to-train-your-race-car\" rel=\"nofollow\"\u003eSony AI’s Gran Turismo Sophy training account\u003c/a\u003e is a reference for building a varied training regimen. Solo driving, interaction with traffic and specialised situations each contribute useful experience. For NullG, that encourages deliberate coverage of circuits, traffic conditions and difficult states, with several kinds of practice available during development.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/trackmania-rl/tmrl\" rel=\"nofollow\"\u003eTMRL\u003c/a\u003e, the TrackMania reinforcement-learning framework, is useful for its treatment of real-time control, observation histories, analog actions and off-policy learning. It helped motivate a controlled SAC steering comparison alongside PPO. NullG’s native worker supplies a different integration path, while the timing and control questions transfer well.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://linesight-rl.github.io/linesight/build/html/main_objects.html\" rel=\"nofollow\"\u003eLinesight\u003c/a\u003e provides another TrackMania reference, including its IQN-based approach and explicit reference-line geometry. Its value here is the care given to defining progress and training coverage. \u003ca href=\"https://github.com/learn-to-race/l2r\" rel=\"nofollow\"\u003eLearn-to-Race\u003c/a\u003e adds a useful autonomous-racing environment and baseline perspective: conventional and learned controllers can be compared through a clearly defined task.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://ai.bu.edu/caps/\" rel=\"nofollow\"\u003eCAPS\u003c/a\u003e informs the smooth-control studies. Action variation and the frequency content of motion provide ways to examine steering quality. That sits alongside a separate question about exploration: the sampled actions used while learning and the deterministic controls used by an exported actor can behave differently.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/rameshvarun/NeuralKart\" rel=\"nofollow\"\u003eNeuralKart\u003c/a\u003e supplies a practical reference for searching for useful driving actions and learning from them. NullG adapts that principle using native snapshots from states reached by its own learner. \u003ca href=\"https://proceedings.mlr.press/v15/ross11a.html\" rel=\"nofollow\"\u003eDAgger\u003c/a\u003e gives the broader rationale for collecting corrective examples where the learner actually drives, as successive actions change the states it encounters.\u003c/p\u003e\n\u003cp\u003eThese references contribute different pieces: curriculum design, control timing, progress geometry, smoothness, baseline comparisons and corrective data collection. NullG combines them with its existing simulation, input and replay systems.\u003c/p\u003e\n\u003ch2\u003eGiving the driver useful information\u003c/h2\u003e\n\u003cp\u003eEarly work established the loop from observation to action, followed by closer examination of what the network was actually receiving. That led to an audit of observation scaling, feature connectivity, road preview and the steering adapter.\u003c/p\u003e\n\u003cp\u003eScaling deserves attention because a number can be technically present yet convey very little useful variation after normalisation and clipping. The corrected foundation uses explicit physical scales and identity normalisation for its observation contract. Checks also trace new features through to the network inputs, so a change to the observation layout has a verifiable effect on the model being trained.\u003c/p\u003e\n\u003cp\u003eRoad guidance then became more explicit. The pilot receives road-forward directions, heading error, longitudinal and lateral velocity, displacement across the road, curvature and available clearance. Connected-road projection gives those measurements a continuous position along the route, including the neighbourhood of section boundaries and qualified junctions.\u003c/p\u003e\n\u003cp\u003eThat same care applies to progress rewards. Canonical road distance and high-water accounting make forward progress meaningful across the track’s connected geometry. Pickups and boost pads have their own bounded contributions. A reward can then describe a useful driving objective with a clear relationship to what happened on the circuit.\u003c/p\u003e\n\u003cp\u003eSteering also moved to a native analog contract, with 513 signed positions available through the XL input adapter. A controlled comparison could then ask about the observation design while holding the control protocol and experience budget steady. Another steering study compared PPO and SAC under the same restricted auxiliary controls. Those experiments narrowed individual design choices before the full driver took on more responsibilities.\u003c/p\u003e\n\u003ch2\u003eThe repeated work between longer runs\u003c/h2\u003e\n\u003cp\u003eThe development record across October 15–20 contains an ongoing cycle of collecting races, reviewing telemetry, making a focused adjustment, and testing the resulting policy again. This has occupied a substantial part of the RL work alongside the training itself.\u003c/p\u003e\n\u003cp\u003eSeveral strategies needed revisiting. Increasing a steering-change penalty could make sampled inputs look quieter, so review expanded to the policy’s mean output and the ship’s actual heading and lateral motion. Longer road preview and different brake commitment were tested separately. Exploration settings were examined alongside deterministic native inference, giving both the training behaviour and the exported driver a direct comparison.\u003c/p\u003e\n\u003cp\u003eTurbo made preservation especially important. A steering change affects the trajectory from which Turbo is used, even when the weapon-control weights stay identical. Naturally earned Turbo states therefore became part of the review panels and corrective training anchors. Useful speed, health, recovery and the rest of the race all contribute to judging the manoeuvre.\u003c/p\u003e\n\u003cp\u003eThe corrective-driving work took another route. Native snapshots preserve a state reached by the learner, then development tooling tries small steering interventions from that same state. Accepted examples become training labels, with unchanged actions retained as anchors. Focused work on Gare d’Europa and Odessa Keys added longer follow-through checks and preservation samples from the other circuits.\u003c/p\u003e\n\u003cp\u003eEach revision brought additional work around the optimiser: reconstructing states, verifying the replayed baseline, collecting examples, fitting a bounded update, exporting the actor and running complete races. Longer safety follow-through was added to examine the consequences beyond a promising short steering branch.\u003c/p\u003e\n\u003cp\u003eThe time involved can be described concretely from the run receipts. Three completed combat jobs alone—the eight-hour run on October 18, the four-hour run on October 19, and the latest four-hour continuation—account for \u003cstrong\u003emore than 16 hours of training wall time\u003c/strong\u003e. Short comparison arms, earlier driving work, evaluation races, corrective searches and media production add to that. Those three jobs branch from selected earlier checkpoints, so their durations describe compute spent across experiments rather than sixteen uninterrupted hours on one policy.\u003c/p\u003e\n\u003cp\u003eThe records establish those training durations. Reading references, inspecting footage and revising the tools also take development time; that human work has no consolidated hour counter in the run receipts. The visible pattern is a sequence of experiments and adjustments over several days, with longer jobs following more focused checks.\u003c/p\u003e\n\u003ch2\u003eFrom driving practice to racing and combat\u003c/h2\u003e\n\u003cp\u003eThe driving foundation gave the pilot room to practise navigation, traffic, pickups and earned Turbo. Combat then introduced a different timing problem: choosing an action now can affect another racer several seconds later, and that exchange can change the final placing.\u003c/p\u003e\n\u003cp\u003eThe approach evolved toward training the weapon outputs and critic while freezing the actor’s driving features and movement outputs. That lets the combat experiment build on an existing driver. Weight checks verify the protected parameters, while complete races show how the new combat choices affect the resulting trajectories.\u003c/p\u003e\n\u003cp\u003eThe objective also became explicitly placement-first. Race outcome has the dominant reward, with bounded auxiliary credit for effective combat and useful pickups or pads. Shot count by itself receives no bonus. The critic and credit-assignment settings then become important parts of learning when a weapon opportunity is worth taking.\u003c/p\u003e\n\u003cp\u003eExperiments examined longer credit assignment, combat reward weighting and critic calibration. Calibration fits the value estimate to returns collected from the retained policy, while preserving the actor. Opportunity starts reconstruct naturally reached situations with offensive inventory and nearby opponents, giving the learner more practice around decisions that may be relatively sparse in ordinary races.\u003c/p\u003e\n\u003cp\u003eThe latest configuration combines ordinary races with ten-second combat opportunity windows. These windows start from verified native states and collect fresh actions from the current policy. Their training cutoff is handled separately from a race finish or elimination, preserving the meaning of the full-race objective.\u003c/p\u003e\n\u003cp\u003eTraining opposition has expanded too: original XL opponents, a retained learned challenger, and mixed fields provide different contexts. The active development rotation is Talon’s Reach, Sagarmatha, Gare d’Europa and Odessa Keys.\u003c/p\u003e\n\u003ch2\u003eWhat the latest four-hour continuation did\u003c/h2\u003e\n\u003cp\u003eThe latest completed continuation began at the earlier combat run’s hour-two checkpoint. Four CPU workers added \u003cstrong\u003e6,639,616 decisions\u003c/strong\u003e, moving the checkpoint counter from \u003cstrong\u003e32,651,264 to 39,290,880\u003c/strong\u003e. That number belongs to this checkpoint lineage; it is separate from the experience collected across all the other experiments.\u003c/p\u003e\n\u003cp\u003eThe run preserved the driving parameters and continued learning weapon outputs and the critic. Its recorded settings retained a placement-first objective, gamma 1.0, GAE lambda 0.95, combat reward scale 1.0 and 300-decision opportunity windows. In practical terms, the experiment concentrated on combat choices while retaining the driver’s learned control function.\u003c/p\u003e\n\u003cp\u003eHourly checkpoints made it possible to compare behaviour during the continuation. The subsequent review covered six policies, with 48 standard evaluation races per policy and additional cross-play and confirmation panels. \u003ca href=\"https://research.google/blog/rliable-towards-reliable-evaluation-reporting-in-reinforcement-learning/\" rel=\"nofollow\"\u003eRLiable’s evaluation guidance\u003c/a\u003e informs this emphasis on paired conditions, multiple seeds and the distribution of results.\u003c/p\u003e\n\u003cp\u003eThe final checkpoint won 18 of its 48 standard-panel races and finished 31. In the additional 24-race confirmation panel, it won 9 and finished 15. Different intermediate checkpoints had different strengths, so the review retains those trade-offs for the next decision. A cinematic race shows the driving and combat in detail; the larger panels establish the context for interpreting it.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/b1e12503f058-nullg-rl-full-preview.png\" alt=\"\"\u003e\n\u003cp\u003e\u003cem\u003eRecorded Gare d’Europa gameplay from the final checkpoint. The cinematic director follows racing interest and weapon exchanges across the field, including opponents as well as the learned racer.\u003c/em\u003e\u003c/p\u003e\n\u003ch2\u003eWatch the latest races\u003c/h2\u003e\n\u003cp\u003eThe videos make the development easier to follow alongside the technical account. Earlier driving updates show the broader training progression; the latest full race and Short focus on racing with weapons. The learned pilot occupies slot 0 in the latest full race, while automatic cinematic cameras also cover other racers and exchanges.\u003c/p\u003e\n\u003ch3\u003eLearning to fight: the complete Gare d’Europa race\u003c/h3\u003e\n\u003cp\u003eThis complete three-lap race comes from the final checkpoint of the latest four-hour continuation. It runs for approximately three minutes, with native race audio and cinematic presentation.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/__kpDHYbsCg\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003ca href=\"https://youtu.be/__kpDHYbsCg\" rel=\"nofollow\"\u003eWatch the full Gare d’Europa race on YouTube\u003c/a\u003e.\u003c/p\u003e\n\u003ch3\u003eLearning to race and fight: the Short\u003c/h3\u003e\n\u003cp\u003eThe latest Short offers a compact look at the racing and combat work.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/lTbLUj1QKt4\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003ca href=\"https://youtu.be/lTbLUj1QKt4\" rel=\"nofollow\"\u003eWatch the racing and combat on YouTube\u003c/a\u003e.\u003c/p\u003e\n\u003ch3\u003eEarlier training footage: update 3\u003c/h3\u003e\n\u003cp\u003eThis earlier upload is titled “NullG - 8 hour AI driving training 3 (reinforcement learning)” and forms part of the playlist’s training record.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/fkUTwW2p_8k\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003ca href=\"https://youtu.be/fkUTwW2p_8k\" rel=\"nofollow\"\u003eWatch training update 3 on YouTube\u003c/a\u003e.\u003c/p\u003e\n\u003ch3\u003eEarlier training footage: update 2\u003c/h3\u003e\n\u003cp\u003eThe preceding “NullG - 8 hour AI driving training 2 (reinforcement learning)” upload provides another point in that recorded progression.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/9ddeaoyyIY4\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003ca href=\"https://youtu.be/9ddeaoyyIY4\" rel=\"nofollow\"\u003eWatch training update 2 on YouTube\u003c/a\u003e.\u003c/p\u003e\n\u003ch2\u003eFollowing the next experiments\u003c/h2\u003e\n\u003cp\u003eThe work now has a native training loop, portable in-game policies, corrective driving tools, combat-focused continuations and recorded evaluations to guide further changes. The next direction is to build on the checkpoint comparisons: keep race outcome central, improve the usefulness of weapon decisions, and preserve driving quality across the four-circuit rotation.\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://projectable.me/projects/nullg/reinforcement-learning/\" rel=\"nofollow\"\u003ereinforcement-learning project page\u003c/a\u003e describes the engine integration. The \u003ca href=\"https://www.youtube.com/playlist?list=PLaR-_mRLlb6E\" rel=\"nofollow\"\u003eYouTube playlist\u003c/a\u003e follows the training through the races themselves, with the full recordings providing context for each shorter highlight.\u003c/p\u003e\n","excerpt":"From native driving controls and road guidance to Turbo preservation and weapon combat: the experiments, references and repeated adjustments behind NullG’s learning pilots.","metaTitle":"NullG’s reinforcement-learning journey: driving, Turbo and combat","metaDescription":"Explore NullG’s native racing RL pipeline, external research references, strategy revisions and latest training videos, from analog steering to combat.","status":"published","featured":false,"publishedAt":"2026-10-20T13:21:42Z","authorId":"190160de54f2192bd5b8734ec8808086","authorName":"Daniel Chote","authorSlug":"daniel","heroMediaId":"2de6b37e96d56188d9b74019123198cd","projectId":"ae4bdb66da6dc1729a263a475e1cdbe3","tags":[{"id":"10a974c0a281d4fcf3d44f5ef8dae079","name":"NullG","slug":"nullg"},{"id":"1c9e8a1339a8f8b797767e91a9673016","name":"Game","slug":"game"},{"id":"60103f47eb65b46c6138b9d6fc7b17d0","name":"Machine Learning","slug":"machine-learning"}],"createdAt":"2026-10-20T13:10:40Z","updatedAt":"2026-10-20T15:07:55Z"},{"id":"7b367212a739706ba4e3e9b999bec15d","siteId":"projectable","slug":"introducing-nullg-anti-gravity-racing-and-ai","title":"Introducing NullG: anti-gravity racing and AI-assisted development","markdown":"[NullG](https://projectable.me/projects/nullg/) is an anti-gravity racing engine built in C++20 with Vulkan for rendering. It combines legacy game asset imports with racing physics, weapons, multiplayer, and tools for testing and capturing gameplay.\n\nThe longer-term goal is a motion simulator pod, with acceleration, braking, cornering, and impacts feeding into physical movement. Positional audio and multiple displays are part of that plan too. Earlier projects such as the [Car-cade](https://projectable.me/my-dirt-rally-tabletop-car-cade-game/) and [motion rig](https://projectable.me/sim-racing-motion-rig-v2-updates/) explored racing through custom hardware. NullG takes that work into the game engine.\n\nDevelopment started in January 2026 with AI-assisted planning and implementation. Over the following months, the work expanded into asset loading, rendering, physics, and automated tests. October added more direct access for agents to inspect the engine, run controlled scenarios, and review the results.\n\n![Original NullG ship artwork](/content/images/2026/10/583bdbe059a6-ship.png)\n\n*Original NullG ship artwork.*\n\n## January: plans and the first renderer\n\nThe first git commit, dated January 22, 2026, contains the project outline, research files, architecture notes, and initial application code. The plans already covered asset conversion, input, audio, networking, computer-controlled opponents, and motion output. The application had a window, Vulkan setup, input handling, configuration, and logging.\n\nThe architecture put the race simulation at the center. Graphics and sound would use the state produced by the simulation, with motion hardware eventually reading the same data. This kept the simulator goal part of the engine design from the beginning.\n\nEarly development used Cursor, with project commands for planning, preparation, and review. The preparation step directed the agent to read reference material and trace the relevant code before making changes. Tasks were broken into smaller pieces, with examples and written decisions available for the next session.\n\n![G_jZiq3WQAAg2Cz.jpeg](/content/images/2026/10/037075fac8ed-G_jZiq3WQAAg2Cz.jpeg)\n\nJanuary 23 brought asset conversion tooling and the first renderer pass. Menus, model loading, asset management, and track parsing followed over the next few days. Existing WipEout research and community projects provided references for loading the ships, tracks, textures, and scenery.\n\n## February: loading the original assets\n\nBy February 8, the project had a direct PlayStation asset-loading checkpoint. Work during this period covered track rendering, scene objects, sprites, and texture transparency.\n\nLoading the geometry, textures, and scenery together made it possible to check the imported data in the renderer. File-format notes and agent rules developed alongside the loaders, giving later tasks a record of how the assets were organized and used.\n\n## March: handling, race flow, and weapons\n\nMarch focused more on how ships move around a track: hover height, coasting, weight, jumps, boost, recovery, and tunnel-wall collisions. Scene placement, sky textures, pickups, and boost pads also received attention, along with the camera moving through the track behind the menus.\n\nReal-time lighting, shadows, and GPU particles added to the presentation. By March 6, the code included race-session flow and a weapon system, handling the transition into a race and back to the menus.\n\nThese changes were developed as individual tasks using the relevant code and reference material. Code review and updated implementation notes kept the decisions available as the systems grew.\n\n## May: rendering and automated tests\n\nMay brought a larger pass through the engine internals. The original engine plan was split into focused documents with a shared status index, making individual areas easier to track.\n\nRenderer work included dynamic rendering, geometry access, material organization, and a move to Slang for runtime shaders. Lighting work covered animated scene lights, illuminated pickups, shields, and the shadows received by ships from surrounding scenery.\n\nAn entity/component scene system and render snapshots were added during the same period. A snapshot holds the scene data needed for a frame, including ship and object positions, giving the renderer a consistent set of data to draw.\n\nOn May 28, a headless test suite added checks for the job system, memory, and asset handling. Agents could run these tests after editing the code and inspect the results directly. This became the starting point for the more extensive inspection and gameplay tools added later.\n\n## June: collision, effects, and XL\n\nJune added Jolt collision integration and further GPU effects work. Research notes covered established techniques for effects, shadows, and physics, providing examples for subsequent implementation tasks.\n\nWipEout XL became the default asset source in a June 9 checkpoint. Source descriptors drove the menus, allowing the selected game's data to determine the available choices. Other changes covered waterfall texture scrolling and the starting-grid camera.\n\nBy this stage, the codebase covered rendering, asset loading, handling, race flow, weapons, collision, and tests. The next concentrated stretch of commits begins on October 9, with the existing agent guidance brought into Codex, engine-backed inspection tools, and a fixed 60 Hz racing setup. Multiplayer followed on October 10, then the XL reconstruction checkpoint on October 11.\n\n## October: giving agents access to the engine\n\nOctober also marked a decision to use OpenAI Codex exclusively for NullG's coding-agent work. The existing planning commands, project rules, and reference notes were carried over from Cursor, keeping the earlier work available as context. Development then focused more heavily on giving Codex access to the tools needed to inspect, test, and review changes.\n\nRecently watched YouTube videos about Blender MCP helped shape that approach. They showed how an agent could work directly with a scene and inspect the result. Those concepts were brought into NullG's model-authoring process and reinforced the value of connecting agents to the engine's own inspection tools.\n\nOctober's tooling work gave agents more ways to check their changes. [MCP, the Model Context Protocol](https://modelcontextprotocol.io/introduction), connects AI applications to external tools and data. NullG uses it to expose native inspection windows, track validators, model viewers, and controlled race sessions.\n\nAn agent can load a track, choose a camera, inspect geometry, and capture a frame. Model inspection provides access to materials, bounds, and different viewing angles. Test harnesses provide repeatable scenarios with known inputs.\n\n![NullG Track Validator showing track geometry, texture inspection, and timeline controls](/content/images/2026/10/nullg/intro-track-inspection.png)\n\n*The track inspector, with the track view, texture panel, and playback controls.*\n\nThe weapon harness opens a paused production race scene. An agent can deploy a weapon and advance the scene in controlled steps, inspecting a projectile, impact, or Quake effect at a specific point. Simulation state and rendered output can then be reviewed together.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/pbUzB3j74p8\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n*Reactive engine plumes viewed through the MCP harness.*\n\nPhysics tests compare movement with expected values, track checks inspect road geometry, and screenshots show the rendered result. Replaying the same inputs checks consistency across changes. Together, these tools let agents run a larger part of the validation process themselves, with reports and captures available for human review.\n\n![Ships racing with engine trails and a weapon effect in NullG](/content/images/2026/10/nullg/nullg-ships-weapon-action.png)\n\n### Working through a change\n\nA weapon-effect investigation starts with a specific scene and setup. The agent deploys the weapon, steps through the action, checks the state, and follows the code responsible for the effect. After an edit, it builds the affected code and repeats the scenario.\n\nSaved reports retain the inputs and settings. That allows the case to be repeated in another session or compared across versions. Visual review and gameplay testing provide additional checks on appearance and handling.\n\n![Diagram showing an agent connected through MCP to native inspection and headless validation tools](/content/images/2026/10/nullg/intro-agent-workflow.png)\n\n*The agent can run a test, open an inspector, and save the results for review.*\n\n## Reverse engineering WipEout XL\n\nThe October research also examined WipEout XL / 2097 behavior in more detail, including steering, weapon updates, starting positions, and animated objects.\n\n[REA, Reverse Engineer Anything](https://github.com/morluto/rea), formed part of the research setup. It connects agents with tools for investigating applications and binaries. The PlayStation XL executable decompilation used a PSX-aware Ghidra workflow, with scripts retaining instructions, references, annotations, and findings.\n\nThe starting grid provides a useful example. Following the original track numbering and route links established where ships should start. Those findings became checks against the imported track, with the inspector showing the selected position on the road.\n\n![An overhead track inspection with a highlighted grid marker](/content/images/2026/10/nullg/intro-grid-placement.png)\n\n*Checking a grid position against the track geometry.*\n\nThe research covers both USA and European editions. Each finding retains the edition and executable details so timing values and behavior can be traced to their source.\n\nRecovered calculations and state changes are implemented as small C++ reference models, tested, and then connected to NullG. The records distinguish behavior derived from the original executable, adaptations for NullG, and observations from running the engine.\n\nAgent access to analysis tools makes this kind of detailed investigation more accessible to individual developers. Existing products can be studied one behavior at a time, with findings carried into tests and new implementations. For NullG, that supports continued refinement of racing behavior alongside modern rendering, controls, and multiplayer. Imported content comes from user-supplied game files, while original NullG assets are developed separately.\n\n## A wider wave of software reconstruction\n\nREA's rapid rise in attention during early October put agent-assisted reverse engineering in front of a much larger audience. [Coverage of its growth](https://www.onfirstlaunch.com/blog/reverse-engineer-anything-rea-explained) described a surge in interest around demonstrations of agents inspecting applications and reconstructing their behavior.\n\nAt the same time, “vibe-coded” alternatives to familiar creative and office software were attracting attention. [ArtCraft's projects](https://github.com/storytold) include photo, video, and PDF tools, alongside [WordCraft](https://github.com/storytold/wordcraft), [GridCraft](https://github.com/storytold/gridcraft), and [DeckCraft](https://github.com/storytold/deckcraft), which target Word, Excel, and PowerPoint-style workflows. [October coverage](https://www.techradar.com/computing/office-suites/developer-who-vibe-coded-free-adobe-clones-reveals-apps-to-take-down-microsoft-office-next-and-says-there-is-no-reason-to-save-broken-software) connected these AI-assisted projects with the growing interest in alternatives to Adobe and Microsoft applications.\n\nThese are separate projects exploring related possibilities: using agents to understand software, implement familiar workflows, and build tools around specific needs. NullG applies that approach to racing. Executable research informs individual behaviors, while tests, inspectors, and recorded scenarios provide ways to check the implementation. The same emphasis on repeatable validation carries through asset production and gameplay development.\n\n## Blender and model production\n\nThe Blender MCP concepts from those videos were applied to a specific job: preparing original menu models for the engine. Scene access let the agent inspect parts, make scoped edits, export a candidate, and produce comparison views within the same task.\n\nThe benefit was practical. Model changes could be checked from several angles in Blender and then reviewed at their actual size in NullG's menus. Saved revisions and repeatable exports made the process easier to iterate, while geometry checks and visual review stayed part of the finishing pass.\n\nBlender MCP provides agent access to scene inspection, geometry and material editing, and visual review. The menu-model process starts with visual references and generated models where useful, followed by a Blender finishing pass.\n\nThat pass covers shape, individual parts, surface cleanup, materials, and polygon count. Models are reviewed from several angles, exported, and checked in NullG's model viewer and menus at their intended display size.\n\n![Four Blender review renders of the original monitor-shaped Graphics menu model](/content/images/2026/10/nullg/intro-blender-graphics-model.png)\n\n*Front, side, rear, and angled review renders of the Graphics menu model.*\n\nThe authoring files, exports, and comparison images remain available through each revision. Connecting these tools lets an agent work through research, code, tests, and visual checks within the same development session.\n\n## Race capture and social media\n\nNullG includes race recording, replay playback, cinematic cameras, and video export. Recorded races can be rendered with ship-focused shots, action cuts, titles, and audio. Landscape, portrait, and square formats support both longer videos and shorter social clips.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/tREm0SM8zmg\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n*The XL cinematic race intro.*\n\nScreenshot tools capture menus, starting grids, tracks, and weapons in action. Agents can help select and organize those captures, with settings and source details retained alongside the images. The same recorded race can support a gameplay review and provide footage for a project update.\n\n## Reinforcement learning for the pilots\n\nNullG also includes reinforcement-learning experiments for computer-controlled pilots. A trained model selects ship controls during a race. Development agents help build the training tools, run checks, and prepare the results for review.\n\nThe pilot receives information about speed and direction, the road ahead, nearby ships, and pickups. It selects throttle, steering, air brakes, pitch, and weapon commands, which pass through the racing simulation as player-style inputs.\n\nTraining uses Python, Gymnasium, Stable-Baselines3, and PyTorch, with PPO as the learning algorithm. Native workers run NullG's race simulation, allowing several driving attempts to run in parallel while the training process updates the model.\n\n![](/content/images/2026/10/nullg/intro-rl-city-race.png)\n\n*A frame from an RL evaluation replay on Gare d’Europa, rendered through NullG's replay tools.*\n\n### Training and evaluation\n\nA short run checks the training setup and controls. Longer runs save checkpoints for evaluation on a chosen set of tracks and race configurations. Saved settings and seeds allow those checks to be repeated.\n\nEvaluation measures completion, time, damage, and steering smoothness. Traffic and combat scenarios also examine race position, pickup use, and weapon timing. Training checkpoints and policies approved for gameplay have separate evaluation steps.\n\nReplays provide another view of the results. Chase cameras show ship movement through a corner, while overhead views show racer positions around the circuit. These views can be compared with the recorded controls and race metrics.\n\n![](/content/images/2026/10/nullg/intro-rl-overhead.png)\n\n*An overhead replay view from the RL development work, with colored racer markers.*\n\nThe exported pilot is a compact model evaluated by native C++ code. Python handles training, and the game runs the exported policy. Retained checkpoints allow different training runs to be compared using the same evaluation setup.\n\nAgents can run the checks, read reports, and prepare replay captures. This supports review of individual driving behaviors and produces footage for documenting the experiments.\n\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/fkUTwW2p_8k\" frameborder=\"0\" allowfullscreen\u003e\u003c/iframe\u003e\n\n*An AI-driving training clip from the NullG playlist.*\n\nMore detail is available on the [MCP tooling page](https://projectable.me/projects/nullg/mcp-tooling/) and [reinforcement-learning page](https://projectable.me/projects/nullg/reinforcement-learning/).\n\n## Publishing to projectable.me\n\nThe same agent-assisted workflow extends to publishing on projectable.me. Agents can prepare illustrated posts, update project pages, and organize development updates under the NullG project.\n\nThe process starts with the git history, project documentation, and relevant captures. An agent prepares the article, adds screenshots and video embeds, and saves a draft on projectable.me. The post can then be reviewed and edited on the site before publication.\n\nThis post follows that process, using repository history for the timeline, project documentation for the workflow details, and existing engine captures for the screenshots. Keeping these updates attached to the NullG project makes the development history easy to follow alongside the project pages.\n\n## Current state and next steps\n\nNullG now includes racing, weapons, computer-controlled opponents, local split-screen, LAN and private online rooms, and replay tools. Inspection and validation tools support development across those systems.\n\n![Two-player vertical split-screen racing with WipEout XL content in NullG](/content/images/2026/10/nullg/intro-xl-splitscreen.png)\n\n*Two racers, two views, and independent HUDs in a NullG split-screen session.*\n\nThe longer-term work includes original ships and tracks, sound, and handling for gamepad and simulator use. Motion output, positional audio, and multiple displays remain part of the simulator plan.\n\nThe [NullG project pages](https://projectable.me/projects/nullg/) cover the engine and its tools in more detail. Development footage is available in the [NullG video playlist](https://www.youtube.com/playlist?list=PLaR-_mRLlb6E), with further updates collected in the [project blog](https://projectable.me/projects/nullg/blog/).","html":"\u003cp\u003e\u003ca href=\"https://projectable.me/projects/nullg/\" rel=\"nofollow\"\u003eNullG\u003c/a\u003e is an anti-gravity racing engine built in C++20 with Vulkan for rendering. It combines legacy game asset imports with racing physics, weapons, multiplayer, and tools for testing and capturing gameplay.\u003c/p\u003e\n\u003cp\u003eThe longer-term goal is a motion simulator pod, with acceleration, braking, cornering, and impacts feeding into physical movement. Positional audio and multiple displays are part of that plan too. Earlier projects such as the \u003ca href=\"https://projectable.me/my-dirt-rally-tabletop-car-cade-game/\" rel=\"nofollow\"\u003eCar-cade\u003c/a\u003e and \u003ca href=\"https://projectable.me/sim-racing-motion-rig-v2-updates/\" rel=\"nofollow\"\u003emotion rig\u003c/a\u003e explored racing through custom hardware. NullG takes that work into the game engine.\u003c/p\u003e\n\u003cp\u003eDevelopment started in January 2026 with AI-assisted planning and implementation. Over the following months, the work expanded into asset loading, rendering, physics, and automated tests. October added more direct access for agents to inspect the engine, run controlled scenarios, and review the results.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/583bdbe059a6-ship.png\" alt=\"Original NullG ship artwork\"\u003e\n\u003cp\u003e\u003cem\u003eOriginal NullG ship artwork.\u003c/em\u003e\u003c/p\u003e\n\u003ch2\u003eJanuary: plans and the first renderer\u003c/h2\u003e\n\u003cp\u003eThe first git commit, dated January 22, 2026, contains the project outline, research files, architecture notes, and initial application code. The plans already covered asset conversion, input, audio, networking, computer-controlled opponents, and motion output. The application had a window, Vulkan setup, input handling, configuration, and logging.\u003c/p\u003e\n\u003cp\u003eThe architecture put the race simulation at the center. Graphics and sound would use the state produced by the simulation, with motion hardware eventually reading the same data. This kept the simulator goal part of the engine design from the beginning.\u003c/p\u003e\n\u003cp\u003eEarly development used Cursor, with project commands for planning, preparation, and review. The preparation step directed the agent to read reference material and trace the relevant code before making changes. Tasks were broken into smaller pieces, with examples and written decisions available for the next session.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/037075fac8ed-G_jZiq3WQAAg2Cz.jpeg\" alt=\"G_jZiq3WQAAg2Cz.jpeg\"\u003e\n\u003cp\u003eJanuary 23 brought asset conversion tooling and the first renderer pass. Menus, model loading, asset management, and track parsing followed over the next few days. Existing WipEout research and community projects provided references for loading the ships, tracks, textures, and scenery.\u003c/p\u003e\n\u003ch2\u003eFebruary: loading the original assets\u003c/h2\u003e\n\u003cp\u003eBy February 8, the project had a direct PlayStation asset-loading checkpoint. Work during this period covered track rendering, scene objects, sprites, and texture transparency.\u003c/p\u003e\n\u003cp\u003eLoading the geometry, textures, and scenery together made it possible to check the imported data in the renderer. File-format notes and agent rules developed alongside the loaders, giving later tasks a record of how the assets were organized and used.\u003c/p\u003e\n\u003ch2\u003eMarch: handling, race flow, and weapons\u003c/h2\u003e\n\u003cp\u003eMarch focused more on how ships move around a track: hover height, coasting, weight, jumps, boost, recovery, and tunnel-wall collisions. Scene placement, sky textures, pickups, and boost pads also received attention, along with the camera moving through the track behind the menus.\u003c/p\u003e\n\u003cp\u003eReal-time lighting, shadows, and GPU particles added to the presentation. By March 6, the code included race-session flow and a weapon system, handling the transition into a race and back to the menus.\u003c/p\u003e\n\u003cp\u003eThese changes were developed as individual tasks using the relevant code and reference material. Code review and updated implementation notes kept the decisions available as the systems grew.\u003c/p\u003e\n\u003ch2\u003eMay: rendering and automated tests\u003c/h2\u003e\n\u003cp\u003eMay brought a larger pass through the engine internals. The original engine plan was split into focused documents with a shared status index, making individual areas easier to track.\u003c/p\u003e\n\u003cp\u003eRenderer work included dynamic rendering, geometry access, material organization, and a move to Slang for runtime shaders. Lighting work covered animated scene lights, illuminated pickups, shields, and the shadows received by ships from surrounding scenery.\u003c/p\u003e\n\u003cp\u003eAn entity/component scene system and render snapshots were added during the same period. A snapshot holds the scene data needed for a frame, including ship and object positions, giving the renderer a consistent set of data to draw.\u003c/p\u003e\n\u003cp\u003eOn May 28, a headless test suite added checks for the job system, memory, and asset handling. Agents could run these tests after editing the code and inspect the results directly. This became the starting point for the more extensive inspection and gameplay tools added later.\u003c/p\u003e\n\u003ch2\u003eJune: collision, effects, and XL\u003c/h2\u003e\n\u003cp\u003eJune added Jolt collision integration and further GPU effects work. Research notes covered established techniques for effects, shadows, and physics, providing examples for subsequent implementation tasks.\u003c/p\u003e\n\u003cp\u003eWipEout XL became the default asset source in a June 9 checkpoint. Source descriptors drove the menus, allowing the selected game\u0026#39;s data to determine the available choices. Other changes covered waterfall texture scrolling and the starting-grid camera.\u003c/p\u003e\n\u003cp\u003eBy this stage, the codebase covered rendering, asset loading, handling, race flow, weapons, collision, and tests. The next concentrated stretch of commits begins on October 9, with the existing agent guidance brought into Codex, engine-backed inspection tools, and a fixed 60 Hz racing setup. Multiplayer followed on October 10, then the XL reconstruction checkpoint on October 11.\u003c/p\u003e\n\u003ch2\u003eOctober: giving agents access to the engine\u003c/h2\u003e\n\u003cp\u003eOctober also marked a decision to use OpenAI Codex exclusively for NullG\u0026#39;s coding-agent work. The existing planning commands, project rules, and reference notes were carried over from Cursor, keeping the earlier work available as context. Development then focused more heavily on giving Codex access to the tools needed to inspect, test, and review changes.\u003c/p\u003e\n\u003cp\u003eRecently watched YouTube videos about Blender MCP helped shape that approach. They showed how an agent could work directly with a scene and inspect the result. Those concepts were brought into NullG\u0026#39;s model-authoring process and reinforced the value of connecting agents to the engine\u0026#39;s own inspection tools.\u003c/p\u003e\n\u003cp\u003eOctober\u0026#39;s tooling work gave agents more ways to check their changes. \u003ca href=\"https://modelcontextprotocol.io/introduction\" rel=\"nofollow\"\u003eMCP, the Model Context Protocol\u003c/a\u003e, connects AI applications to external tools and data. NullG uses it to expose native inspection windows, track validators, model viewers, and controlled race sessions.\u003c/p\u003e\n\u003cp\u003eAn agent can load a track, choose a camera, inspect geometry, and capture a frame. Model inspection provides access to materials, bounds, and different viewing angles. Test harnesses provide repeatable scenarios with known inputs.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-track-inspection.png\" alt=\"NullG Track Validator showing track geometry, texture inspection, and timeline controls\"\u003e\n\u003cp\u003e\u003cem\u003eThe track inspector, with the track view, texture panel, and playback controls.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThe weapon harness opens a paused production race scene. An agent can deploy a weapon and advance the scene in controlled steps, inspecting a projectile, impact, or Quake effect at a specific point. Simulation state and rendered output can then be reviewed together.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/pbUzB3j74p8\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003cem\u003eReactive engine plumes viewed through the MCP harness.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003ePhysics tests compare movement with expected values, track checks inspect road geometry, and screenshots show the rendered result. Replaying the same inputs checks consistency across changes. Together, these tools let agents run a larger part of the validation process themselves, with reports and captures available for human review.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/nullg-ships-weapon-action.png\" alt=\"Ships racing with engine trails and a weapon effect in NullG\"\u003e\n\u003ch3\u003eWorking through a change\u003c/h3\u003e\n\u003cp\u003eA weapon-effect investigation starts with a specific scene and setup. The agent deploys the weapon, steps through the action, checks the state, and follows the code responsible for the effect. After an edit, it builds the affected code and repeats the scenario.\u003c/p\u003e\n\u003cp\u003eSaved reports retain the inputs and settings. That allows the case to be repeated in another session or compared across versions. Visual review and gameplay testing provide additional checks on appearance and handling.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-agent-workflow.png\" alt=\"Diagram showing an agent connected through MCP to native inspection and headless validation tools\"\u003e\n\u003cp\u003e\u003cem\u003eThe agent can run a test, open an inspector, and save the results for review.\u003c/em\u003e\u003c/p\u003e\n\u003ch2\u003eReverse engineering WipEout XL\u003c/h2\u003e\n\u003cp\u003eThe October research also examined WipEout XL / 2097 behavior in more detail, including steering, weapon updates, starting positions, and animated objects.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/morluto/rea\" rel=\"nofollow\"\u003eREA, Reverse Engineer Anything\u003c/a\u003e, formed part of the research setup. It connects agents with tools for investigating applications and binaries. The PlayStation XL executable decompilation used a PSX-aware Ghidra workflow, with scripts retaining instructions, references, annotations, and findings.\u003c/p\u003e\n\u003cp\u003eThe starting grid provides a useful example. Following the original track numbering and route links established where ships should start. Those findings became checks against the imported track, with the inspector showing the selected position on the road.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-grid-placement.png\" alt=\"An overhead track inspection with a highlighted grid marker\"\u003e\n\u003cp\u003e\u003cem\u003eChecking a grid position against the track geometry.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThe research covers both USA and European editions. Each finding retains the edition and executable details so timing values and behavior can be traced to their source.\u003c/p\u003e\n\u003cp\u003eRecovered calculations and state changes are implemented as small C++ reference models, tested, and then connected to NullG. The records distinguish behavior derived from the original executable, adaptations for NullG, and observations from running the engine.\u003c/p\u003e\n\u003cp\u003eAgent access to analysis tools makes this kind of detailed investigation more accessible to individual developers. Existing products can be studied one behavior at a time, with findings carried into tests and new implementations. For NullG, that supports continued refinement of racing behavior alongside modern rendering, controls, and multiplayer. Imported content comes from user-supplied game files, while original NullG assets are developed separately.\u003c/p\u003e\n\u003ch2\u003eA wider wave of software reconstruction\u003c/h2\u003e\n\u003cp\u003eREA\u0026#39;s rapid rise in attention during early October put agent-assisted reverse engineering in front of a much larger audience. \u003ca href=\"https://www.onfirstlaunch.com/blog/reverse-engineer-anything-rea-explained\" rel=\"nofollow\"\u003eCoverage of its growth\u003c/a\u003e described a surge in interest around demonstrations of agents inspecting applications and reconstructing their behavior.\u003c/p\u003e\n\u003cp\u003eAt the same time, “vibe-coded” alternatives to familiar creative and office software were attracting attention. \u003ca href=\"https://github.com/storytold\" rel=\"nofollow\"\u003eArtCraft\u0026#39;s projects\u003c/a\u003e include photo, video, and PDF tools, alongside \u003ca href=\"https://github.com/storytold/wordcraft\" rel=\"nofollow\"\u003eWordCraft\u003c/a\u003e, \u003ca href=\"https://github.com/storytold/gridcraft\" rel=\"nofollow\"\u003eGridCraft\u003c/a\u003e, and \u003ca href=\"https://github.com/storytold/deckcraft\" rel=\"nofollow\"\u003eDeckCraft\u003c/a\u003e, which target Word, Excel, and PowerPoint-style workflows. \u003ca href=\"https://www.techradar.com/computing/office-suites/developer-who-vibe-coded-free-adobe-clones-reveals-apps-to-take-down-microsoft-office-next-and-says-there-is-no-reason-to-save-broken-software\" rel=\"nofollow\"\u003eOctober coverage\u003c/a\u003e connected these AI-assisted projects with the growing interest in alternatives to Adobe and Microsoft applications.\u003c/p\u003e\n\u003cp\u003eThese are separate projects exploring related possibilities: using agents to understand software, implement familiar workflows, and build tools around specific needs. NullG applies that approach to racing. Executable research informs individual behaviors, while tests, inspectors, and recorded scenarios provide ways to check the implementation. The same emphasis on repeatable validation carries through asset production and gameplay development.\u003c/p\u003e\n\u003ch2\u003eBlender and model production\u003c/h2\u003e\n\u003cp\u003eThe Blender MCP concepts from those videos were applied to a specific job: preparing original menu models for the engine. Scene access let the agent inspect parts, make scoped edits, export a candidate, and produce comparison views within the same task.\u003c/p\u003e\n\u003cp\u003eThe benefit was practical. Model changes could be checked from several angles in Blender and then reviewed at their actual size in NullG\u0026#39;s menus. Saved revisions and repeatable exports made the process easier to iterate, while geometry checks and visual review stayed part of the finishing pass.\u003c/p\u003e\n\u003cp\u003eBlender MCP provides agent access to scene inspection, geometry and material editing, and visual review. The menu-model process starts with visual references and generated models where useful, followed by a Blender finishing pass.\u003c/p\u003e\n\u003cp\u003eThat pass covers shape, individual parts, surface cleanup, materials, and polygon count. Models are reviewed from several angles, exported, and checked in NullG\u0026#39;s model viewer and menus at their intended display size.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-blender-graphics-model.png\" alt=\"Four Blender review renders of the original monitor-shaped Graphics menu model\"\u003e\n\u003cp\u003e\u003cem\u003eFront, side, rear, and angled review renders of the Graphics menu model.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThe authoring files, exports, and comparison images remain available through each revision. Connecting these tools lets an agent work through research, code, tests, and visual checks within the same development session.\u003c/p\u003e\n\u003ch2\u003eRace capture and social media\u003c/h2\u003e\n\u003cp\u003eNullG includes race recording, replay playback, cinematic cameras, and video export. Recorded races can be rendered with ship-focused shots, action cuts, titles, and audio. Landscape, portrait, and square formats support both longer videos and shorter social clips.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/tREm0SM8zmg\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003cem\u003eThe XL cinematic race intro.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eScreenshot tools capture menus, starting grids, tracks, and weapons in action. Agents can help select and organize those captures, with settings and source details retained alongside the images. The same recorded race can support a gameplay review and provide footage for a project update.\u003c/p\u003e\n\u003ch2\u003eReinforcement learning for the pilots\u003c/h2\u003e\n\u003cp\u003eNullG also includes reinforcement-learning experiments for computer-controlled pilots. A trained model selects ship controls during a race. Development agents help build the training tools, run checks, and prepare the results for review.\u003c/p\u003e\n\u003cp\u003eThe pilot receives information about speed and direction, the road ahead, nearby ships, and pickups. It selects throttle, steering, air brakes, pitch, and weapon commands, which pass through the racing simulation as player-style inputs.\u003c/p\u003e\n\u003cp\u003eTraining uses Python, Gymnasium, Stable-Baselines3, and PyTorch, with PPO as the learning algorithm. Native workers run NullG\u0026#39;s race simulation, allowing several driving attempts to run in parallel while the training process updates the model.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-rl-city-race.png\" alt=\"\"\u003e\n\u003cp\u003e\u003cem\u003eA frame from an RL evaluation replay on Gare d’Europa, rendered through NullG\u0026#39;s replay tools.\u003c/em\u003e\u003c/p\u003e\n\u003ch3\u003eTraining and evaluation\u003c/h3\u003e\n\u003cp\u003eA short run checks the training setup and controls. Longer runs save checkpoints for evaluation on a chosen set of tracks and race configurations. Saved settings and seeds allow those checks to be repeated.\u003c/p\u003e\n\u003cp\u003eEvaluation measures completion, time, damage, and steering smoothness. Traffic and combat scenarios also examine race position, pickup use, and weapon timing. Training checkpoints and policies approved for gameplay have separate evaluation steps.\u003c/p\u003e\n\u003cp\u003eReplays provide another view of the results. Chase cameras show ship movement through a corner, while overhead views show racer positions around the circuit. These views can be compared with the recorded controls and race metrics.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-rl-overhead.png\" alt=\"\"\u003e\n\u003cp\u003e\u003cem\u003eAn overhead replay view from the RL development work, with colored racer markers.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThe exported pilot is a compact model evaluated by native C++ code. Python handles training, and the game runs the exported policy. Retained checkpoints allow different training runs to be compared using the same evaluation setup.\u003c/p\u003e\n\u003cp\u003eAgents can run the checks, read reports, and prepare replay captures. This supports review of individual driving behaviors and produces footage for documenting the experiments.\u003c/p\u003e\n\u003ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/fkUTwW2p_8k\" frameborder=\"0\" allowfullscreen=\"\"\u003e\u003c/iframe\u003e\n\u003cp\u003e\u003cem\u003eAn AI-driving training clip from the NullG playlist.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eMore detail is available on the \u003ca href=\"https://projectable.me/projects/nullg/mcp-tooling/\" rel=\"nofollow\"\u003eMCP tooling page\u003c/a\u003e and \u003ca href=\"https://projectable.me/projects/nullg/reinforcement-learning/\" rel=\"nofollow\"\u003ereinforcement-learning page\u003c/a\u003e.\u003c/p\u003e\n\u003ch2\u003ePublishing to projectable.me\u003c/h2\u003e\n\u003cp\u003eThe same agent-assisted workflow extends to publishing on projectable.me. Agents can prepare illustrated posts, update project pages, and organize development updates under the NullG project.\u003c/p\u003e\n\u003cp\u003eThe process starts with the git history, project documentation, and relevant captures. An agent prepares the article, adds screenshots and video embeds, and saves a draft on projectable.me. The post can then be reviewed and edited on the site before publication.\u003c/p\u003e\n\u003cp\u003eThis post follows that process, using repository history for the timeline, project documentation for the workflow details, and existing engine captures for the screenshots. Keeping these updates attached to the NullG project makes the development history easy to follow alongside the project pages.\u003c/p\u003e\n\u003ch2\u003eCurrent state and next steps\u003c/h2\u003e\n\u003cp\u003eNullG now includes racing, weapons, computer-controlled opponents, local split-screen, LAN and private online rooms, and replay tools. Inspection and validation tools support development across those systems.\u003c/p\u003e\n\u003cimg src=\"/content/images/2026/10/nullg/intro-xl-splitscreen.png\" alt=\"Two-player vertical split-screen racing with WipEout XL content in NullG\"\u003e\n\u003cp\u003e\u003cem\u003eTwo racers, two views, and independent HUDs in a NullG split-screen session.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThe longer-term work includes original ships and tracks, sound, and handling for gamepad and simulator use. Motion output, positional audio, and multiple displays remain part of the simulator plan.\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://projectable.me/projects/nullg/\" rel=\"nofollow\"\u003eNullG project pages\u003c/a\u003e cover the engine and its tools in more detail. Development footage is available in the \u003ca href=\"https://www.youtube.com/playlist?list=PLaR-_mRLlb6E\" rel=\"nofollow\"\u003eNullG video playlist\u003c/a\u003e, with further updates collected in the \u003ca href=\"https://projectable.me/projects/nullg/blog/\" rel=\"nofollow\"\u003eproject blog\u003c/a\u003e.\u003c/p\u003e\n","excerpt":"NullG’s development from January’s engine plans through asset loading, racing systems, XL research, agent validation, and reinforcement learning.","metaTitle":"Introducing NullG: racing and AI-assisted development","metaDescription":"The development of NullG: a C++20 and Vulkan racing engine with WipEout XL research, MCP tools, Blender workflows, reinforcement learning, and replay capture.","status":"published","featured":true,"publishedAt":"2026-10-19T02:27:51Z","authorId":"190160de54f2192bd5b8734ec8808086","authorName":"Daniel Chote","authorSlug":"daniel","heroMediaId":"3cd28585400f94ee7115b744db06b6a1","projectId":"ae4bdb66da6dc1729a263a475e1cdbe3","tags":[{"id":"1c9e8a1339a8f8b797767e91a9673016","name":"Game","slug":"game"},{"id":"ecaaace3f367d1a9865ae0933d53d715","name":"Sim Racing","slug":"sim-racing"}],"createdAt":"2026-10-19T02:05:13Z","updatedAt":"2026-10-19T20:15:35Z"}],"project":{"id":"ae4bdb66da6dc1729a263a475e1cdbe3","siteId":"projectable","name":"NullG","summary":"A C++20/Vulkan anti-gravity racing engine exploring legacy game asset import, simulation-first architecture, local/LAN/online multiplayer, and reinforcement-learning opponents.","mediaId":"","completed":"","url":"","imageUrl":"","linkedPostId":"","sortOrder":0,"slug":"nullg","excerpt":"A C++20/Vulkan anti-gravity racing engine exploring legacy game asset import, simulation-first architecture, local/LAN/online multiplayer, and reinforcement-learning opponents.","metaTitle":"NullG anti-gravity racing engine","metaDescription":"NullG is a simulation-first anti-gravity racing engine built in C++20 and Vulkan, with legacy asset import, multiplayer, and reinforcement-learning research.","status":"published","publishedAt":"2026-10-18T18:31:43Z","updatedAt":"2026-10-18T22:09:56Z","heroMediaId":"3cd28585400f94ee7115b744db06b6a1","githubUrl":"","youtubeUrl":"https://www.youtube.com/playlist?list=PLaR-_mRLlb6E","twitterUrl":"","linkedinUrl":"","websiteUrl":"","mastodonUrl":"","authorId":"190160de54f2192bd5b8734ec8808086","downloadCount":0},"projectNav":[{"kind":"home","label":"Home","url":"/projects/nullg/"},{"kind":"blog","label":"Blog","url":"/projects/nullg/blog/"},{"kind":"custom","label":"Architecture","url":"/projects/nullg/architecture/"},{"kind":"custom","label":"MCP Tooling","url":"/projects/nullg/mcp-tooling/"},{"kind":"custom","label":"Reinforcement Learning","url":"/projects/nullg/reinforcement-learning/"},{"kind":"custom","label":"Multiplayer","url":"/projects/nullg/multiplayer/"}],"site":{"id":"projectable","theme":"projectable","title":"Daniel Chote's Project Blog","description":"Software Development, Game Development, Hardware Hacking, Sim Racing, Multi-rotors and Robots!","timezone":"America/New_York","postsPerPage":10,"logoMediaId":"21557257b3f2ecc4b3fa875b808097a7","coverMediaId":"6d7e99f0997d13aac98da38677ca7064","copyright":"© Daniel Chote","twitterUrl":"https://twitter.com/dchote","linkedinUrl":"https://www.linkedin.com/in/dchote","googleTagId":"G-07GJBQVM38","hosts":[{"host":"new.projectable.me","canonical":false},{"host":"projectable.me","canonical":true},{"host":"www.projectable.me","canonical":false}]},"topics":[{"id":"1c9e8a1339a8f8b797767e91a9673016","name":"Game","slug":"game"},{"id":"60103f47eb65b46c6138b9d6fc7b17d0","name":"Machine Learning","slug":"machine-learning"},{"id":"10a974c0a281d4fcf3d44f5ef8dae079","name":"NullG","slug":"nullg"},{"id":"ecaaace3f367d1a9865ae0933d53d715","name":"Sim Racing","slug":"sim-racing"}],"total":2}

NullG

Blog

A C++20/Vulkan anti-gravity racing engine exploring legacy game asset import, simulation-first architecture, local/LAN/online multiplayer, and

Teaching NullG to race: the reinforcement-learning journey so far
From native driving controls and road guidance to Turbo preservation and weapon combat: the experiments, references and repeated adjustments behind NullG’s
Introducing NullG: anti-gravity racing and AI-assisted development
NullG’s development from January’s engine plans through asset loading, racing systems, XL research, agent validation, and reinforcement learning.