It started with their ideas.
A night race through a neon grid. A trial to recover a sunken crown. A beam you bend across a room of targets. A coaster you draw first and ride second. The kinds of ideas kids produce before somebody teaches them to worry about whether a concept sounds sensible.
We built them.
They stopped treating the screen as a place where finished things come from.
The jobs are different.
The kids own the premise, the characters, the rules, and the verdict on whether something is actually fun. I translate those instincts into mechanics, code, and systems. AI tooling keeps the loop short enough that an idea can become playable while the excitement is still alive.
The arcade made it real.
Once there were several games, I put a tiny server on the home network and built an arcade index in front of it. Plain Python, standard library only, no packages, no internet. The kids open one URL on their iPads and their strange little ideas sit next to each other as a body of work.
Drop an HTML file in the games folder and it appears in the gallery on the next refresh. Adding a game never requires editing code, so the kids can do it.
The server is the single source of truth. The iPads hold no copies. When we fix a game, every tablet has the fix on the next refresh, and a bad change is one git checkout away from undone.
What shipping to kids taught me.
My first real bug report was three words: the games are too small. Before touching anything, I measured. The arcade shell was innocent. Two games were capping their own width with a magic number, and on an iPad the actual art filled about a third of the screen. The fix was to bound the art by the box it lands in, and the same games now fill roughly two thirds of it.
The math game went harder. Version one passed every automated check I had: layout clean at six screen sizes, no overflow anywhere. The kids bounced off it in one sitting. The checks were measuring whether the game fit the screen, and the kids were measuring whether it was worth playing. I rebuilt it. Now every new game runs the mechanical gates before it lands, and then it faces the real gate: hand it over and say nothing.
The machine can verify that a game fits. Only a kid can verify that it matters.
The deeper experiment
Teaching them to code is a side effect. The real lesson is creative agency. Code is one material among many, next to generated art, sound, physics, and the little server that makes it all reachable.
The lesson I care about is simpler: you are allowed to make the thing different.
Neonrace
Night racing through the neon grid.
Drag to steer. The first game to fill the whole screen, and the benchmark the others got measured against.
Emberfall
Trial of the Sunken Crown.
An adventure that taught us landscape wants the controls beside the canvas.
Beamwright
Bend the beam to hit every target.
A puzzle where the layout and the canvas share one source of truth for size.
Coaster
Draw a track, then ride it.
A toy. Immediate, wordless, and the one they hand to guests first.
Math Facts
Fill the tray, then know it by heart.
Version two. Version one passed every automated check and lost the kids in one sitting.
Cat-A-Vac
A cat rides the vacuum. The floor is hungry.
Hold a side to steer, thirteen seconds a round. One mechanic, and a sound pass that carries half the comedy.
Next questions
- What happens when the kids can edit the games themselves, straight on the server?
- All six games are single player. The two-player filter chip in the gallery is waiting for its first game.
- Every game shares one origin now, so two games saving under the same key would eat each other's progress. The arcade needs a save convention before it needs more saves.
- How little tooling does a family actually need to start doing this?