VitSoonYoung
SpriteStack2D
SpriteStack2D is a Godot 4 addon that renders pseudo-3D sprite stacks from a single 2x2 sheet of orthographic pixel-art views.
AI repository intelligence
FR-AI / ANALYSISWhy it is worth attention
It reframes art generation as program synthesis: sprites are built by functions, animation is a puppet system with skeletal motion and procedural paint, and style consistency is enforced by headless audits instead of sampling or manual redrawing.
Who it is for
- Game developers exploring procedural or code-generated art pipelines
- Godot users interested in technical animation and pixel-art workflows
- Technical artists and tools engineers
- Developers experimenting with prompt-driven or programmatic generation
Use cases
- Generating character sprite sheets and animation clips with consistent face, palette, and proportions
- Retheming an entire character or cast by editing one palette file and rerunning the same code
- Enforcing pixel-art style rules through automated headless checks
- Producing deterministic, regenerable demo GIFs and videos from code
Strengths
- Every asset is a script, so edits are reviewable diffs rather than regenerated images
- Consistency is structural: the same functions draw every frame, preventing style drift
- Style rules are checked by headless audits, making quality testable
- All README media is regenerable from the code if deleted
Considerations
- Requires Godot 4.6+, so it is tied to a specific engine version
- The project is an experiment and currently at the animation-prototyping phase, focused on one protagonist
- Adopting the pipeline means embracing a code-centric art workflow and the learning curve of the Ink & Bones system
README quick start
CyNinja
An experiment in prompt-driven graphics: a pixel-art character — a half-robot cyborg ninja — whose every sprite and animation frame is constructed by code, not drawn by hand and not generated by a diffusion model. The prompts produce programs that produce the art.
640×360, integer scaling, nearest-neighbour — a 2D side-scroller viewport.
Why programs instead of diffusion
Image generators are good at one-off pictures and bad at the same character, again. A sprite sheet needs the identical face, palette, and proportions across dozens of frames, two facings, and two lighting themes — exactly where sampling noise, style drift, and anatomy glitches show up. This repo takes the other road:
- Every asset is a script.
art//*.gdfiles extendPixelAssetand draw into anImagepixel by pixel inbuild(). There are no authored image files in the repo at all. - Consistency is structural, not statistical. The character's face is the
same in frame 30 as in frame 1 because it is the same function. Colors can
never drift because every pixel comes from
art/palette.gd— retheming the entire cast means editing that one file and rerunning the same code. - Edits are diffs, not regenerations. "Make the scarf longer" is a one-line change that alters nothing else, reviewable in version control like any other code.
- Quality is testable. Because art is code, style rules (outline law, color-ramp discipline, no single-pixel noise) are enforced by headless audits rather than by eye alone.
The current phase is animation prototyping: the deliverables are the protagonist's motion clips and a recorded showcase.
How the animation works — "Ink & Bones"
Hand-keying pixel sprites frame by frame has the same drift problem as
diffusion, just slower. Instead, a character is a puppet compiled to
sprite frames (docs/ANIMATION.md is the full reference):
The five clips — idle, run, dash, jump, slash — baked from one rig and one paint pass. None of these frames exists as an authored image.
- Skeleton (
art/skeleton.gd) — a bone hierarchy with float angles, two-bone IK for the legs (author where the foot goes, the knee falls out), and verlet chains for cloth (scarf, headband tails). - Paint (
art/paint.gd) — each body part is painted once, procedurally, in its bone's local
Description
Demo code for prompting a generative cybernetic ninja using Claude code.
