Josh Creek
cb06300685
Stage 5 blocked after nine attempts and ~540M steps, every one on productive_air_touch_fraction. Instrumenting the environment rather than retuning the reward again found three separate causes, none of which was the policy's competence. The gate could not register the behaviour. productive_air_touch_fraction divides by TOTAL touches in the episode, so a strong ground game dilutes it for identical aerial play. Stage 4's entire purpose is improving that ground game (it took forward_motion_fraction 0.24 -> 0.48), so Stage 4's success drove Stage 5's gate toward zero and the two stages were working against each other. It also explains why every non-zero reading in the whole lineage came from degenerate episodes whose single touch happened to be aerial: per-episode 1.0, which is exactly 0.0100 once meaned over SB3's 100-episode buffer, and 0.0100 was every run's observed maximum. Replaced with productive_air_touch_episode_fraction, which asks whether the episode contained a productive aerial at all and cannot be diluted by ground play. The bar was never derived from anything. AIR_TOUCH_HEIGHT was 5.0 and four rounds of aerial mechanisms were built on top of it without anyone measuring where the ball goes. New ball-altitude telemetry over normal match play: the ball averages ~1.6m, the average episode's peak is ~2.4m, and it clears 5m for ~5% of ticks. Lowered to 3.0, this project's existing airborne threshold, with _place_air_intercept's band retuned 8-14m -> 6-10m. Simulated against real physics the pair strictly dominates the old one: 67.8% reach (was 53.2%), 57.3% above-bar touches (was 41.2%), 5.2m of climb instead of 8.2m. The band could not be lowered alone -- at a 5m bar, 8-14m was optimal and 5-8m collapses above-bar touches to 4.3%. This reverses Round 9's explicit "AIR_TOUCH_HEIGHT stays 5.0"; that objection was about comparability, and a metric that read 0.0 for nine attempts has no history to protect. Pre-2026-08-24 air-touch figures are not comparable with later ones. Note AIR_TOUCH_HEIGHT also gates air_touch_bonus_weight's payout, so unlike Round 9 this DOES change the reward function and the usual "don't resume a policy shaped by a different reward balance" rule is engaged rather than exempt. Resuming retry2 anyway is justified on narrower grounds: the changed term has never once fired (productive_air_touch_fraction exactly 0.0 across nine attempts, air_touch_fraction at ~0.0003 noise), so no learned value estimate is attached to it, while the ground handling and scoring retry2 does know are untouched. The flip side is that at a 3m bar a fully-aligned aerial touch now pays 0.7 + 0.5 = 1.2 against a ground touch's 0.7, which is the intended incentive but is a live reward change -- if attempts show touch farming near 3m rather than genuine intercepts, cut air_touch_bonus_weight rather than raising the threshold back. The policy could not climb, and the entropy controller could not see it. Its target is a sum over heads, which read 21% of h_max -- on target -- while thrust_y alone sat at 14% of its own ceiling. The measured consequence was a policy commanding ~0.03 mean vertical thrust when hovering needs 0.408 (120/5 = 24 m/s^2 against 9.8 gravity), leaving it in free fall ~84% of every episode. Added --min-head-entropy-frac so one starved head raises ent_coef regardless of the aggregate, and --ent-coef-max because a probe pinned the old 0.05 ceiling for its entire duration with the head still starved. A 200k-step probe from retry2 with all three in place moved air_touch_fraction from 0/74 rollouts non-zero to 5/98, ent_coef 0.0102 -> 0.0416 and vertical_thrust_mean 0.031 -> 0.089, with goal_rate, upright_fraction and forward_motion_fraction all holding. The gate metric was still 0.0 at that scale, so its 0.02 floor is marked provisional in generation5.py and should be re-derived from attempt 1's tail rather than trusted. Stage 5 expands to 90M timesteps and MAX_RETRIES 4, its goal_rate floor drops 0.75 -> 0.72 (every attempt landed 0.7217-0.7369 and was failed by ~2-4% while winning its paired evaluations 54-25, 63-23 and 47-32), and state resumes from 20260823-1734-gen5-s5-intercepts-retry2 via resume_override. Verified: generation5.py --dry-run resolves the resume to retry2 with the new flags, 123 unit tests pass, probe artifacts removed.
Cosmic Clash
In "Cosmic Clash," the heart-pounding action takes place in variable gravity environments where vehicles hover just above the ground. In this thrilling spiritual successor to Rocket League, players engage in high-speed, gravity-defying matches set in the far reaches of space. Each pitch is situated in a unique environment or planet, offering breathtaking vistas and challenging terrain. But instead of cars, competitors pilot rocket-powered ships, each equipped with its own set of customisable features and special abilities.
Ships hover just above the ground, defying the laws of physics and adding an extra layer of intensity to the gameplay. With no friction to hold them back, players must master the art of control as they glide effortlessly across the pitch, executing precise manoeuvres and lightning-fast aerial tricks. With precise control and lightning-fast reflexes, players boost, drift, slam and even turn upside down on their way to victory, scoring epic goals against their opponents.
Whether you're soaring through asteroid fields, navigating treacherous alien landscapes, or battling in the depths of cosmic storms, "Cosmic Clash" delivers non-stop action and adrenaline-pumping excitement that's out of this world! Get ready to take your skills to the stars and dominate the galaxy in the ultimate celestial showdown!
Reason for being
Since Epic Games bought Psyonix, Rocket League has never been the same, and rather than releasing an Unreal Engine 5 version of the game, or giving any meaningful updates, instead item trading was removed and 'Rocket Racing' was added to Fortnite. With no one else stepping up to the plate, it falls to the Open Source Community to come up with a spiritual successor, to keep the spirit of the game alive.
Legality
The concept of 'vehicle soccer' cannot be copyrighted, but the original expression of ideas such as the specific code, art, music and narrative of a game can be. So long as all code, assets game design and other elements are made from scratch, this project will remain legal. The use of an alternative game engine, Godot, serves to ensure that this is achieved, as does the move to using space ships instead of cars as the vehicles.
Technical Information
This project is composed of two parts:
- Godot game
- C# backend
Contributing
Eventually there will be contributor guidelines, but for now open a PR and make sure it has been formatted according to the auto-formatting rules.
Gameplay
The core gameplay is still football/soccer but with vehicles, however there are key changes to the format used in Rocket League. The vehicles are now space ships, which hover above the surface of the pitch. This will impact core game mechanics, enabling near-immediate changes in direction (thanks to those spacefaring engines!), the ability to play upside down (which will change the way you interact with the ball in as-yet unknown ways), slamming down at full boost speed, and many more that will be discovered along the way.
Bots
There will be default bots available, trained using reinforcement learning, and it will be possible to train your own using a gym for submission to be included in the game itself. It will NOT be possible to connect bots to the game, and with the community itself ensuring rigorous anti-cheat measures are in place we will aim to keep it that way. Cheaters have no place here.
MVP
The first version of this game will be JUST the game, no server-side functionality at all. It will be a local only game where you can play against bots. Split-screen multiplayer could be added in a version 0.2 if demand is high enough. If there is sufficient interest then the server-side functionality can be added to enable online play, with a system in place to ensure that servers can be paid for (perhaps a cheap monthly subscription model?).
Monetisation
The aim for this project is NOT to monetise it. Rocket League saw terrible changes once the Item Shop was added, and even the costs for crates and keys prevented some members of the community from collecting items and fully enjoying the game. Instead, this game will, if it becomes successful enough to warrant online servers, only use funding to keep itself running, and in the event anyone needs to be employed full time to maintain it with a growing playerbase, to pay them a fair wage for their time. Any additional profit in any given year should be held for maintaining servers in the future should demand fall, or for any future needs of the game such as a large effort to upgrade to a new engine, anti-cheating measures, etc.