A farm that runs on your robots' brains.
UMCP.it is a living colony game where every duck movement comes from a community-trained Microduck policy – rolled out in MuJoCo, baked, and played back in Unreal Engine. It was built in about five weeks, from the day the robot was announced. This page shows the work, how it got made, and how it could grow with the community when the physical duck's first deliveries arrive (targeted before Christmas).
The trailer
The two-minute trailer, as it was posted on LinkedIn.
It is filmed in the running game: the colony, the dog herding, foxes and wolves at dusk, weather rolling in, and two ducks having an argument. The ducks, dog, predators and weather are simulation; a few shots are staged only to frame the action.
It was well received there – the reactions are public on the post itself. It is also the clearest answer to "what is this?", so it is here for you to watch before the detail below.
What it is
A small farm of robot ducks that runs itself. You nudge it; it lives.
Autonomous colony
Ducks forage, deliver parts, build a nest, lay eggs, and hatch ducklings. A German Shepherd herds them; foxes and wolves come out at dusk; weather and night change behaviour. A friendly neighbour farm trades goods. A fresh farm finishes its first nest before the first sunset in 8 of 8 test runs.
Behaviour comes from policies
Walking styles, pecking, preening, play-dead, bows, kicks, rolls, a flamingo stand – each is a policy from Hugging Face. Personality shows up in the body: each duck's gait style (sneaky, parade, lean, crouch) is a different community policy.
Built to be inspected
The world is driven by pure rule functions with 175 automated tests, an autoplayer, per-change telemetry, and an interaction ledger. A text-only agent can play it. Every clip carries repo, licence and checksum.
The pipeline: policy → MuJoCo → clip → game
Left: the policy rolled out in MuJoCo. Right: the same motion, baked to a clip and played in Unreal. Three examples: a head-high carry, a bow, a ground pick.
The bake is forward kinematics on the Microduck MJCF, heading removal, a parent-local round trip, and loop-seam search. Reconstruction error is about 3×10−6 cm per clip. The ONNX runner reproduces Pollen's golden vectors to 1.2×10−7, so a policy that works on the robot works the same in the game.
61 → 14, manifest schema 2).The game
Footage from several builds (mid-September onward). The latest polished takes are being re-edited. Overlays are debug views; the ducks are not scripted.
A full Season, in time-lapse
Ball Turret goes up, an outpost claims the North sector, the partner farm's contract is filled, the season completes. The ducks do the routine work; the player steers.
Three temperaments, three ways of reacting
Curious ducks reach; gentle ducks catch. Each temperament has its own set of reactions, and every reaction is a baked policy clip.
Hands-on play (19 Sep build)
Select, send, build, and herd. Day and night, rain and shelter are part of the loop; footage here is from an earlier, rougher build.
A text-only agent plays the colony
An external text-only decision model reads structured colony state and issues orders through the same APIs a player uses. It makes the farm a testbed for agents as well as a game.
The training lab
Before the game, there was a month of questions about the robot itself, trained with mjlab on one GPU. Some answers were good; the honest ones are below too.
Six ways it learned – including two ways it cheated
The first "solved" policy reported zero ball losses and zero falls – and was sitting down. A motionless duck already scores 0.80 of the velocity reward at a 0.15 m/s command, and the ball-centred term pays for a motionless head. Fixing the reward's tolerance, not its weight, produced a real walk: 82–103% of the commanded speed, and about 94% of episodes holding the ball for the full 20 s.
A solved policy has zero skill on the real ball
The training ball is 500× tackier than the kick ball the robot actually owns. Holding the ball for 20 s: 89% at the trained friction, 67% at 0.035, 27% at 0.030, and 0% from 0.025 down to the real ball (0.0001). A competence-gated friction curriculum then moved the cliff: 89% at 0.020 and 55% at 0.016, with the 0.050 control unregressed (94%).
Catching a lobbed ball
Nine ducks catch and balance a lobbed ball. In Unreal this only worked once the BAM actuator model drove the joints – 9 of 9 catches, against 0 of 57 through a plain position servo. The motor model was the whole difference.
A command layer for reflexes: escape, brake, saccade
Policies trained to take reflex commands – a startled escape, a nose-down brake when a trip is detected, head saccades. Turning rose from about 4–10% to 77–97% of the commanded rate after a reward rebalance. Squeezing through a slit is shown too, because it did not work.
Stepping over a 25 mm bar
The shipped policy crossed a 25 mm bar only 2 of 56 times (92% falls). Training on a lattice of gentler bars (4–12 mm) improved step-over – 28 of 49 crossings against 20 of 60 for the shipped policy, falls 22% against 36% – but it cost yaw tracking (0.76 down to 0.35), so that run was stopped.
What didn't work
Two results I'd rather you hear from me.
BallToss: no verified release, no catch
In the final audit of all ten exported windows the longest head-contact gap was 3 frames (0.06 s) against 6 required: 0 verified releases, 0 catches. An earlier result was retracted after the environment turned out to reset inside the step – the "throw" was a teleport. Earlier still, the reward economics made trying irrational: a miss cost about 9,000 against about 60 for a completed toss, a break-even miss rate near 1%.
A neural controller for walking (AnimGen) lost to baked clips
I trained Epic's experimental AnimGen on rollouts of the published walk policy to get a continuously steerable walk. It follows speed and turn commands, but it learned the policy's shuffle and its feet visibly slide, even after a speed match and a foot lock. The baked clips look better, so they stay the default. The experiment stays behind a switch.
Credits & licences
Every behaviour in the game is somebody else's trained policy. Each clip records its repo, licence and checksum. Please correct anything I've mis-credited.
| Author | What I used | Licence |
|---|---|---|
| Pollen Robotics | The Microduck robot model (MJCF, meshes); microduck-policies (walking, sit-stand, ground-pick, ball-kick, roller, roulade); microduck-emotions (17 emotions, with sound) | Policies & emotions Apache-2.0. Robot model: CC BY-NC-SA – the reason for this page |
| Pollen Robotics (Reachy Mini) | A Reachy Mini companion character built from the reachy_mini hardware design files – included in my licence question below | CC BY-NC-SA, as I understand it |
| tfrere | Four personality walk & run gaits (sneaky, parade, lean, low-crouch); hen-pecking-seeds, play-dead, roulade; academy base policies | Apache-2.0 |
| RemiFabre | rough-walk (driven with head commands for carry, alert, bow), flamingo-cycle | Apache-2.0 |
| joanfox | happy-hop – the Hop clip (it barely leaves the ground in our sim; see the roadmap) | Apache-2.0 |
| HannesVonEssen | The climb policy's get-up (Fall_GetUp); basketball and running studied | Apache-2.0 |
| q2p | beak-throw, studied for the ball experiments | Apache-2.0 |
| white100big | custom-walking (paddling legs for a snatched duck) | MIT |
| craigm26 | Golden vectors, used to verify the ONNX runner numerically | Apache-2.0 |
| Nupr-Haokun | step-up-head-brake (vendored, measured, not wired) | Apache-2.0 |
Environment art, plugins and sound are licensed marketplace content that is not redistributed. Videos here are muted for that reason. Policies with no declared licence are kept in a folder that is not shipped.
How I got here
The order things happened in, mistakes included.
Where it goes, with the community
The physical duck's first deliveries are targeted before Christmas. The game could be where each new policy gets seen, tried, and remixed before anyone owns the robot.
Skill packs
A folder with policy.onnx, a manifest and a licence becomes a new duck behaviour. Loading and the contract check already exist; the plan is one command, bake_skill <hub repo>, so a new repo becomes a game behaviour without touching the engine.
Make it your own
Duck personalities, scenarios, predators and rules as data. Share a colony. Pick which policies your ducks use. As more policies arrive, the colony's range grows with them.
A mirror of the real robot
The game runs the same 61 → 14 policies as the hardware. Owners could see their own policy live in the world, and sim-to-real gaps could be measured as part of play. This is an idea to explore with you, not something built.
A showcase that sends people to you
Every skill shown credits its author and links to the repo and, I'd hope, to where you sell the robot. A preview that needs no hardware is a funnel, not a substitute.
What I'm asking
- Permission and terms. Can I use the Microduck model in a free, non-commercial public release, with prominent credit and links to Pollen? Please confirm which CC BY-NC-SA version applies.
- If you'd like it to grow commercially, what would work for you: an official licensed edition, a revenue share, a Pollen-hosted showcase, or staying free and non-commercial forever? I will follow your lead.
- Direction. Anything you'd like it to do (or avoid) as the physical duck launches (I will not describe the robot as open-source hardware): skill sharing, a hardware tie-in, naming and trademark guidance.
- Specs. Any updates to the model, manifest or BAM actuator constants I should track before the first deliveries.
Nothing is sold in the meantime and no binaries are public. I'm happy to walk you through the project live.