233 touch mechanics in black and white squares
The whole brief, typed into an empty folder called
mobile-game-mechanics-playground at 2:42 at night:
the folder name says it all. a variety of game mechanics for mobile (touch). focus on creativity, no polish. literally black and white squares or cubes will be good enough graphics. mechanics only
Eleven seconds later, a second line: oh and deploy them to my webspace so I can
test on my phone easily
. Claude built a small engine, a canvas, pointer handling for
any number of fingers, a back and a restart button, and sent three agents off to write
mechanics in parallel, eight to ten each. Twelve minutes later the first 27 were live,
and I asked for one tiny thing: can you turn it into a PWA so I can play everything
fullscreen?
One mechanic per square
Each mechanic is one file, usually 50 to 140 lines, with a goal, a way to fail and a score. Flashlight is a black screen where your finger is the only light and the creatures only freeze while lit. Dig is rubbing sand away so a block can fall to the exit. Elevator is a strip you hold at the top or bottom, and you have to stop it level with a floor. Landing paths is the old draw-a-line-for-each-plane game, with squares for planes.
Then the menu. wow! just great. can we add a fav/pin system or something for
visitors to remember their favorites or also know which ones they havent played yet
etc...? so advanced sorting, filtering and tagging. and then make more :) all good
stuff
. The menu now remembers per phone what you starred, hid, played and for how
long, filters by 19 tags from tap to tilt, and has a button
for a random unplayed one. A best score per mechanic came next, also on request.
Until the credits run out
Around four in the morning:
ok keep going... we still have 6% of weekly credits so... let's make the most of it and keep adding mechanics until we run out of them
and ten minutes later: sonnet uses
even less credits so yeah... just keep going until it fails
. From then on it ran as a
pipeline: three batches of eight writing at once, a smoke test that throws random
multi-touch at every mechanic and catches crashes, NaN and hangs, and a deploy after each
batch that only ships the files that passed. The journal counted along: 75 live at 5:15,
123 at 6:36, 179 at 6:50, 235 at 9:38.
Playing them in between produced the requests. sculpt the ground is fun but needs
invariants to prove that each level is solvable... right now most are not I think
.
And: a lot of the games extend beyond the bottom of the / my screen... any good ideas
how to fix that for all possible screen sizes? example "dig" is fun but it seems I cant
win cause the sand goes beyond my screen
. An audit script now checks every mechanic
for anything drawn off the screen; ten were drawing their board or controls past the edge
and were fitted. Sculpt now regenerates a level until it can prove it is solvable.
Air hockey, online
air hockey is fucking great... let's add a 2 player filter and get a simple backend going so people can play together... e.g. by unique room string with rooms expiring after a while and the backend having some cpu cap to not be able to be dos-ed
Followed by my own doubt: yeah the online multiplayer air hockey may not work out as
well due to its super fast paced nature but we can at least try
. The hockey card has a
room code and an invite link. A small PHP relay only introduces the two phones, then the
match runs directly between them over WebRTC. The relay is capped at four requests a
second per address, 300 rooms, ten minutes idle. Three more mechanics are for two people
on one phone.
Make your own
let users make their own games... we can add a claude api backend and let them use opus 5.5 high ... analytics can track their prompts / requests and system prompt will be basically to keep it in the same minimalistic black and white squares / cubes style.... that way we can extend the collection while keeping people engaged and find out what their interests are
Half a minute later: obviously it needs a daily cap, like 4$ claude API spent or
so... if you made a lot of games with sonnet and they work well I guess sonnet is fine as
well
. It is Sonnet 5.5. You describe a mechanic, it writes one file in the same form
as the other 233, and the game runs in a sandboxed frame with no network access. The test
game, a rubber square you stretch and let snap, took 20 seconds and cost three cents.
The caps are $4 and 80 games a day, five an hour per phone. A finished game gets a share
link, a fun-or-meh vote and a "fix it" button when it crashes.
The last request of the morning was a way for my phone to tidy the public collection:
idk some hidden menu perhaps where I say I want to sync or so... like a developer menu
with three fingers or tapping some obscure place 10 times in a row
. Claude built it
with a key and an unlock link, and I sent it back: see thats why I dont like hash links and passwords and
that crap cause theres not enough people using it for any risk and you are making it more
complicated than it has to be
. Seven fast taps on the title now switch dev mode on.
Whatever is crossed out there disappears for everyone. By the last sync, two nights
later, I had crossed out two (Mow and Fill the glass) and starred six: Traffic stop,
Landing paths, Elevator, Pendulum cut, Two thumbs and Trampolines.
- built
- 6 November, 2:42 at night to 10:07 in the morning, with Claude Code and parallel batches of agents; dev-mode curation synced on 8 November
- mechanics
- 235 written, 233 public; about 16,000 lines, one file each; 19 tags, 77 of them drag, 71 puzzle, 68 tap, 4 for two players
- online
- air hockey between two phones, WebRTC peer to peer after a PHP relay introduces them
- make your own
- Claude Sonnet 5.5, about 3 cents a game, capped at $4 a day
- made with
- plain JavaScript on a canvas, built into one 880 KB HTML file that also works opened from disk; installs as a fullscreen app
Still rough
Agents wrote almost all of them from a one-page brief, and the smoke test only proves that a mechanic does not crash under random tapping, not that it is any fun; that is what the stars and crosses are for, and 227 have neither. Some are thin. In a few the score is printed on top of the mechanic's own counter, so "landed 0" and "delivered 0" carry a big 0 over them. Online hockey still carries the doubt from that night: a game this fast, played across the internet. The game maker has made exactly one game so far, the test one, and good visitor games cannot yet move into the main collection: they live only behind their share links.