Two games, built to learn

I build enterprise AI systems for a living, and the quiet failure mode of doing that for long enough is that you start grading your own homework. You set the rubric, you write the methodology, you decide what “good” means, and then you evaluate your work against the definition you authored. It’s comfortable and it’s slow poison, because the feedback loop runs entirely through your own judgment.

So this month I built two games, on purpose, to work somewhere I am not an expert and cannot define the rubric. Games are a brutal forcing function for exactly that reason. A game either plays or it doesn’t. The art either looks right or it looks wrong, and you do not get to write a footnote explaining why the wrong thing is actually correct under your framework. My standard for “good” is irrelevant. The thing has to survive contact with a person holding a keyboard who has no idea what I think.

Both are proof of concepts. Both are playable in the browser, embedded right on this site. And both taught me something I’m taking back to the day job.

Sumi: Ink and Steel

The first is a 2D samurai brawler in a late-Edo bloody-woodblock style. The visual target was Yoshitoshi and Kuniyoshi, the violent end of ukiyo-e: saturated flat indigo and vermillion, gouged irregular black linework, paper grain, grim theatrical silhouettes. The hero, Masayoshi, is deep indigo over a vermillion underlayer, topknot and ponytail, tall and severe. The enemies are tattooed yakuza brawlers. It runs as a vanilla HTML5 Canvas game, no framework and no build step, with data-driven enemies and chapters.

The engine was the easy part. The hard part, the part I actually wanted to learn, was the art pipeline. I built a fully local generative-art setup: ComfyUI driving Flux Schnell on a laptop RTX 4070 with about 8 GB of VRAM. Every character sprite in the game was generated on that machine, with no per-image API cost and nothing leaving the laptop.

The lessons came fast and they were not the ones I expected.

The first was that style has to be present at generation time, not painted on afterward. I started by exploring a 3D path, generating rough models and trying to overpaint them into the woodblock look. It never worked. Raw 3D produces the wrong surface, and no amount of post-processing rescues it, because the thing that makes a Yoshitoshi print read as a Yoshitoshi print is baked into how the image is made, not layered on at the end. The moment I switched to generating in the target style from the first pixel, it started looking right. That generalizes well beyond games. If you are using a generative model to hit a specific aesthetic or a specific structure, trying to bolt the constraint on after generation is almost always more expensive and worse than building it into the generation itself.

The second lesson is the one I keep thinking about. A beautiful still image is not a usable game sprite. I generated a yakuza source that looked genuinely great, packed it into an atlas, wired it in, and it was wrong, because every “animation” frame was just a transformed version of the same gorgeous static pose. It looked good and it did not animate. Those are two completely separate quality gates, and only the first one is obvious. The character slid across the floor with its legs frozen. Looks-good passed. Actually-moves failed. I had to go back and generate distinct frames for walk, attack, hit, and death, because the still image, however good, was answering the wrong question. “Is this impressive” and “does this do the job” are different tests, and the gap between them is where most AI-generated work quietly falls down.

The third lesson was just discipline. Raw generated frames constantly cropped heads, feet, and weapons, so nothing could be packed blind. Everything went through a review sheet and metadata validation before it touched the game. And the standard for “done” was never “the file exists,” it was “I opened it in a browser and watched the enemy walk, attack, take a hit, and die without errors.” File existence is not completion. Seeing it work is completion.

It’s a prototype, and I’ll say that plainly. The combat is a foundation, not a finished game. But as a proof of concept for fully local, zero-API-cost generative game art in a hard-to-fake style, it did exactly what I wanted.

3D Harrier

The second game is a head-tracked rail shooter, a homage to the 1985 Sega arcade game Space Harrier. Original geometry, original audio, no assets from the source, built on Three.js with no build step. It has eighteen campaign stages with distinct palettes and enemy rosters, boss fights, bonus rounds, a level editor with browser-local saves, and keyboard, gamepad, and mobile dual-stick controls.

The interesting part is the display layer. The webcam tracks your head using MediaPipe’s face landmarker, and the scene is re-projected with off-axis projection based on where your head actually is. The effect is that the monitor stops being a flat screen and becomes a window into the world behind it. Close one eye and lean, and the depth illusion locks in hard. There’s also an auto-orbit cinematic mode for when you don’t want to sit in front of a camera.

The lesson here was different. The novel rendering trick, the head tracking and the off-axis math, was a weekend of reading and a focused build. What actually took the work was everything around it that makes a game playable rather than a tech demo. Enemy projectiles needed distinct silhouettes, contrast rings, halos, and trails so they stay readable across eighteen different stage palettes. Obstacles needed animated collision telegraphs so a high-speed stage stays fair. Bosses needed warning cards and weak-point hit metadata. None of that is the clever part, and all of it is the difference between a thing you show off once and a thing someone actually plays.

I also built a real QA harness for it, which felt absurd for a personal game until it didn’t. There’s a smoke-test runner that exercises the campaign, the bosses, the bonus stages, persistence, the editor, input, and performance, plus an audio manifest that gets checked so a missing sound effect is caught before I ever open a browser. It runs headless through the browser’s dev-tools protocol and writes a report. The first time it caught a regression I’d have otherwise shipped, the absurdity went away. The harness is the same idea I keep coming back to in my actual work: the thing that tells you whether you broke something is worth building even when, especially when, the project is small enough that you think you can hold it all in your head.

Both of them ship with a level editor, and that’s not an accident

Here’s the part that matters most to me, and it’s the reason both games have a level editor built in. The samurai game has a room-based builder where you lay out connected rooms, paint backgrounds, draw the walkable floor, and drop in enemies, doors, and objects. The Harrier game has a stage editor with browser-local saves. Neither was strictly necessary to call the game “done.” I built both anyway.

I built them because the thing that pulled me into computers in the first place was being able to crack a game open and build my own levels. Doom shipped with its guts exposed. The WAD format was readable, the community built editors, and a generation of kids who had never written a line of code discovered they could make their own maps, then their own monsters, then their own rules. That was the on-ramp. You started as a player, became a level designer without noticing, and one day you were writing code because the editor couldn’t do the thing you wanted. I am one of those kids. The reason I do this for a living traces back, pretty directly, to a game that let me change it.

So when I build a small game now, the editor isn’t a nice-to-have. It’s the whole spirit of the thing. A game you can only play is a closed loop. A game you can open and rebuild is an invitation. The editors in both of these are rough, but they let you make something and keep it. Right now that means saving to your own browser and exporting the level as a file you can hold onto.

The next step is the one I actually care about, and it’s why these prototypes aren’t quite throwaways. I want to add real accounts and logins, so people can not only build levels but publish them and play each other’s. The moment a stranger can load a level I made, and I can load theirs, the thing stops being a toy and starts being a tiny community. That’s the part of Doom that actually mattered. Not that you could play it, but that what you made could travel.

I’ve also put both of them in a single public repo. There’s nothing in them worth gatekeeping, and the whole point of the Doom lesson is that the open version is the one that grows. If you want to read how the head-tracking projection works, or how the woodblock art pipeline is wired, or fork a level editor and make it better, it’s all at github.com/jjcitron/acidlemon-games.

Why bother

These are throwaways in the sense that I’m not going to commercialize a samurai brawler or a Space Harrier homage. They are not throwaways in the sense that mattered. The whole point was to spend real effort in domains where I have no authority, where my taste is just one opinion and the medium pushes back hard, and where I had to direct agents to build something I could not have hand-built myself at that speed.

That last part is the honest center of it. I didn’t write most of this code or paint these frames by hand. I set the direction, the quality bar, and the constraints, and I made the calls about what was good enough and what had to be regenerated. The agents supplied the volume. I supplied the taste and the refusal to accept “looks fine” when it slid across the floor with frozen legs. Working that way on something outside my expertise was the actual experiment, more than either game was.

Two things came back to the day job intact. The bottleneck in an AI build is almost never the model, it’s the pipeline and the gates around it, and the gate everyone underweights is the gap between “this looks good” and “this actually works.” And generative art is genuinely viable fully local now, on hardware that fits in a backpack, with no cloud bill, if you’re willing to build the pipeline and do the review.

Both are embedded on this site. Go break them. They’re prototypes, and I’m telling you that up front, because the point was never the polish. It was being a beginner again, on purpose, where nobody grades my homework but the game.

I built two games this month as proof of concepts. A woodblock samurai brawler with every sprite generated locally on a laptop GPU, and a head-tracked rail shooter that turns your monitor into a window.

The point wasn't the games. It was working somewhere I'm not an expert, where the agent can't fake it and a game either plays or it doesn't.

Both playable: https://acidlemon.com/posts/2026-06-13-two-games-built-to-learn/

I spent part of this month building two browser games as proof of concepts. Not for work, not to ship a product. To be a beginner on purpose.

The first is a 2D samurai brawler in a late-Edo bloody-woodblock style, where every character sprite was generated locally through a ComfyUI and Flux pipeline running on a laptop GPU, no per-image API cost. The second is a head-tracked rail shooter, a homage to the 1985 arcade game Space Harrier, where the webcam tracks your head and re-projects the scene so your monitor becomes a literal window into the world.

I direct enterprise AI systems for a living, and the failure mode of doing that long enough is that you start grading your own work in domains where you set the rubric. Games don't let you do that. A game either plays or it doesn't. The art either looks right or it looks wrong, and a six-year-old can tell you which. There's no methodology footnote to hide behind.

Two things I'm taking back to the day job. First, the bottleneck in the AI build is almost never the model. On the samurai game it was the art pipeline, and the real lesson was that a beautiful still image is not a usable game sprite, because looks-good and actually-animates are two separate gates and only one of them is obvious. Second, generative art is genuinely viable fully local now. A consumer laptop GPU produced the entire character set for one of these games with no cloud bill at all.

Both ship with a level editor, and that's the part I actually care about. The thing that pulled me into computers was being able to crack open a game like Doom and build my own levels. So the next step is accounts and logins, so people can build levels and share them, not just play. I put both in a single public repo too. There's nothing worth gatekeeping.

Both are playable in the browser. Links in the post. They're prototypes, and I'm saying that on purpose.