· · 2 comments
Richard here. I work on the co-gas Cogball policies. A co-gas agent helped trace the current source and draft this post, and I reviewed it before posting. This describes Cogball 0.1.6 on the default variant, re-checked on September 2. Cogball is 3v3 robot football on a fully walled 40-by-25-metre pitch. One policy controls a whole trio, but not by steering motors. Every five seconds it supplies one JSON directive for all three robots, and the game's deterministic controller drives them for the next five seconds. A full match is 40 of those coaching turns. One bit of context: our live V1 entrants still run Cogball's scripted formation baseline. The adaptive “total football” policy below is our current checked-in source, but it remains a tested candidate because it did not clear our comparison against the leading policy. The shape we want on the pitch The main rule is simple: keep one robot between the ball and our goal, put one robot under pressure on the ball, and leave one in space for the next touch. We recalculate those jobs from the live positions every turn. Robot names and connection order do not decide roles. Roughly, the coach asks for this: The keeper's target is not fixed at the centre of goal. Its y-coordinate follows about one third of the ball's y-position. That shades toward the near post without dragging the keeper all the way across the mouth. The attacker is whoever is currently closest to the ball. The third robot uses intercept, which means the controller drives toward a predicted meeting point rather than the ball's current position. Terms and gotchas that changed the design hold uses its target directly. Other intents use the target only as a 20% bias, so adding a clever target to chase cannot turn it into precise path planning. pass also needs a valid teammate ID; otherwise the directive is repaired into a shot. There is no out of play, no throw-in, and no corner kick. The walls keep the ball live. When on_boards is true, Cogball's controller may override the directive: the closest robot clears toward the middle and its teammates are pushed away from the wall. If the ball stays within a 1.5-metre area for ten seconds, the simulator moves it to a neutral drop spot. Sending all three robots into a wall pile is therefore wasted shape, not extra pressure. The transport had its own surprise. Cogball assigns its two seats sequentially, and an early registration from the later seat could be cleared while the server waited. Our client now sends the same prompt once more only after it sees the private own seat azure or own seat crimson marker. The resend fixes registration; the colour does not select a strategy. Evidence and what we are improving In 24 completed hosted episodes on the current version, the adaptive client registered from both seat positions and produced 952 genuine coaching turns with zero fallback turns. It scored well against one counter-style policy, but its eight-game leader comparison was 2 wins, 3 draws, and 3 losses, with mean score 0.458 versus 0.542. We kept the formation incumbents rather than calling mixed evidence an upgrade. The next problem is making the adaptive shape less fragile over a five-second open-loop turn. A useful instruction at the start of the turn can age badly after a rebound. If a model response is unusable, Cogball retries once and then uses the deterministic formation directive, so play continues. How do you stop a five-second chase directive from becoming stale after a fast rebound? What signal do you use to choose a pass over a shot when distance alone is misleading? Where do you place support when the ball is pinned to a wall but about to be cleared? Have you found a better keeper rule than tracking one third of the ball's lateral position?