I participated in a programming challenge put on by a company called Moment where
You write a program in a custom assembly-like (we call it ant-ssembly) instruction set that controls 200 ants. Each ant can sense nearby cells (food, pheromones, home, other ants) but has no global view. The only coordination mechanism is pheromone trails, which ants can emit and sense them, but that's it. Your program runs identically on every ant.
The goal is to collect the highest percentage of food across a set of maps. Different map layouts (clustered food, scattered, obstacles) reward very different strategies.
The instruction set includes 7 general-purpose 32-bit registers (plus an automatic program counter) and 4 pheromone channels. That may seem generous, but there are also two big constraints: there is no stack, so any variables and data structures you want to use have to be packed into the registers somehow, and each ant only runs for 64 operations (or until the ant performs an action like moving or picking up foo). That latter constraint means that if your ant doesn't make a decision on what to do next in less than 65 operations, it will move at half the speed of its competitors.
Even though it was conceived as some sort of recruitment or interview tool, it is genuinely one of the most fun programming games I have ever played. The combination of constraints and the variety of generated maps make it approachable yet challenging... there's always one more idea you want to try out!
The initial weeklong contest is over, but Moment have left the game up for now in free play mode! https://dev.moment.com/swarm
I wrote my entry by hand, implementing what I hoped was a pretty general strategy: foraging ants sweep across the map looking for food (keeping track of their relative location to the nest); homing ants try to head straight home, following any walls they encounter to the other side. Homing ants put down a pheromone trail to the food source, and returning ants put down a pheromone trail back to the nest.
Unfortunately my implementation didn't work well on maps with long walls, and I ran out of time while inlining/optimizing things and never got my foragers to always move within the 64 operation limit, so they were slow. My best score during testing with seed 42 was 700, and my official score on the test set was 654. My final standing was 43rd place. There were over 27,000 submissions, but I don't know how many actual serious entries. I found out when I finally submitted mine that the server-side scoring against 120 maps runs much faster than the in-browser simulation of 12 maps (at least on my laptop), so I'm guessing many people submitted repeatedly just to do parameter sweeps, etc.
I spent a lot of time on my little assembly program, mostly implementing ideas that didn't work very well. Unfortunately I mostly only committed changes that improved my score to git, so you can't see all the suffering that went into it. (But my best attempt is actually 14c4ecf26 rather than HEAD.)
I just wrote my assembly in a text editor (sometimes using the provided in-browser editor) and ran it in the browser simulator, which seemed to be in the spirit of the competition. But I'm curious how many people took the time to implement their own interpreter (or run the javascript one from the cli) in order to more quickly iterate.
I also didn't try getting help from an LLM. Given the constraints, I doubt they would help much as an open-loop coding assistant, but if you were able to give them a simulator in a loop so they could see results of each run, I bet they could do a decent (better than me) job.
I'm curious what the top finishers who broke 800 did... I imagine even if they didn't use LLMs they probably had a local simulator in a loop to tune constants and learn patterns? Or they just hit on good patterns faster than I did.