PROCESS5 MIN READ
Fun and games with Opus 5.5
How I built Back Street Boxing, a multiplayer browser boxing game, with Claude Opus 5.5: game feel, mobile UI, and skills for game-ready 3D models.
I build games for fun. I'm a product designer, but I've made hobby games in Unity and about five games for the web. In autumn 2026, in my own time, I spent a few weeks building the latest one with Claude Opus 5.5.
It's called Back Street Boxing. Two fighters box in a neon alley, and every so often a car comes through and you both have to jump it. There are eight fighters, you can play a friend from an invite link, and it runs at 60 frames a second on a phone.
Play a round at bsboxing.dev, then come back.
Claude wrote the code. The design decisions stayed with me.
Game feel came before everything else
Early builds worked, but the punches didn't have any weight. One of my notes just says "janky, not how boxers move".
Rather than describe the problem, I gave Claude a 50-second clip of a boxing game that felt right, and asked it to measure every frame.
It counted 88 landed hits and timed every phase of a punch. The glove stays on the target for four to eight frames. Both fighters freeze for a few frames on a heavy hit. And the head snaps on the frame of contact, not after it.
Those numbers became the spec. A jab now lands nine or ten frames after you press the button.
The measuring also caught a mistake I'd have shipped. The first knockback values pushed the other fighter out of reach, and only 5 of 9 punches in a scripted combo landed. Once knockback scaled with damage, 7 of 9 did.
A phone has no room for instructions
You play on a phone held sideways, with two thumbs, and the fighters need the middle of the screen. So the fight screen got one rule: icons only. Gloves punch, a star fires the super, and a double chevron jumps the car.
That rule lives in a style guide in the repo, and the project's CLAUDE.md tells every agent to read it before it touches the UI. It's the same habit I use on product work.
The first lean pad, which moves your fighter in and out, followed your thumb around, and the knob flew off the screen. Now it's a fixed rail with a knob that can't leave it, and the glove buttons grew from 76 pixels to as much as 128.
The first menu put 13 tappable things on one phone screen. The new one asks one question per screen: who you are, who you're fighting, then the match.
I had Claude build two directions for it.
The alley is a painting
My brief for the arena was a mood. This is most of it:
Handcrafted painterly 3D environment, stylized realism, soft beveled edges. Cinematic low-key lighting: deep teal and cyan ambient shadows, vibrant magenta and pink neon accents, warm amber light spilling from a small storefront, soft volumetric haze, gentle bloom, wet pavement with subtle neon reflections.
Haze, bloom and reflections are all expensive, and a phone can't pay for them 60 times a second, so the arena got a second rule: performance first, then fake it as closely as possible.
Almost nothing in that alley is real. The building fronts are painted in code onto one canvas. The neon glow is baked into the sign textures, and the wet road is a small shader trick. The whole street costs about 11 draw calls and adds nothing to the download.
Three Claude skills for the boring parts
Every fighter starts as an AI-generated 3D model, and a raw one is no use to a game: it's over 20 MB, it has no skeleton, and its hands can be fused to its hips.
The fixes went into skills, which are folders of instructions and scripts that Claude can load again. I've written about why I write my own, and this project left me with three more.
game-ready-character drives Blender from the command line. It cleans the mesh, cuts triangles but spares the face and hands, fits the same 23-bone skeleton to every fighter, and exports a web-ready file. One fighter, Jeff, went from 26 MB to 1.5 MB. Then it renders the fighter in boxing poses, so I can spot a torn armpit before the model reaches the game.
One fighter came out looking like wet plastic, so the skill now measures skin roughness on every new model.
cloth-secondary-motion makes shirts and hair move without a cloth simulation, which is too expensive on a phone. It marks the loose parts of each model and drives them with seven small springs per fighter. I couldn't measure any change in frame time.
game-promo-clip turns an approved storyboard into a trailer. I wrote it while making the launch trailer.
A 20-second trailer for $2.81
The trailer is one joke. Two fighters sit at a neon bar, a woman winks, they both point at themselves, and the bartender slams two pairs of gloves on the counter. Then it cuts to the alley.
Nothing paid ran until I'd approved the storyboard. Claude generated three stills from the game's own fighter portraits, and each still became the first frame of a four-second shot, so a fixed panel meant a fixed shot. (Two panels were re-rolled to move the woman from the counter to a booth.)
The fight is real gameplay, recorded by a script that plays a match. The end card is the game's own title, built from the same CSS and font and rendered frame by frame. All of it came to $2.81 against a $4 cap.
Made a multiplayer boxing game where you fight in an alley and avoid getting hit by a truck. it’s free, it’s in the browser, mobile friendly (landscape) and matches are a minute long.
Launch week
I launched the game on X on November 11 with that trailer, and posted this gameplay clip the next day:
Multiplayer fighting game built with @threejs, punch your opponent and avoid getting hit by a truck. Optimized for mobile, currently doing 60fps.
In its first week at bsboxing.dev, the game had 148 active users and 167 views, with a spike on November 11.
Those are small numbers, and I'm happy with them.
Go play a round, and jump the car.