Prototype

Bone Yard Three kinds of game in one, to learn how games get made.

A browser dig game inside the arcade cabinet: dig for bones, explore the yard, then face the cat. It was my first game, so I used it to try different ways of building the graphics, the art and the game logic. The cabinet and yard draw with WebGPU shaders and fall back to plain canvas drawing on browsers without it, the dog and the cat are pixel sprites held to model sheets, and the game moves through named states from the attract screen to the fight. It’s also where I test AI agents from different companies side by side: the same kind of task, the same written rules and model sheets, the same automated checks, so I can see how each behaves and what it can produce. It’s also how I learn game mechanics and animation. I work on it on Saturdays with whatever is left of my weekly AI usage before it resets Sunday morning; the weekdays go to Jobs.Dog. That’s why it isn’t finished.

Recorded from the game, on a scripted run: into a mound, down to the bottom at double speed, the cat’s arrival, then the fight’s first volleys.

What I set out to learn

I’d never made a game, so I picked a hard version of one. Bone Yard joins three styles that usually live in separate games: a yard to explore, a mine to dig in the spirit of Motherload and Dig Dug, and a bullet-hell fight with the cat. One dog and one set of upgrades run through all three, so the dig builds your fight. I wanted to learn how mechanics and timing make something fun, how to make a game feel like part of this site, and how far AI could take the art when it can only write code.

The hardest part

The art, at first. I tried every route I could find: a game dog traced from the logo’s SVG, a vector cat rendered down to pixels, a 3D voxel yard. Each one fell short. A four-colour trace can’t hold shading, and the vector cat looked like a sticker. What worked was pixel sprites drawn per pose by scripts, fixed by hand and held to a model sheet by a 14-rule checker. Then the three games had to work as one: early builds lost your loot on the way to the fight, had no way back after the cat, and took about twelve minutes of digging to reach the boss at all.

How the art is checked

A drawing made for this page from the game’s own sprite sheets: a dig down to a bone, and three of the model-sheet checks run on the dog’s idle frame, then on a copy redrawn off-model.

The model sheet is the dog’s reference drawing, written as data: the nine colours he may wear, the dark outline round every edge, the line his feet stand on.
Each frame of the dog is a pixel sprite, drawn per pose and per size. A walk, a dig and an idle are separate drawings, and an agent can get any of them wrong.
A script holds every frame to the sheet with fourteen rules, from the colours and the outline to the head, the proportions and the timing.
It runs in every build, so a frame that fails stops the deploy, whichever agent drew it.
The drawing here runs three of those rules in your browser: on the shipped idle frame, which passes, and on a copy with new colours and lifted feet, which fails.

Decisions on Bone Yard

The same rules and checks for every agent
Why it matters I give agents from different companies the same kind of work, the same written rules and model sheets, and the same automated checks, so I can compare how each one behaves and what it produces.
A script holds every sprite to its model sheet
Why it matters A model sheet is the reference drawing of a character. An agent redrawing a sprite can drift from it, so the check fails the build on a colour that isn’t on the sheet, a broken outline or feet off the ground line, whichever agent drew it.
Every number an agent tunes says where it came from
Why it matters Each one is marked as sourced, tested or measured, so I can tell a measured result from a guess.