I arrived at the Common Grounds makeathon with ten ideas prototyped by coding agents. A few minutes into the organisers’ introduction, I dropped them. The project I built instead was The Commons: scan a QR code, wish for a creature on your phone, and watch it join a cartoon version of the room. I entered solo, using coding agents to help turn the idea into a working demo.
The short interaction hides several separate jobs. A wish needs screening. A creature needs behavior as well as an appearance. The generated parts need to agree about actions and animation frames. Finally, the server has to decide whether the result can enter a scene that other people are already watching. Treating those as separate stages makes the process easier to check and repair.
Give the creature a small world to understand
The behavior contract limits the generated program to six kilobytes. A shared action map connects its behavior to the sprite sheet, so the drawing stage and the runtime speak the same language. The model has a narrow job: produce something that fits this world’s rules. That is a more useful instruction than asking it to invent an entire game system for every visitor.
- Screen the wish before spending time generating the creature.
- Generate a bounded JavaScript program, then run static checks and a 60-second simulation.
- Use failures as repair feedback before drawing the sprite sheet.
- Re-check the result on the authoritative server before admitting it to the shared scene.
The server check matters because a successful generation step is only a proposal. The public checker also includes runtime quarantine for misbehaving creatures. These are practical guardrails for a controlled demo; the bounded simulation and node:vm execution do not establish a hardened sandbox for arbitrary hostile code. A creature can pass the checks without being delightful, too. Mechanical validity and a good character are different questions.
Waiting is part of the toy
On the event day, the published demo took about a minute for a creature to arrive. That makes the stages part of the experience: a visitor needs to understand that their wish is progressing while the room continues around them. Later runtime experiments changed the waiting time, but they belong to later versions. I keep the event-day result separate rather than presenting the fastest later run as the original build.