244个像素特效，仓库里找不到一张图片

244 个像素特效。火焰、爆炸、魔法、雨雪、UI、拾取物、小生物。全是代码画的，仓库里一张图片都没有。

仓库在 patch-gg/pixelfx，MIT 协议，可以直接拖进浏览器游戏，也可以导出 sprite sheet 给任意引擎。作者 Rehan Sheikh 最初放出来时写的是 232 个，两天后 RoundtableSpace 转发时，数字变成了 244。

纯代码画的，好处不在省事

像素特效常规做法是画 spritesheet，一帧一帧抠。问题是硬：改个颜色得重画，想镜像得再存一份，想做 20 种变体，美术资源先翻二十倍。

代码驱动的特效把这件事调过来了。颜色是变量，尺寸是参数，镜像翻转一行代码。有网友在评论区说得很直白：对浏览器游戏来说，每个特效都留在几十 KB 以内，这是刚需。另一位刚把自家生物游戏首页减重 40% 的开发者，看完直接说“很心动”。

最有意思的是导出。仓库里有个 render.mjs，带 --sheet 参数时会写出一张透明 PNG 网格，外加 Aseprite 风格的 JSON，包含 fps、循环、pivot。Godot 和 Unity 的 Aseprite 导入器都吃得下。所以“没有图片”这句只说对了一半：跑的时候没有，导出的时候还是会有。

关键不在生成，在“看一眼”

这个项目配了一个 Claude Code skill，工作流是四步：draft、render、look、refine。起草、渲染、看、修。

真正卡住质量的，是第三步。

有网友评论：渲染完再逐帧检查，是大部分 agent 循环跳过的环节。代码能跑，不代表那团火看起来像火。另一位说得更具体：Claude 必须真的看到它画出来的那一帧，否则它只是在猜像素落在哪。

这项目就是靠这个循环磨出来的。不过循环本身也有漏洞。有人问了一个很尖的问题：审查帧怎么选？如果两帧之间藏了一次闪烁，而在采样时正好没采到这两帧，那这次闪烁就会被放过。

评论区没跟着一起吹

有人拿它试了人形角色，结论是“效果类和物件还行，人形很糟”。另一位做特效的开发者评价更长：

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.

翻译过来：看着复杂、看着酷，但读不懂。缺预备动作，缺收尾阶段。他还补了一句，如果生成 100 个就知道第 101 个长什么样了。

这是整个讨论里最值钱的一句。数量堆不出节奏。特效的可读性靠 anticipation 和 cooldown，也就是起手那一瞬的停顿和结束后的余韵，跟生成多少个没有关系。

同源的另一篇文章

Hugo Duprez 在 Sprite Fusion 博客里写过一篇教程，Rehan 在评论区专门谢过他。那篇文章里有几句判断比仓库本身更值得看。

第一句：把代码当黏土。有想法就描述个大概，让 agent 先出 5 到 10 个草稿，渲染成短视频放进 /records 目录，人来挑方向。第二句：相信你的眼睛，质量线是你自己定的，凑合出一版和做到满意，都做得出来。

他为此专门去《流放之路 2》里拆闪电怎么打，去 ARC Raiders 里看爆炸和碎屑。用他的话说，一小时不干活、只喂自己的判断力，是划算的投入。

下面是几个现成的效果，都是代码，都能改：

一个没人回答的问题

评论区里 Cozy 问了一句：很好奇同屏跑 50 个会怎么样。

没人回。纯代码特效省的是资产体积和改色成本，CPU 那头该算的还是得算。仓库写着 MIT，Star 数在转发时是 2,152，Fork 一下跑个火焰出来，花不了几分钟。

至于 244 个里先抄哪个，有人已经在评论区抢答了：火焰还是小生物。