244 Pixel Effects, and Not a Single Image in the Repo
Pixel fire, explosions, rain and snow, and tiny creatures, all drawn purely in code. Open-sourced under the MIT license, and it can even export sprite sheets you can feed to Godot and Unity. But what the comments are really arguing about is something else: whether these effects actually read clearly.
244 pixel effects. Fire, explosions, magic, rain and snow, UI, pickups, tiny creatures. All drawn in code, and there isn't a single image in the repo.
The repo is at patch-gg/pixelfx, under the MIT license. You can drag it straight into a browser game, or export sprite sheets for any engine. When the author, Rehan Sheikh, first released it, he wrote 232; two days later, when RoundtableSpace reposted it, the number had become 244.
Drawn purely in code: the benefit isn't saving effort
The usual way to do pixel effects is to draw spritesheets, frame by frame. The problem is tough: change a color and you have to redraw it, want it mirrored and you have to store another copy, want 20 variants and your art assets multiply by 20 first.
Code-driven effects flip this around. Colors are variables, size is a parameter, and mirroring is one line of code. One commenter put it bluntly: for browser games, keeping each effect under a few dozen KB is a hard requirement. Another developer, who had just cut 40% off the weight of their creature game's homepage, said after seeing it, 'I'm very tempted.'
The most interesting part is export. The repo has a render.mjs; with the --sheet parameter it writes out a transparent PNG grid, plus Aseprite-style JSON containing fps, looping, and pivot. The Aseprite importers for Godot and Unity can both handle it. So the phrase 'not a single image' is only half true: there are none at runtime, but there still are when you export.
The key isn't generation; it's 'taking a look'
The project comes with a Claude Code skill, and the workflow has four steps: draft, render, look, refine. Draft, render, look, refine.
What really gates quality is the third step.
One commenter noted: checking frame by frame after rendering is the step most agent loops skip. Code running doesn't mean that blob of fire looks like fire. Another put it more concretely: Claude has to actually see the frame it drew; otherwise it's just guessing where the pixels landed.
This project was ground out through exactly this loop. But the loop itself has a hole. Someone asked a sharp question: how are the review frames chosen? If a flicker is hidden between two frames and sampling happens to miss both of those frames, then that flicker slips through.
The comment section didn't just cheer along
Someone tried it on humanoid characters and concluded, 'Effects and objects are okay; humanoids are terrible.' Another VFX developer gave a longer assessment:
It doesn't read well. It looks complex and cool, but it still has all the common issues, such as a lack of anticipation and cooldown phases.
Which means: it looks complex and cool, but it doesn't read. It lacks anticipation and cooldown phases. He added that if you generate 100 of them, you'll know what the 101st looks like.
That's the most valuable sentence in the whole discussion. Volume can't pile up into rhythm. The readability of an effect depends on anticipation and cooldown—the pause at the instant of the wind-up and the lingering afterglow after it ends—and has nothing to do with how many you generate.
Another article in the same vein
Hugo Duprez wrote a tutorial on the Sprite Fusion blog, and Rehan thanked him specifically in the comments. A few judgments in that article are more worth reading than the repo itself.
The first: treat code as clay. When you have an idea, describe it roughly, have the agent produce 5 to 10 drafts first, render them into short videos and put them in the /records directory, and let a human choose the direction. The second: trust your eyes; you set the quality bar yourself. You can settle for a version or make one you're satisfied with—both are doable.
![]()
![]()
For this, he specifically went into Path of Exile 2 to break down how lightning strikes are built, and into ARC Raiders to watch explosions and debris. In his words, spending an hour not doing the work and just feeding your own judgment is a worthwhile investment.
Below are a few ready-made effects; all are code, and all can be modified:
![]()
![]()
![]()
![]()
A question no one answered
In the comments, Cozy asked: I'm really curious what would happen if 50 of these ran on the same screen.
No one replied. Pure-code effects save on asset size and recoloring costs, but the CPU side still has to do the calculations it has to do. The repo says MIT, and at the time of reposting it had 2,152 stars; fork it and get a flame running, and it won't take more than a few minutes.
As for which of the 244 to copy first, someone has already jumped in with an answer in the comments: fire or the tiny creatures.
发布时间: 2026-11-02 12:55