Generate 2D Sprite

Name: Generate 2D Sprite
Author: 0x0funky

Generate and postprocess 2D game assets and animation sheets: pixel-art sprites, characters, NPCs, spells, projectiles, props and…

You say

Buy it · $35 Read it before you buy $35 Written by 0x0funky · unverified publisher

Context cost: 33.2k tokensestimated from the bundle, loaded when it triggers
Bundle: 7 files · 132.7 kB3 scripts among them — read before you run
Licence: MITpaid listing
Last change: —no release on file
Servers it uses: Noneruns standalone

What it does

Generate and postprocess general 2D game assets and animation sheets: pixel-art sprites, clean HD map props, creatures, characters, NPCs, spells, projectiles, impacts, props, summons, and transparent GIF exports. Use when Codex should infer the asset plan from a natural-language request, match a reference or map art style, call built-in `image_gen` for solid-magenta raw sheets, and use the local processor only for chroma-key cleanup, frame extraction, alignment, QC, and transparent exports.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Workflow

Runs a procedure end to end.

spritespixel-artgame-assetsanimation

Filed under

Gaming & Entertainment

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md29.1 kB · 377 lines

--- name: generate2dsprite description: "Generate and postprocess general 2D game assets and animation sheets: pixel-art sprites, clean HD map props, creatures, characters, NPCs, spells, projectiles, impacts, props, summons, and transparent GIF exports. Use when Codex should infer the asset plan from a natural-language request, match a reference or map art style, call built-in `image_gen` for solid-magenta raw sheets, and use the local processor only for chroma-key cleanup, frame extraction, alignment, QC, and transparent exports." ---

6# Generate2dsprite

8Use this skill for self-contained 2D sprite or animation assets.

10When a larger game or playable prototype needs sprites, use this skill for the visible sprite assets and keep runtime/game assembly separate. Do not replace requested sprite assets with code-drawn placeholders.

12## Parameters

14Infer these from the user request:

18- view: topdown | side | 3/4

19- sheet: auto | 2x2 | 2x3 | 2x4 | 3x3 | 3x4 | 4x4 | 5x5 | custom_grid | strip_1x3 | strip_1x4

20- frames: auto or explicit count

22- effect_policy: all | largest

23- anchor: center | bottom | feet

24- scale_strategy: fit | preserve

25- scale_profile: none | create_from_accepted_action | reuse_existing

26- margin: tight | normal | safe

28- reference: none | attached_image | generated_image | local_file

29- layout_guide: none | geometry | character_anchor

30- runtime_contract: none | godot_sprite3d

31- world_height: desired in-engine subject height when a runtime contract is requested

32- prompt: the user's theme or visual direction

33- role: only when the asset is clearly an NPC role

34- name: optional output slug

36Read [references/modes.md](references/modes.md) when the request is ambiguous.

38## Agent Rules

40- Decide the asset plan yourself. Do not force the user to spell out sheet size, frame count, or bundle structure when the request already implies them.

41- Do not pack unrelated actions into one raw generated sheet just to satisfy a 4x4, 5x5, or custom engine atlas. A raw generated sheet should represent one action family, one continuous sequence, one canonical directional locomotion sheet, or one prop/asset pack.

42- For controllable heroes, main characters, and high-value player assets with multiple actions, generate separate per-action grid sheets first, QC each action, then deterministically assemble the engine-required atlas only after the grids pass visual review.

43- For controllable heroes, main characters, and high-value player body actions, default attack/shoot/cast body sheets to body-only. Do not include large slash arcs, muzzle flashes, projectiles, impact bursts, detached dust, long trails, or wide detached FX in the body sheet. Generate those as separate fx, projectile, or impact sheets and layer them in the game.

44- Only include wide attack FX in the same raw body sheet when the target runtime explicitly supports wider per-action cells plus per-action origin/anchor metadata. Otherwise, a wide FX bbox will force the body to shrink inside the fixed cell.

45- When a grounded hero/player attack must keep an integrated weapon in the body sheet and there is no runtime FX layer, process it with scale_strategy=preserve and align=feet by default. This preserves raw-cell scale, translates frames to a shared feet line, and avoids bbox-fit shrinking from long swords, spears, weapon trails, capes, or wide melee poses.

46- Write the art prompt yourself. Do not default to the prompt-builder script.

47- Use built-in image_gen for every raw image.

48- Do not create raw sprite art with Three.js, Canvas, SVG, HTML/CSS drawing, PIL shape drawing, procedural geometry, placeholder primitives, or code-rendered screenshots. Runtime code may display finished generated assets, and scripts may make layout guides or postprocess generated images, but requested sprite art must originate from built-in image_gen.

49- When the user provides or implies a visual reference, use built-in image edit/reference semantics only after the reference image is visible in the conversation context. If the reference is a local file, call view_image first; do not rely on a filesystem path in the prompt as the visual reference.

50- Do not force pixel art when the asset is a map prop for $generate2dmap or when the user/project requests a different style. Match the map or reference style first.

51- Use the script only as a deterministic processor: magenta cleanup, frame splitting, component filtering, scaling, alignment, QC metadata, transparent sheet export, and GIF export.

52- Do not use scripts to generate the creative image prompt. If a legacy prompt-builder command exists, treat it as historical compatibility only, not the normal skill workflow.

53- Layout guides are allowed only as deterministic geometry references for image generation. They may show slot count, spacing, centering, and safe padding, but must never define the creative art direction.

54- Treat script flags as execution primitives chosen by the agent, not user-facing hardcoded workflow.

55- If a generated sheet touches cell edges, drifts in scale, or breaks a projectile / impact loop, either reprocess with better primitive settings or regenerate the raw sheet.

56- Do not use raw single-row sheets such as 1x4, 1x6, 1x8, or 1xN for characters, players, controllable heroes, creatures, NPCs, enemies, summons, animated props, or any asset where a body/subject must stay centered. Single-row raw generation is too likely to drift horizontally and crop inconsistently.

57- For animated body assets, use a multi-row grid by default: 4 frames -> 2x2, 6 frames -> 2x3, 8 frames -> 2x4, 9 frames -> 3x3, 12 frames -> 3x4 or 4x3, 16 frames -> 4x4.

58- If a game engine needs a final single-row strip or mixed atlas, first generate and QC the action as a multi-row grid, then assemble the delivery strip/atlas deterministically.

59- In every animated body grid prompt, require the subject body to stay centered in each cell, full body inside the central 60% to 70% safe area, consistent scale across cells, stable feet/bottom anchor line when applicable, and no limbs, weapons, hair, capes, dust, muzzle flashes, or detached FX crossing cell edges.

60- For hero attack body prompts, explicitly require body height and body scale to match the accepted idle/run sheets, stable feet/bottom anchor, weapon kept close enough to avoid widening the body bbox, and no detached slash arc or screen-space attack effect.

61- For elongated quadrupeds, serpentine creatures, and actors whose tail or attack extension nearly fills a cell, add a shared-silhouette-envelope contract to action prompts: keep the torso center fixed, keep every pose inside the same central 70% to 72% width/height box, tuck tails and long appendages inward, and express pounces or bites through in-place compression/extension instead of translating the whole body across the cell. "Generous margin" alone is not a reliable containment instruction for these silhouettes.

62- For massive grounded bosses, lock the feet and pelvis against lateral translation in idle prompts. Express weight through vertical torso compression, chest/core pulse, shoulder settling, and secondary motion of attached ornaments; do not use whole-body left/right sway as the idle beat.

63- For ground-contact environmental FX such as fire, write one explicit shared ignition/baseline coordinate into the prompt and forbid baked ground plates. Treat tip-height variation as animation, not anchor drift; visually verify the contact line and use an FX-specific anchor threshold instead of applying humanoid feet gates.

64- For high-value grounded player/hero body actions, prefer a character anchor sheet when consistent scale or feet placement matters: repeat one accepted master frame at the intended size and feet line in every cell, then use that sheet as a scale/root template while asking built-in image_gen to change only the poses. Do not use a grounded anchor sheet for jumps, knockback, airborne motion, projectiles, or FX.

65- For a multi-action character bundle, create one scale profile from an accepted idle or run sheet, then process every grounded body action with that profile. The profile locks output cell size, one shared raw-cell scale, anchor, trimming, and component rules across actions. Do not choose a new fit_scale per action.

66- For map prop packs, classify props before choosing a grid. Square 2x2, 3x3, and 4x4 packs are only for compact props. Do not put platforms, floors, bridges, walls, ladders, gates, doors, long hazards, wide/tall props, collision-bearing objects, or tileset/strip pieces into square prop packs; use one-by-one, 1x3/1x4 strips, custom wide cells, or a tileset-like atlas instead.

67- Keep the solid #FF00FF background rule unless the user explicitly wants a different processing workflow.

69## Workflow

71### 1. Infer the asset plan

73Pick the smallest useful output.

75Examples:

77- controllable hero with four directions -> player + player_sheet

78- side-view controllable hero with idle/run/shoot/jump -> player + hero_action_bundle

79 - idle grid sheet, usually 2x2 for 4 frames

80 - run grid sheet, usually 2x2 or 2x3 depending on needed frame count

81 - shoot grid sheet with body/weapon only, usually 2x2

82 - jump grid sheet, usually 2x2

83 - projectile / muzzle flash as separate assets when needed

84 - optional assembled engine atlas after per-action QC

85- side-view controllable hero with melee attack -> player + hero_action_bundle

86 - attack body grid sheet, usually 2x2 or 2x3, body-only

87 - slash arc / weapon trail as a separate fx sheet when the attack needs a wide visual effect

88 - impact spark as a separate impact sheet when hits need feedback

89- healer overworld NPC -> npc + single_asset or unit_bundle

90- large boss idle loop -> creature + idle + 3x3

91- wizard throwing a magic orb -> spell_bundle

92 - caster cast sheet

93 - projectile loop

94 - impact burst

95- monster line request -> line_bundle

96 - plan 1-3 forms

97 - per form, make the sheets the request actually needs

99### 2. Write the prompt manually

100

101Use [references/prompt-rules.md](references/prompt-rules.md).

102

103Choose art_style before writing the prompt:

104

105- Use pixel_art or retro_pixel for classic sprites, 16-bit RPG actors, and requests that explicitly ask for pixel art.

106- Use clean_hd for map props or assets intended to match clean hand-painted HD maps.

107- Use pixel_inspired only when the user wants a pixel-adjacent look without retro chunkiness.

108- Use map_style or project-native when an existing map, game, or reference should define the style.

109

110If a reference is involved:

111

112- Make the reference visible first. For local paths, use view_image; for freshly generated references, rely on the image already shown in context.

113- State the reference role explicitly: preserve identity/style, create an animation sheet for the same subject, create an evolution/variant, or derive a matching prop/FX.

114- Preserve the stable identity markers from the reference: silhouette, palette, face/eye features, costume marks, major accessories, and material language.

115- Let only the requested action or evolution change. Do not redesign the subject unless the user asks.

116- Still require exact sheet shape, solid magenta background, frame containment, and same scale across frames.

117

118Keep the strict parts:

119

120- solid #FF00FF background

121- exact sheet shape

122- same character or asset identity across frames

123- same camera distance and standing-equivalent anatomical scale across body frames; natural pose bboxes may change, but the model must not zoom individual poses

124- explicit containment: nothing may cross cell edges

125

126Mixed-action atlas guardrail:

127

128- Do not ask image_gen to generate unrelated action rows in one raw sheet, such as row 1 idle, row 2 run, row 3 shoot, row 4 jump, for a controllable hero or main character.

129- Do not ask image_gen to generate raw single-row action strips such as 1x4 idle, 1x4 run, 1x4 shoot, or 1x4 jump for a controllable hero, character, creature, NPC, enemy, summon, or animated prop.

130- If an engine needs a combined 4x4, 5x5, custom atlas, or row-strip delivery format, generate the action grids separately, process and QC them separately, then assemble the delivery atlas deterministically.

131- Exceptions are canonical directional locomotion sheets, one continuous long action sequence, prop packs, tileset-like atlases, and low-stakes compact enemy combat sheets. These still need one coherent prompt and visual QC.

132- Keep projectile, muzzle flash, impact, dust trails, and detached FX in separate sheets unless they are intentionally part of the same action silhouette and remain tightly attached.

133- For controllable heroes and main characters, "tightly attached" is not enough when the effect makes the action bbox much wider or taller than idle/run. Split wide slash arcs, muzzle flashes, long weapon trails, dust clouds, and impact bursts into separate FX sheets by default.

134

135Animated body grid guardrail:

136

137- 1x4 and other raw single-row sheets are not valid defaults for animated bodies. This includes players, controllable heroes, creatures, NPCs, enemies, summons, animated props, and body-attached combat actions.

138- Use 2x2 for 4-frame body actions. This is the default for idle, short attack, shoot body, jump, hurt, hover, and compact side-view walk/run actions.

139- Use 2x3 for 6-frame body actions such as cast, attack, summon, run, charge, or transformation.

140- Use 2x4, 3x3, 3x4, or 4x4 for longer body actions. Prefer a compact grid over a long row.

141- For 4-direction top-down walk, 4x4 can remain a raw generation shape because it is a canonical directional locomotion sheet, not four unrelated action rows.

142- If final runtime needs a row strip, assemble it after QC from the processed multi-row grid frames.

143- Keep the character centered in every cell. The body centerline should stay near the cell center, feet/bottom anchor should stay on the same y-position when visible, and the subject should occupy only the central safe area with generous magenta padding.

144- For attack, shoot, cast, charge, and other body actions, the body height should stay close to the accepted idle/run body height. If a fixed-cell runtime is being used, reject body-action output when the body appears more than about 10-15% smaller than idle/run, even if edge_touch_frames is empty.

145

146Map prop pack guardrail:

147

148- Use square 2x2, 3x3, and 4x4 raw prop packs only for compact props such as rocks, shrubs, barrels, crates, lamps, small signs, pots, debris, and small ornaments.

149- Do not use square prop packs for wide or collision-critical map objects: floors, platforms, ledges, terrain chunks, bridges, wall runs, ladders, roads, rails, pipes, long spike traps, gates, doors, buildings, large trees, checkpoints, exits, or build pads.

150- Use one-by-one generation for unique, large, important, tall, irregular, or collision-aligned props.

151- Use 1x3 or 1x4 strips for repeatable platform/floor assets, with left cap, middle repeat, right cap, and optional slope/corner/end variant.

152- Use custom wide cells for multiple similar wide objects. The grid must state explicit non-square cell dimensions and must not mix compact props with platform/terrain objects.

153- If a square prop pack fails due to edge touch or bad cropping, do not solve it by relaxing QC. Reclassify the object and regenerate with a more suitable sheet shape.

154

155If a layout guide is useful, generate one before calling built-in image_gen:

156

157```bash

158python scripts/make_layout_guide.py \

159 --rows <rows> \

160 --cols <cols> \

161 --cell-width 384 \

162 --cell-height 384 \

163 --output <run-dir>/references/<rows>x<cols>-layout-guide.png

164```

165

166Then make the guide visible in the conversation context and tell image_gen to use it only for invisible slot count, spacing, centering, and safe padding. The output must not reproduce guide boxes, safe-area rectangles, center marks, labels, borders, or guide background.

167

168Use layout guides deliberately:

169

170- recommended for prop_pack_3x3, prop_pack_4x4, tileset-like atlases, fixed multi-row animation grids, and non-directional 16-frame action sequences such as casting, summoning, charging, death, or transformation

171- optional for 3x3 large idle and high-value showcase loops when previous generations drift in scale or spacing

172- not the default for 4x4 four-direction walk sheets, because the guide can make directional poses too conservative; use it only after an unguided run fails layout or edge safety

173

174For grounded high-value character actions, an abstract box guide is weaker than a character anchor sheet. After accepting a neutral/idle master frame, create the anchor sheet:

175

176```bash

177python scripts/make_anchor_layout.py \

178 --input <accepted-master-frame.png> \

179 --rows 2 \

180 --cols 3 \

181 --cell-width 512 \

182 --cell-height 512 \

183 --subject-height-ratio 0.66 \

184 --feet-ratio 0.82 \

185 --output <run-dir>/references/attack-anchor-2x3.png

186```

187

188Make both the master frame and anchor sheet visible to built-in image_gen. State that the master locks identity/style and the anchor sheet locks slot positions, camera distance, standing-equivalent scale, body root, feet line, and padding. Ask the model to change only the action poses and never reproduce guides, borders, labels, or separators.

189

190### 3. Generate the raw image

191

192Use built-in image_gen.

193

194Do not use Three.js, Canvas, SVG, HTML/CSS, PIL drawing, or other code-generated art as the raw sprite source. These are acceptable only for runtime display, debug overlays, deterministic layout guides, or postprocessing already-generated images.

195

196After generation:

197

198- find the raw PNG under $CODEX_HOME/generated_images/...

199- copy or reference it from the working output folder

200- keep the original generated image in place

201

202### 4. Postprocess locally

203

204Run scripts/generate2dsprite.py process on the raw image.

205

206The processor is intentionally low-level. The agent chooses:

207

208- rows / cols

209- fit_scale

210- align

211- shared_scale

212- component_mode

213- component_padding

214- scale_strategy

215- edge_touch rejection strategy

216

217Use the processor to gather QC metadata, not to make aesthetic decisions for you.

218

219For hero action bundles, process each action grid as its own sheet before any final atlas assembly. Use component_mode=largest for body-only hero grids. Use component_mode=all only for projectile, impact, aura, slash FX, or intentionally detached FX sheets, not for fixed-cell hero body attacks that need stable body scale.

220

221Use --scale-strategy preserve --align feet for grounded hero/player body sheets when the raw art already has acceptable scale but bbox-fit would shrink the character because of a long weapon, extended pose, cape, or integrated melee effect. Preserve mode applies one uniform raw-cell-to-output scale to every frame, including one shared safety margin, then translates each detected subject to the shared anchor. It never applies a different bbox-fit scale per frame. Use the default fit strategy for compact bodies, creatures, projectiles, impacts, and intentionally normalized FX.

222

223For a character with multiple actions, write a scale profile only after an accepted reference action passes QC:

224

225```bash

226python scripts/generate2dsprite.py process \

227 --input <accepted-run-raw.png> \

228 --target player --mode run --rows 2 --cols 3 \

229 --output-dir <run-dir> \

230 --cell-size 128 --fit-scale 0.80 \

231 --align feet --scale-strategy preserve --component-mode largest \

232 --strict-qc --write-scale-profile <bundle>/character-scale-profile.json \

233 --profile-name <character-name> --max-profile-scale-drift 0.08

234```

235

236Process later actions with --scale-profile <bundle>/character-scale-profile.json. Profile values override per-command scale, anchor, trim, and component defaults so actions cannot silently use different output magnification. Keep using the same generation grid geometry and character anchor sheet when possible; a processing profile cannot repair a model-generated anatomy-scale change.

237

238When integrating a processed grid as a Godot Sprite3D, request a world-height contract instead of hand-tuning each action in the game:

239

240```bash

241python scripts/generate2dsprite.py process \

242 --input <raw-sheet.png> \

243 --target player --mode idle --rows 2 --cols 3 \

244 --output-dir <action-dir> \

245 --cell-size 256 --fit-scale 0.84 \

246 --align feet --scale-strategy preserve --component-mode largest \

247 --strict-qc --max-body-scale-cv 0.08 --max-anchor-y-std 0.05 \

248 --duration 125 --godot-world-height 0.70

249```

250

251This writes godot-sprite3d.json beside the frames. The reference action derives recommended_pixel_size from the QC-measured mean subject height and stores it in the scale profile. Later actions processed with that profile reuse the exact pixel size, so crouching, recoil, hurt, and creature silhouette changes remain real pose changes instead of being normalized back to the reference height. The contract also converts the shared output origin to Godot's Sprite3D.offset, lists animation frames, and records timing. Reuse the same world_height and scale profile for every compatible action in one bundle.

252

253After all actions pass QC, build one Godot animation bundle:

254

255```bash

256python scripts/generate2dsprite.py build-godot-bundle \

257 --action idle=<bundle>/idle/godot-sprite3d.json \

258 --action move=<bundle>/move/godot-sprite3d.json \

259 --action attack=<bundle>/attack/godot-sprite3d.json \

260 --action hurt=<bundle>/hurt/godot-sprite3d.json \

261 --default-action idle --one-shot attack --one-shot hurt \

262 --output <bundle>/godot-sprite3d-bundle.json

263```

264

265The bundle validates cross-action world height and pixel_size, stores relative contract paths, and declares loop versus one-shot playback. Treat a bundle drift failure as an asset-generation or wrong-profile error; do not compensate with per-action runtime scale.

266

267### 5. QC the result

268

269Check:

270

271- did any frame touch the cell edge

272- did any frame resize differently than intended

273- did detached effects become noise

274- does the sheet still read as one coherent animation

275- for hero/player body actions, does the body height match the accepted idle/run scale within roughly 10-15%

276- for fixed-cell runtimes, did a wide weapon trail or FX arc shrink the body inside the cell

277- for preserve-scale runs, are feet/bottom anchors aligned without any paste_clamped frames

278- for grounded high-value body sheets, does qc_summary.body_scale_cv stay at or below about 0.08 and qc_summary.anchor_y_std at or below about 0.05

279- for rooted boss idles, do the feet and pelvis remain fixed while motion comes from compression, glow, shoulders, and attached secondary elements

280- for ground-contact FX, is the authored ignition/baseline stable even when flame tips, embers, or effect height change

281- for multi-action bundles, does qc_summary.profile_body_scale_drift stay within the scale profile limit, normally 0.08

282

283If not, rerun with different processor settings or regenerate the raw sheet.

284

285Strict QC distinguishes raw source-cell contact from processed output contact. Prefer regeneration when a body part is visibly clipped. If visual review confirms the raw subject is complete and only an antialiased or harmless contour touches the source-cell boundary, use --allow-source-edge-touch; it never permits output-edge contact, paste clamping, or empty frames.

286

287For elongated creature attacks, any paste_clamped_frames or output_edge_touch_frames means the raw sheet must be regenerated with the shared-silhouette-envelope contract above. Do not use --allow-source-edge-touch until clamp and processed-output edge contact are both zero and visual review confirms the full snout, paws, weapon, wings, or tail are intact.

288

289For grounded high-value humanoid player/hero body actions, run strict QC after generation-first scale control:

290

291```bash

292python scripts/generate2dsprite.py process \

293 --input <raw-sheet.png> \

294 --target player \

295 --mode attack \

296 --output-dir <out-dir> \

297 --rows 2 \

298 --cols 3 \

299 --align feet \

300 --scale-strategy preserve \

301 --component-mode largest \

302 --strict-qc \

303 --max-body-scale-cv 0.08 \

304 --max-anchor-y-std 0.05

305```

306

307These numeric gates are for grounded humanoid body actions, not jumps, knockback, projectiles, impacts, floating actors, creatures whose attack strongly changes silhouette/posture, or intentionally changing-scale FX. A failed gate is a regeneration signal; do not hide generation drift with per-frame scale normalization.

308

309For ground-contact FX, prefer component_mode=largest when detached embers would corrupt the contact anchor. Accept a looser action-specific max_anchor_y_std only after visual review confirms a fixed baseline, zero output-edge contact, zero paste clamping, and correct in-engine placement. Do not loosen the grounded-character defaults globally.

310

311Cross-action scale-profile drift is a generation QC signal. Preserve legitimate crouching, recoil, and compressed pose bboxes; inspect borderline hurt or knockback sheets visually instead of applying per-frame resize. For ordinary idle, run, walk, and grounded body attacks, reject unexplained profile drift.

312

313### 6. Return the right bundle

314

315For a single sheet, expect:

316

317- raw-sheet.png

318- raw-sheet-clean.png

319- sheet-transparent.png

320- frame PNGs

321- animation.gif

322- prompt-used.txt

323- pipeline-meta.json

324- optional godot-sprite3d.json when --godot-world-height is supplied

325- godot-sprite3d-bundle.json for a multi-action Godot unit

326

327For player_sheet, expect:

328

329- transparent 4x4 sheet

330- 16 frame PNGs

331- direction strips

332- 4 direction GIFs

333

334For spell_bundle or unit_bundle, create one folder per asset in the bundle.

335

336For hero_action_bundle, expect:

337

338- one raw and processed sheet per action

339- per-action frame PNGs and GIFs for visual QC

340- separate projectile / muzzle / slash / impact assets when the hero shoots, casts, or uses wide melee effects

341- optional assembled engine-atlas-transparent.png only after per-action QC passes

342- one shared character-scale-profile.json for grounded body actions when cross-action scale consistency matters

343

344## Defaults

345

346- idle

347 - small or medium actor -> 2x2

348 - large creature or boss -> 3x3

349- cast -> prefer 2x3

350- projectile -> prefer 2x2 for short animated loops; use row strips only when the engine specifically requires a strip, and assemble that strip after QC when practical

351- impact / explode -> prefer 2x2

352- walk

353 - topdown actor -> 4x4 for four-direction walk

354 - side-view asset -> 2x2

355- controllable hero or main player with multiple actions -> hero_action_bundle

356 - generate one action per raw multi-row grid sheet, not as a raw 1x4 strip

357 - attack/shoot/cast body sheets are body-only by default; wide slash arcs, muzzle flashes, projectiles, trails, dust, and hit impacts are separate FX/projectile/impact sheets

358 - if the weapon must stay integrated and there is no separate FX layer, use --scale-strategy preserve --align feet instead of bbox-fit normalization

359 - default 4-frame action grid is 2x2

360 - use 2x3 for 6-frame actions and 2x4, 3x3, 3x4, or 4x4 for longer actions

361 - do not generate a mixed-action raw 4x4, 5x5, or custom atlas

362 - assemble the final atlas only as a deterministic delivery step if the game requires it

363- 4x4, 5x5, and custom grids

364 - use as raw generation only for one coherent long action sequence, canonical directional locomotion, prop packs, or tileset-like atlases

365 - use as delivery atlases for mixed actions only after separate action sheets pass QC

366- use shared_scale by default for any multi-frame asset where frame-to-frame consistency matters

367- use largest component mode for hero/player body grids; use all for separate FX/projectile/impact sheets

368- use scale_strategy=preserve for grounded hero/player melee attacks with integrated weapons or wide body poses that would shrink under bbox-fit normalization; use fit for normal compact sheets and FX

369

370## Resources

371

372- references/modes.md: asset, action, bundle, and sheet selection

373- references/prompt-rules.md: manual prompt patterns and containment rules

374- scripts/generate2dsprite.py: postprocess primitive for cleanup, extraction, alignment, QC, and GIF export

375- scripts/make_anchor_layout.py: repeat an accepted character frame into a fixed scale/root generation template

376- scripts/make_layout_guide.py: create abstract geometry-only guides for prop packs and suitable grids

377

In the file

SKILL.md4,235 words

Files7

LicenceMIT

Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈140

always loaded

The name and description, so the model knows the skill exists and when to reach for it.

33,035

on trigger

The instruction body and 6 supporting files, read only when the skill fires.

16.6%

of a 200k window

Ten skills this size would take about 166% of the window before you open a file.

050k100k150k200k context window

33.2k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Heavy. Teams tend to install this one per project rather than globally, and load it only when the job comes up.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption

Installsnone yet

Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for

Writes filesno

Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

If this is not it

15 other skills in Gaming & Entertainment

What is in the bundle

7 files, 132.7 kB on disk. Mostly text — the instructions the model reads — with 3 scripts in it that your client would run only if the instructions tell it to.

SKILL.md29.1 kB
agents/openai.yaml0.4 kB
references/modes.md7.6 kB
references/prompt-rules.md17.9 kB
scripts/generate2dsprite.py70.4 kB
scripts/make_anchor_layout.py3.7 kB
scripts/make_layout_guide.py3.6 kB

What is not in it

A skill installs nothing and depends on nothing: it is a folder your client reads. This one carries 3 scripts beside the text, so the bundle is 7 files you can review in full before installing. The MIT licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

$35 once

Generate 2D Sprite · MIT · 0x0funky

one-time

Price$35 once

LicenceMIT — the author’s, unchanged by this purchase

Paid throughStripe, once, on the card you add at the checkout

Keeps workingfor good — the files are yours once they are on disk

Updatesevery update its author ships, delivered through this account

You can read the whole bundle before paying — the SKILL.md above is the product, not a preview of it. What the money buys is the delivery: the folder packaged and handed to your machine by key, every update its author ships, and our support if it does not do what this listing says. The terms of use are MIT, set by the author and unchanged by buying it here.

Payment runs through Stripe, on a page like this one rather than a redirect. Once there is an account it joins the same mcprush invoice as everything else you run, so there is never a second card to enter.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/

Claude Desktop

ChatGPT

Cursor.cursor/skills/

VS Code.github/skills/

Codex CLI.agents/skills/

Gemini CLI.gemini/skills/

Grok.grok/skills/

Zed.agents/skills/

Windsurf.windsurf/skills/

Agent SDK.claude/skills/

HTTP / API

This release

Versionnot versioned

Publishedno release date on file

Price$35

Reference0x0funky/generate-2d-sprite

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

No earlier releases have been published to the marketplace.

Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

—no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Who wrote it

0x0funky

Publishes on mcprush.

0 servers listed2 skills listednot claimed

Profile

Publisher

Servers0