Quick Answer: Pixel art effects are small animated visuals such as fire, explosions, magic, and hits. The open-source pixelfx library provides 244 of them, each written as a small piece of code rather than a stack of hand-drawn frames. You can run them in a browser game, export them as sprite sheets for engines like Godot or Unity, or generate new ones with its Claude Code skill.

Most pixel art effects ship as a folder of PNG frames. You pick one, hope the timing works, and redraw it when you want a blue fire instead of an orange one. pixelfx, from the studio Patch, takes a different route. Every effect is a file of code, so color, timing, and direction are settings you change rather than frames you repaint. The README's counter reads 244 effects. The listing description says 232, but the 21 category counts in the catalog add up to 244, so that's the current number.

Why code instead of frames?

Hand-drawn frames are fixed. A sprite sheet of a campfire is one campfire, and recoloring it means repainting every frame. A code-driven effect is closer to a recipe. The method comes from Hugo Duprez's essay on making pixel art effects with Claude, and his open-source effects at Sprite Fusion set the bar that pixelfx builds on.

Here's the practical difference. Pass a palette array of hex colors and the same fire can burn blue or a heal can glow pink, with no changes to the effect's code. Every random number comes from a seed, so frame 40 looks identical every time you render it. That reproducibility matters when you're tuning a hit for a game and need to compare two versions frame by frame.

The trade-off is that you give up hand-tuned pixel control. A code effect produces what its rules produce. If you need one specific frame to look exactly right, a hand-drawn sheet is still the faster tool.

Two kinds of effect, and why the split matters

pixelfx sorts effects into two types, and the difference affects how you use them.

  • Pure effects export draw(p, t, o). The frame at time t depends only on t, so a looping effect tiles with no visible seam.
  • Simulated effects export create(o). They step real particles, debris, and lights at 120 Hz, so sparks bounce and smoke rolls the same way at 30 fps or 144 fps.

Here's where most people get it wrong: they assume every effect is a sprite animation. Simulated effects behave more like a small physics scene. If you export one to a sprite sheet, you're baking one timeline. If you run it live in the game loop, you can change its origin, direction, or light on the fly.

Using pixelfx in a browser game

The browser path needs no dependencies. You create a frame at your game's pixel resolution, create an effect at a position, and call update and draw each tick. The effect has a "back" pass for things behind characters and a "front" pass for things in front, which is how you get a fireball to sit behind the mage but in front of the floor.

const fx = createFx(frostNova, { x: 160, y: 140 });
fx.draw(frame, "back");
drawCharacters();
fx.draw(frame, "front");

Scale the canvas up with image-rendering: pixelated, or the effect will look blurry. That's the most common mistake people make in their first hour.

Exporting sprite sheets for engines

If you're building in Godot, Unity, GameMaker, Defold, LÖVE, or Bevy, you'll want sprite sheets instead. The command node tools/render.mjs ice/frost-nova --sheet writes a transparent PNG grid of every frame plus an Aseprite-style JSON. That JSON includes frame rectangles, durations, and a meta.pixelfx block with fps, loop flag, column count, and pivot.

The README says Phaser's atlas loader and the Aseprite importers for Godot and Unity read the output. Running node tools/sheets.mjs exports the entire library to a sheets/ folder. Check the importer on your engine version before you commit to a pipeline, since atlas formats change between releases.

The acting layer: where effects start to feel like hits

An effect on its own looks like a sticker. What sells a hit is the body: the wind-up that warns the player something is coming, the freeze on contact, the target rocking back, and the recovery. pixelfx covers this for 61 effects and 12 whole moves, using a timing spec written as plain data.

hits: [{ t: 0.06, stop: 0.14, shake: 0.18, amp: 2, push: 2.8, straw: 18 }],

That line freezes the attack for 0.14 seconds on contact and shakes the picture. The timing is readable data, so you can copy it into your own animation code even if you don't use pixelfx's renderer.

Here's the counter-intuitive part. The obvious instinct is to make every motion as smooth as possible. pixelfx does the opposite for the character: poses hold on 12 fps steps, the way hand-drawn sprites do, while particles run at full rate. Smooth limb motion on a pixel sprite often reads as wrong, because it looks like vector animation pasted onto pixels. The stepped hold is a deliberate style choice, and it's easy to miss if you only skim the code.

There's a caveat too. Effects drawn on the body, such as frost or a poison tint, are written against the standing character. If you bring your own character art, those effects will paint the stock grey dummy, so you'll need to regenerate them.

Making your own with the Claude Code skill

The pixelfx skill teaches Claude Code to find, use, export, and create effects. You install it as a plugin with /plugin marketplace add patch-gg/pixelfx followed by /plugin install pixelfx@pixelfx, or by copying skills/pixelfx into ~/.claude/skills/.

Creating an effect follows a loop the README calls draft, render, look, refine:

  1. node tools/new.mjs arcane/my-spell creates a working starting point.
  2. node tools/render.mjs arcane/my-spell writes a contact sheet you can inspect.
  3. node tools/check.mjs arcane/my-spell flags spills, seams, unseeded randomness, and slow frames.

Then you repeat it. Fix the worst thing, render again. The contact sheet shows a sample of frames, but motion bugs hide between samples, so use --gif or --mp4 for motion, and node tools/act.mjs to step through an act at 12 fps. The authoring guide in docs/AUTHORING.md covers the drawing API and the quality bar.

Choosing your approach: a quick comparison

Hand-drawn sprite sheetCode-driven effect (pixelfx)
RecoloringRepaint every frameChange one palette array
Output for enginesPNG frames plus your own timing dataSprite sheet plus JSON with fps, loop, pivot
ReproducibilityExact, since frames are fixedExact, because all randomness is seeded
Motion in the game loopPlays back as recordedRuns live, with origin and direction changed on the fly
Best fitOne hero effect you need pixel-perfectLibraries of variants and rapid iteration

Use the code approach for breadth and variants, and hand-draw the one signature effect that defines your game.

Licensing and what's not covered

The code and effects are MIT-licensed, so you can use them in commercial games. The README is specific about one exception. The Patch Pixel font in gallery/fonts belongs to Patch and is not covered by the MIT license, and parts of the code are adapted from Hugo Duprez's MIT effects and Hollow Crown's MIT source. Read NOTICE.md before you ship, especially if you plan to use the gallery's typography.

Frequently Asked Questions

What is pixelfx?

pixelfx is an open-source library of 244 pixel art effects, each written as a small piece of code. It covers categories such as fire, explosions, magic, weather, and UI. You can run effects in a browser game, export them as sprite sheets, or create new ones with the Claude Code skill.

How do I add pixel art effects to my game?

For a browser game, install with npm i github:patch-gg/pixelfx and create a frame at your game's pixel resolution. Then call createFx with an effect and position, and run update and draw each tick. For engines like Godot or Unity, run node tools/render.mjs <effect> --sheet to export a sprite sheet with JSON metadata.

Can I use pixelfx effects in a commercial game?

Yes. The code and effects are MIT-licensed, which allows commercial use. The exception is the Patch Pixel font in gallery/fonts, which is Patch's own and not covered by that license. Check NOTICE.md before you ship.

Why do some pixelfx characters move in steps instead of smoothly?

Poses hold on 12 fps steps, the way hand-drawn pixel sprites do, while particles run at full rate. Smooth limb motion on pixel art often looks wrong, so the stepped hold is intentional. You can change it, but the default is what the library's style is built around.

Pixel art effects are easier to ship when they're code you can tune rather than frames you have to repaint. Try rendering one effect with a palette you'd never draw by hand, like fire/torch in blue, and note what changes and what doesn't. Pass this to someone who keeps redrawing the same spell for every color variant in their game.