Teaching JavaScript with a coffee drone

BrewBot started as a joke between friends: what if the barista were a drone, and you had to program it? A few weekends later it was a small game. The code you write runs a floating 3D coffee shop, and new language features unlock as you serve more customers. It's a fond nod to The Farmer Was Replaced, which taught me more about loops than any course did.

The code is the controller

There are no buttons to move the drone. You write a few lines, press run and watch it fly to the grinder, weigh the beans and pour. When something goes wrong, the drone does exactly what you told it to, which is the best and most frustrating teacher there is. A missing condition means a cup of hot water. An endless loop means a very tired drone.

The 3D scene is deliberately small: one cloud, one counter, one drone and a handful of customers. Keeping the world tiny meant every object could react to the code in a way you can read at a glance. A wrong measurement spills beans across the counter, and the drone's lights change colour while it waits for an instruction.

Unlock the language one idea at a time

Each feature shows up at the moment the player already wants it. Nobody reads a definition of a loop; they get tired of copying the same five lines and the game offers a way out.

"I didn't notice I was learning loops until I'd already written one." A playtester, on day two.

Feedback over instructions

Early builds had long tutorial panels, and every playtester skipped them. The current version explains almost nothing up front. Instead, every run is short, every mistake is visible in the 3D scene within a second or two, and the editor highlights the line the drone is running. Fast, visible feedback did the teaching the panels never managed.

BrewBot is still a side project, and it still has rough edges. But it changed how I think about onboarding in client work, too: show the result, shorten the loop, and let people ask for the next idea themselves.