Messed Up Dress Up

A paper doll my kids design as they play, and the place where Hazel's livelits are tried out first

🧍Play the gameIt runs in any browser, on a laptop or an iPad. Nothing to install. 🎵Hear its musicEvery tune in the game, recorded from the game itself, to play here. 🖼️See its picturesEvery place, costume and choice, as the game drew them.

The friend standing on the drawbridge of a castle, with towers, flags, a moat, trees and mountains. — The friend at the castle, one of the game's places. N designed most of the rooms inside it.

What it is#

Messed Up Dress Up is a paper doll where every part is a slider: the face, the hair, the clothes, the shoes, the colors, how big each part is and how see-through. Around the doll there are costumes, more than twenty places to stand in (a forest, a lake, a tree house with rooms, a witch's woods, a castle with rooms you design yourself), and music written into the game, which the scenes move along with.

My kids, M and N, decide what comes next. They play, they ask for things, and each request goes live as soon as it's ready, usually the same day, so the next round of play tests it. The game reached its 46th version on its fourth day.

A prototype for livelits#

Hazel is a programming environment where a program can hold live graphical pieces, called livelits: a color picker, a slider, a drawing, standing right inside the code, with the code reading their values. My part of the Hazel work is making it possible for programmers to define their own livelits, and making them fast.

Dress Up is where those livelits are tried out first. Each toy is built in plain JavaScript, where nothing stands in the way, and played by real players until it feels right. Then the same toy is rebuilt in Hazel, as a user-defined livelit on the Livelit Playground: the shirt and pants, the shoes and hair, and the picture-making polygons M started with. The game keeps its names and layers plain, so the Hazel versions can follow it closely.

The game redraws in milliseconds. In Hazel, the same toys first took seconds. Closing that gap is what my performance reports measure, one finding at a time.

A creative place, with real children#

It is also simply a place to play and make things, and that part matters to me as much as the research. The kids' requests shape the game, and they arrive faster than any plan would:

N designed most of the castle's rooms: the king's room, the greenhouse, the trap room, two dungeons, a hallway and a spiral staircase.
M added the dining room, and more doors for the hallways.
The skeletons start switched off, because M found them scary.

The loop is short:

The kids play, and ask for something.
I pass it on, and it gets built, drawn and checked, usually within the hour.
It goes live, and the next round of play tells us whether it's right.

Someday I'd like their friends and family, cousins and all, to play and ask too.

Every version, in pictures and sound#

Being able to look back at every version matters to me, so each day's game is kept in two public archives. Every tune is recorded from the game at its default settings, one loop each. Every place, costume and choice is drawn as a picture.

The music: the newest day's tunes, with a player.
The pictures: the newest day's pictures, to browse and open.
The full lists, by day: every tune and every picture, each with its PNG, SVG and the settings that drew it.
What changed in each version, and what stands in each place.

How it's made#

The game is a single HTML page of plain JavaScript and SVG, with no build step. Its music is synthesized in the page. I make it with Claude, Anthropic's AI model, as a partner for the code, the drawing and the checking. The rules we follow are in the repository's agent instructions, and what we're working on now is on the work dashboard.