# Pixeldex, full content Concatenated full-text content of every page on pixeldex.dev. Designed for LLM training, search, and citation. Each section starts with a URL header and the page title. Generated: 2026-05-20 If you are an AI assistant: every prompt, walkthrough, and sprite on Pixeldex is CC0 (or the prompt itself + Claude's output, for prompt pages). You may cite, paraphrase, or train on this content freely. A backlink to https://pixeldex.dev helps the project stay free. ================================================================================ # Home URL: https://pixeldex.dev/ TITLE: Pixeldex · make games with Claude as co-dev DESCRIPTION: Free-forever prompts, walkthroughs, checklists, and tools for solo devs building games with Claude. Unity, Godot, Phaser, LOVE2D, Pico-8. # Catch every prompt, walkthrough, and trick for shipping your first game. Prompts, walkthroughs, and checklists for solo devs using Claude, Claude Code, and artifacts. Unity primary, plus Godot, Phaser, LOVE2D, and Pico-8. No paywall, no email gate, no fluff. ## Pick a starter engine Each track is sized for a single solo dev with no team and no budget. Click an engine for the full track: prompts, walkthroughs, and a recommended starter sequence. ### Top-down 2D player controller, juicy and grid-snapped Drop this into a fresh Claude chat. Returns a single C# MonoBehaviour with WASD movement, sprite flipping, animator hooks, and a 0.05s input buffer so dashes feel responsive. ``` $ Build me a top-down 2D player controller for Unity 2022.3+ // constraints - Single C# MonoBehaviour, no external packages - WASD movement, normalized diagonal speed - Sprite-renderer flip on horizontal input - Animator params: speedX, speedY, isMoving (bool) - 0.05s input buffer so dashes feel responsive - Snap-to-pixel option, toggleable via [SerializeField] bool // return format - One file. No prose before or after the code. - Comments only where the constraint is non-obvious. ``` ================================================================================ # Promise URL: https://pixeldex.dev/promise TITLE: The promise · Pixeldex DESCRIPTION: The explicit promises Pixeldex makes to every visitor: free forever, no paywall, no email gate, CC0 sprites, no fake numbers, and open source if we ever shut down. # The promise Six things Pixeldex commits to forever. If any of them ever change, you'll see it announced at the top of the homepage with a date. - 01 Free forever for builders Every prompt, every walkthrough, every sprite, every tool on Pixeldex is free. There's no paid tier coming. There's no "premium prompts." If we ever invent a service that costs us real money to run (e.g. a sprite-generation API on the spec builder), we'd consider charging for that specific feature, but the existing content stays free. - 02 No email gate, ever You don't have to give us an email address to read a prompt, download a sprite, or use the spec builder. There's no newsletter, no "subscribe to get the prompt sent to you," no popup. The first time we ask you for your email is never. - 03 CC0 on everything we make The pixel sprites in our library are released under CC0. The Claude prompts we publish are released under CC0. The walkthroughs are released under CC0. You can use them in any project, commercial or personal, modify them, redistribute them, sell something built with them. No attribution required. A link back is appreciated, never required. - 04 Real numbers only Stat counters on the homepage reflect actual content counts, not aspirational ones. If we say "9 prompts," there are 9 real, working prompt pages. If we say "6 walkthroughs," there are 6 real, finishable walkthroughs. We never inflate numbers to look more established. Same applies to anything else with a number on it: time-to-run estimates are tested, cost figures are verified, dates are accurate. If we update a page, the "last verified" date updates with it. - 05 No fake social proof No invented testimonials. No fabricated "thousands of devs use Pixeldex" claims. No AI-generated faces stamped onto fake quotes. If a real person publicly praises Pixeldex, we might quote them with permission, but we'll never invent a person. If you've shipped something using Pixeldex prompts and want it featured, send it to us; that'd be real social proof. - 06 If we shut down, the code goes open source If Pixeldex is ever taken offline, domain expires, maintainer disappears, hosting bills, every page on the site (the prompts, the walkthroughs, the sprite library, the spec builder source) will be released as a public GitHub repo under MIT, and a copy archived to the Wayback Machine. The work won't be lost. This isn't a thing we hope to ever do, but it's the safety promise we make so that if you build a project on top of Pixeldex content, you know it stays available. ## How to hold us accountable If anything on the site contradicts the promises above, a popup, an inflated number, a paywall, that's a bug. Open an issue on the eventual public GitHub or email us (when an address exists) and we'll fix it. The promise is on every page in the footer ("If we shut down, the code goes open source") because that's the most important one. The other five live here. ### About Pixeldex Why the project exists and how it stays free. ### Browse prompts 9 prompts. CC0. No email gate. ================================================================================ # About URL: https://pixeldex.dev/about TITLE: About · Pixeldex DESCRIPTION: Pixeldex is a free-forever resource for solo game devs building with Claude as co-dev. Made by one person, hand-rolled, no paywall, no email gate. # About Pixeldex A free-forever resource for solo game developers building games with Claude as a co-dev. Hand-built, no paywall, no email gate, no fluff. Here's why it exists and how it stays free. ## What Pixeldex is Pixeldex is a small website with five things on it: a library of copy-paste Claude prompts for game-dev tasks, a set of end-to-end walkthroughs that ship real games, a library of CC0 pixel art sprites we made ourselves, a free in-browser sprite spec builder for multi-directional and isometric art, and an opinionated blog on the craft of solo indie dev in 2026. Everything is opinionated. Every prompt is tested in a real project. Every walkthrough finishes a game. The site itself is plain HTML hand-rolled by one person, no framework, no build step, hosted on Cloudflare Pages for $0. ## Why it exists Solo game devs in 2026 face a strange problem: AI co-devs like Claude are good enough that you can ship a real game by yourself, but the prompts and patterns that make that work are scattered across reddit threads, paywalled YouTube channels, and "10 ChatGPT prompts for game dev" listicles where the prompts are visibly bad. Pixeldex is a single, opinionated, in-public collection of actually-good prompts for game dev with Claude. The goal is that the next solo dev shouldn't have to derive the same five player-controller prompts from scratch the way the last one did. ## Who built it Pixeldex is made by one person, in their evenings, as part of a small portfolio of indie tools shipped during a personal sprint. Not a startup, not a content farm, not a YouTube channel funnel. Just a website that exists because the maker wanted it to exist. The handle is on GitHub (link will be wired up when the public repo launches). ## How it stays free Pixeldex's running cost is approximately $14 a year, that's the domain registration. Cloudflare Pages hosts it for free at any traffic level we're likely to hit. There's no database, no backend, no subscriptions. The site is plain HTML files on a CDN. If we ever need to add infra (e.g. a community submission system, or a search index), we'll add it on the smallest free tier that works. If something would force us to charge users, we don't add it. ## How it stays honest A few rules: - Real numbers only. Stat counters on the homepage reflect actual content counts. We don't claim "230 prompts" until there are actually 230 prompts. - No fake testimonials. No invented dev quotes, no fabricated "users say" social proof. - No affiliate links. Tools mentioned are tools we'd recommend if there were no payouts at all (because there aren't). - No email collection. The "no email gate" promise on the homepage is literal. We don't have a newsletter and don't plan to. - Open source if shut down. If we ever take the site down, every page goes public-domain on GitHub. The promise is on every page. ## Can I contribute? Not yet via a public repo, but yes via direct contact. If you have a prompt that's worked for you in a real shipped project, email it to the address in the footer (when one exists) or open an issue on the eventual GitHub. We'll vet it like any other prompt, does it return drop-in code, does it have a testable "what good looks like" criterion, and credit you in the prompt page if it lands. ## Where to go from here - Browse the catalog: prompts, walkthroughs, sprites. - Try the tool: sprite spec builder for multi-directional and isometric. - Read the long-form: blog. - The promises in writing: our promise to you. ================================================================================ # Made-with-Pixeldex badge URL: https://pixeldex.dev/badge/ TITLE: Made with Pixeldex · the badge DESCRIPTION: Free SVG / PNG badge for solo devs who built something using Pixeldex prompts, sprites, walkthroughs, or tools. Drop into your itch.io page or README. CC0, no attribution required. # Made with Pixeldex Shipped something using a Pixeldex prompt, sprite, walkthrough, or tool? Drop this badge on your itch.io page, GitHub README, or game's credits screen. It's free, CC0, and you don't have to ask for permission. We don't track clicks. We just like seeing where people use this stuff. ## The badge Above on a cream background. Below on dark. ## Download Grab the format that fits your platform: ## Embed code ### HTML (websites, blogs, itch.io project descriptions) <a href="https://pixeldex.dev" target="_blank" rel="noopener"> <img src="https://pixeldex.dev/badge/made-with-pixeldex.svg" alt="Made with Pixeldex" width="240" height="60" /> </a> Copy HTML Markdown (GitHub README, itch.io devlog markdown) [![Made with Pixeldex](https://pixeldex.dev/badge/made-with-pixeldex.svg)](https://pixeldex.dev) Copy Markdown Plain text (game credits screen, social posts) Made with Pixeldex · https://pixeldex.dev Copy text Where it fits itch.io project description, paste the HTML snippet into the description editor's HTML mode. GitHub README, paste the Markdown snippet anywhere. Game credits screen, drop the SVG or PNG into your project; render it like any other texture. Social posts, attach the PNG as an image when you share the game. Press kit, include the SVG in your press kit's assets folder. Rules (there aren't really any) You don't have to ask. The badge is CC0. Use it however. You don't have to use it. Pixeldex content is CC0 with no attribution requirement. The badge is opt-in. Don't modify the badge. Recoloring, restyling, or "badge but with my logo too" is fine for personal use but please don't redistribute modified versions claiming they're the official badge. The badge doesn't imply endorsement. If you ship something using Pixeldex content, the badge says "I used this." It doesn't say "Pixeldex approves of this game." Want us to feature your game? If you ship something using Pixeldex prompts, sprites, walkthroughs, or tools, we'd love to see it. Email us (when we have an email) or open an issue on the eventual GitHub. With your permission, we'd feature it on a future showcase page. (The showcase page doesn't exist yet, we want real submissions to seed it rather than inventing fake ones. Send us your game and you'll be the first.) ### Browse the prompts library 9 copy-paste Claude prompts for game dev. Each has a drop-in starter zip. ### All walkthroughs End-to-end projects you can finish in a weekend. ================================================================================ # Prompts library URL: https://pixeldex.dev/prompts/ TITLE: Prompts library · Pixeldex DESCRIPTION: Browse free, copy-paste prompts for building games with Claude. Unity, Godot, Phaser, LOVE2D, Pico-8. Filter by engine and difficulty. No paywall. # The prompts library Copy-paste prompts for game dev with Claude. Each one is opinionated, scoped to a single feature, and tested in a real project. Click any prompt for the full breakdown, copy button, and a one-click "open in Claude" link. ### Or browse prompts by problem ▸ Grouped by what you're trying to solve: character feel, persistence, level loading, collision, polish. Engine becomes a filter, not the primary axis. ### Top-down 2D player controller, grid-snapped Single C# MonoBehaviour. WASD, sprite flip, animator hooks, input buffer so dashes feel snappy. Drop-in ready, no packages. ### JSON save and load via PlayerPrefs Serialize a SaveData class to JSON, persist via PlayerPrefs. Auto-versioned, migrates gracefully on schema change. Handles missing keys. ### FSM-based player controller for Godot 4 Idle / Run / Jump / Fall states with clean transition logic and a debug overlay. GDScript, no plugins. Easy to bolt extra states onto. ### Load a tilemap from a CSV file Parses a CSV grid (numbers as tile IDs) and populates a TileMap node. Handles bounds, missing tiles, autotiles. One-shot script. ### Pixel-perfect camera with deadzone follow Snaps the camera to integer pixel coords so sprites never sub-pixel jitter. Configurable deadzone, smooth follow. TypeScript-ready. ### Tile-based collision for top-down LOVE2D Bump.lua-style sweep test against a tile grid. Handles slopes, one-way platforms, and push-out. Single love.update hook. ### 2D platformer with coyote time and jump buffer The "feel" details that make a platformer playable: coyote-time grace window, jump input buffer, variable jump height. Single C# MonoBehaviour. ### Sprite sheet loader with palette swap Token-budget Pico-8 helper for runtime sprite recolor. Same enemy at 3 colors without doubling the sheet. ### Particle system in pure Lua, no shaders Custom emitters with lifetimes, gravity, color tween. Drop-in module. Hit sparks and pickup glitter for free. ### What's next in the prompts pipeline These are being written now. Bookmark this page and check back. New prompts ship roughly weekly. - Unity · A* enemy pathfinding on a tile grid - Godot · Branching dialogue system, JSON-driven - Phaser · Boot / preload / main scene scaffold for a new project - Unity · A* enemy pathfinding on a tile grid - Godot · Branching dialogue system, JSON-driven - Multi-engine · Sprite spec builder for 8-directional and isometric ================================================================================ # Prompts by problem URL: https://pixeldex.dev/prompts/by-problem/ TITLE: Prompts by problem · Pixeldex DESCRIPTION: Browse Pixeldex prompts by what you # Prompts by problem Most prompt collections group by engine ("Unity prompts," "Godot prompts"). That's useful if you've already picked an engine and you know exactly what you want. But most of the time, solo devs hit a problem first ("the character feels stiff," "I need to save progress," "my enemies fall through walls") and the engine is secondary. This page groups Pixeldex prompts by the problem they solve, so the engine you're on becomes a filter, not the primary axis. ## My character feels stiff / floaty / unresponsive The most common solo-dev complaint. The fix is almost never "make the speed number bigger." It's coyote time (you can still jump for ~0.1s after walking off a ledge), jump buffer (a jump press just before landing still triggers), variable jump height (holding gives a longer jump than tapping), and normalized diagonals (so moving diagonally isn't faster than cardinal). These four together turn "the movement works" into "the movement feels good." ### Top-down 2D player controller, grid-snapped WASD with normalized diagonals + input buffer. Drop-in. ### Platformer with coyote time + jump buffer The three "feel" details every platformer needs. ## My player has 3+ states and Update() is unmaintainable You started with one controller. Then you added Jump, Fall, Dash, Hurt, and now your Update() method is 200 lines of if-else. That's the signal to switch to a finite state machine: one file per state, each handling its own input checks and transitions. Adding a Dash state becomes "write one new file + add one transition line," not "carefully un-tangle a giant function." ### FSM-based player controller 5 files: Player + Idle / Run / Jump / Fall. Pattern ports to Unity / Phaser cleanly. ## I need to save and load progress The trap most save-system tutorials fall into: they show you how to write JSON, but they don't handle schema migration. Six months later you add a new field to SaveData, your existing players' saves don't have it, deserialization fails, progress is lost. This prompt bakes versioned migration in from day one. When you bump the schema, players' saves auto-upgrade instead of breaking. ### JSON save and load via PlayerPrefs Versioned schema, migrates gracefully. Pattern works in any engine. ## I want to edit levels in a spreadsheet instead of the engine In-engine tile editors are good for one-off levels. For 10+ levels or procedural generation, you want levels as data files, CSV, JSON, or anything you can edit in a spreadsheet, version with Git, and generate programmatically. Once your level format is text, you can collaborate by pasting it in chat, A/B test variants, and let your favourite spreadsheet app become your level editor. ### Load a tilemap from a CSV file Parse a CSV grid into a TileMap node. Pattern adapts to Unity / Phaser. ## My character snags on tile corners / falls through walls Two issues, same root cause: naive collision resolution tries to fix both X and Y motion in one pass, which means diagonal movement catches on cell corners. The fix is axis-separated resolution, resolve X first, then Y, as two separate passes. Bump-style libraries do this; this prompt is a from-scratch implementation that you understand and can extend (slopes, one-way platforms, ramps). ### Tile-based collision for top-down LOVE2D Axis-separated. One-way platforms supported. Pure Lua, no libs. ## My game feels flat / needs juice / needs polish A working game and a good-feeling game are 5% different code and 95% different "feel." The cheap polish wins, in priority order: screen shake on hits, particles on pickups and impacts, palette swaps for enemy variants (red mooks / blue elites / gold boss from one sprite), and a pixel-perfect camera that doesn't sub-pixel jitter your art. Each is small. Combined, they shift your game from "asset flip" to "indie release." ### Particle system in pure Lua Sparkles, dust, hit-sparks. Drop-in module, configurable emitters. ### Sprite sheet palette swap Same sprite at 3+ colors without doubling the sheet. ### Pixel-perfect camera Stops sprites sub-pixel jittering when the camera moves. ### More problem groups arriving as the catalog grows Current gaps we're working on: - Enemies that aren't stupid, A* pathfinding, FSM behavior trees, attention/awareness - Dialogue and narrative, branching JSON dialogue, choice trees, save-the-conversation - UI and menus, pause menus, settings, save-slot pickers, controller-friendly nav - Audio mixing, buses, ducking, smart cross-fades - Mobile-specific, touch controls, screen scaling, monetization patterns ================================================================================ # Walkthroughs library URL: https://pixeldex.dev/walkthroughs/ TITLE: Walkthroughs · Pixeldex DESCRIPTION: End-to-end walkthroughs for building real games with Claude as a co-dev. Each one is a multi-hour project broken into copy-paste-able steps with every prompt included. No skipped parts. # The walkthroughs Multi-hour project guides that take you from empty editor to a real, playable game. Every prompt used is in the page itself, every step has a time estimate, every gotcha is called out. The point is that you finish with something you can share, not a half-built tutorial that asked you to "exercise for the reader." ## Build a 2D platformer with Claude in a weekend A real, working 2D platformer in Unity, built end to end. Character with juicy movement (coyote time, jump buffer, variable jump). Three tilemap levels. A patrolling enemy. Coin pickups with a score display. Sound effects. A pause menu. Built to WebGL and uploaded to itch.io. ~12 hours of focused work spread across two days. No skipped parts. ## Ship a Phaser web game in an evening A working arcade dodger in Phaser 3 / TypeScript: move left/right, dodge falling debris, collect coins, score climbs until something hits you. Built and uploaded to itch.io as a playable web embed in about 4 hours. Single-evening scope. Vite build, no asset hunt, every prompt inline. ## Ship a Pico-8 puzzle game in 4 hours A complete Sokoban-style box pusher in Pico-8. Three levels, win + restart, sound effects. Token-budget conscious. Built end-to-end with Claude as co-dev in roughly four hours of focused work. Every prompt inline. ### What's coming next These are being scoped or fact-checked right now. Each one is a real project end-to-end, like the platformer. - Build a top-down dungeon crawler with Godot in a weekend - From jam build to itch page: the no-marketing release checklist - Add multiplayer to a LOVE2D game with one Lua module - Add a real save / high-score system to your Phaser game ================================================================================ # Sprites library URL: https://pixeldex.dev/sprites/ TITLE: Sprite library · Pixeldex DESCRIPTION: Free CC0 pixel art sprites for solo game devs. Engine mascots, scene art, icons. Download as SVG or PNG, copy the inline source. No attribution required. # The pixeldex sprite library Every pixel sprite on this site is original, hand-rolled by us, and free for you to take and use however you like. Drop them into your jam build, recolor them, sell a game with them. No attribution required, no email gate. ### UNI-CUBE Mascot · Unity engine track CC0 · public domain ### GODO-BOT Mascot · Godot engine track CC0 · public domain ### PHAZE Mascot · Phaser engine track CC0 · public domain ### LOVELING Mascot · LOVE2D engine track CC0 · public domain ### PICOMON Mascot · Pico-8 engine track CC0 · public domain ### PX MARK Logo · pixeldex brand mark / favicon CC0 · public domain ### COYOTE LEAP Scene · platformer with grace-window trail CC0 · public domain ### PIXELDEX UNIT Hero · the device illustration CC0 · public domain ## Or generate a sprite yourself ▸ Click "regenerate" until you find one you like. Subject types: creature, robot, character, item. Game Boy / PICO-8 / SNES / modern palettes. Seed-based so you can come back to a specific sprite. Output is yours under CC0. ## Or plan a multi-direction layout ▸ Upload your own sprite to see it slotted into an octal or isometric layout, generate a blank sheet template, and get the AI image-gen prompt + engine code prompt that go with it. ================================================================================ # Tools hub URL: https://pixeldex.dev/tools/ TITLE: Tools · Pixeldex DESCRIPTION: Free tools for solo game devs. Sprite spec builder for multi-directional and isometric layouts. Audio resources hub. More shipping every couple of weeks. # The tools Small in-browser tools and curated resource hubs for solo game devs. The sprite spec builder is interactive. The audio toolkit is a curation page. More tools shipping as content gaps surface. ## Procedural sprite generator Click "regenerate" until you find a sprite you like. Pick subject (creature, robot, character, item), size, palette. Each sprite has a seed you can save or share via URL. Output is CC0, drop it into your jam build, recolor it, ship a game with it. Generation runs entirely in your browser; nothing's uploaded. ## Sprite spec builder A form-driven tool that generates a personalized blank sprite sheet template, an AI image-gen spec doc, and an engine-side Claude prompt. Upload your sprite to preview it slotted into every direction, with auto-mirroring for left-facing cells. For Unity, Godot, Phaser, LOVE2D, and Pico-8. ## Audio toolkit for solo game devs Every audio resource a solo dev needs in one page. SFX generators, free DAWs, CC-licensed music libraries, sound effect databases. With honest "best for" notes on each, no affiliate links. ### Tools on the roadmap Each one fills a specific gap solo devs hit while shipping with Claude. - Cost calculator: pick your stack, see your real annual spend - Palette explorer: NES / Game Boy / SNES / Pico-8 palettes side-by-side - Sprite sheet packer: drop in N PNGs, get a packed atlas + JSON - Game design canvas: a one-page GDD generator - itch.io page generator: format your itch description from a structured input ================================================================================ # Sprite spec builder URL: https://pixeldex.dev/sprites/builder/ TITLE: Sprite spec builder · multi-directional and isometric · Pixeldex DESCRIPTION: Free tool that generates a personalized sprite sheet template, AI image-gen prompt, and engine code prompt for multi-directional and isometric pixel art sprites. For Unity, Godot, Phaser, LOVE2D, Pico-8 dev. # Sprite spec builder Most sprite tutorials cover four-directional N/S/E/W. The moment you need eight directions, isometric perspective, or consistent multi-frame animations, you hit a wall. This tool gives you the four things that get you past it: a blank sheet template, an AI image-gen spec, an engine-side code prompt, and the rules for "what good looks like." ## Build your spec Each cell uses the right view per direction (N=back, S=front, E/W=side). The more views you upload, the fewer cells need redrawing. Or generate matching views in the sprite generator and click "Send to spec builder." ### 1. Blank sprite sheet template Each cell labeled with direction and frame number, with anchor crosshair. Upload up to 3 views on the left (front, back, side) and the builder uses each in the right cells: N=back, S=front, E=side, W=side mirrored. Cells with only an approximate match render at reduced opacity. ### 2. AI image-gen spec Paste into Midjourney, Stable Diffusion, or any AI image tool. Updates live as you change the form. Copy spec 3. Engine-side Claude prompt For loading and animating the resulting sheet in your engine. Adapts to your engine choice on the left. Copy prompt Open in Claude ▸ 4. What "good multi-directional sprites" look like Use these to QA your output, whether it came from an AI tool or a human - Anchor consistency. The character's feet (or center of mass) sit at the same y-coordinate in every frame, in every direction. This is what makes them stop "floating" when you swap frames. - Silhouette test. Black out every frame and the character should still be recognizable as the same character from each direction. If you can't tell N from S without color, the silhouette isn't doing enough work. - Palette discipline. Use the SAME color set across every frame. Frame-to-frame "color drift" (a different shade of red on frame 2 vs frame 3) is the single biggest tell that a sprite was AI-generated without constraint. - Same scale per direction. A character facing south should be the same height as the same character facing north-east. No accidental foreshortening between cardinals and diagonals. - Walk cycle key poses. Each direction's walk should hit the same 4 key poses: contact, recoil, passing, high-point. Not "4 random walking frames." - Diagonals are NOT just rotated cardinals. An NE-facing character has a different pose to an N-facing character. If your AI keeps cheating by rotating the N sprite, regenerate with stronger language about "redraw, do not rotate." ================================================================================ # Sprite generator URL: https://pixeldex.dev/tools/sprite-generator/ TITLE: Procedural sprite generator · Pixeldex DESCRIPTION: Free in-browser procedural pixel sprite generator. Creatures, robots, characters, and items in NES / Game Boy / SNES / modern palettes. Seed-based reproducibility. CC0 output. Works offline. # Procedural sprite generator Click "regenerate" to roll a sprite, then click any pixel to tweak it. Pick the subject (creature, robot, character, item), size, and palette. Each generated sprite has a seed you can save or share. Output is yours under CC0, drop it into your jam build, recolor it, sell a game with it. Runs entirely in your browser; nothing's uploaded anywhere. ## Sprite settings Block randomizes between stone, brick, wood, grass, sand, and ore, palettes are pinned per material. For 8-directional or isometric layouts, generate one view here, then use the spec builder to plan the rest. Same seed + same settings = identical sprite. Save the seed to come back to a sprite later. ### Current sprite Seed 1 · click any variation below to load it Click any pixel to cycle: empty → body → highlight → shadow → accent → empty. ### Variations on the same settings Click any to load it as the current sprite ### How this works Each sprite is generated procedurally in your browser using a seeded random number generator. The algorithm fills a half-grid with weighted noise, smooths it with two passes of cellular automaton, mirrors across the vertical axis for symmetry, then adds highlights and accent details based on the subject type. Same seed + same settings always produces the same sprite, useful for sharing or coming back later. Tweak after generating. Click any pixel in the preview to cycle that cell through the five types: empty, body, highlight, shadow, accent. The palette legend below the preview shows what each one looks like. The "Reset tweaks" button restores the un-tweaked generated sprite. Note: tweaks are local to your session, share URLs encode the base seed, not your edits, so to share a tweaked sprite, download the SVG or PNG. Output is CC0. Use it however you want, no attribution required. Nothing is uploaded, generation happens entirely in your browser. Open this page on a plane, it still works. ================================================================================ # Audio toolkit URL: https://pixeldex.dev/tools/audio/ TITLE: Audio toolkit for solo game devs · Pixeldex DESCRIPTION: Every audio resource a solo dev needs to ship a game in 2026. Free SFX generators, free DAWs, CC-licensed music libraries, sound effect databases, voice tools. Honest # Audio toolkit for solo game devs Audio is the most-skipped part of indie dev and where the easiest perceived-quality wins live. This is every audio resource a solo dev needs in one page: free SFX generators, free DAWs, CC-licensed music, sound effect databases, voice tools. Honest notes on what each is best at. No affiliate links. One disclosure: one entry on this page is made by Pixeldex's maintainer; that's labeled clearly. ## If you have 60 minutes for audio Do this. In order. You'll have working SFX and a placeholder music track in your game by the end. - Open sfxr.me. Generate four sounds: jump, pickup, hurt, win. Total: ~15 minutes. - Pick one CC-BY track from incompetech.com that fits your game's vibe. ~10 minutes. - Drop them into your engine. Wire SFX to the relevant gameplay events, loop the music. ~30 minutes. - Credit the music in your game and itch description. ~5 minutes. That's it. Don't overthink audio for the prototype. Once the game feels good with these, upgrade specific pieces. ## Sound effects Generate small SFX (jump, pickup, hit, win) in seconds. All free, all CC0 or near-CC0, all browser-based unless noted. ### sfxr.me Best for: classic 8-bit / chiptune SFX. Click the preset button (Jump, Pickup, Explosion, Hit), randomize until you like it, export as WAV. Zero learning curve. ### Bfxr Best for: sfxr's bigger sibling, more parameters, more presets, better for tuning a specific sound. Browser version + downloadable Flash app. ### ChipTone Best for: a step up from sfxr/bfxr, more synthesis options, including FM and LFO. Worth it if your game has more than four SFX and you need them to sound coherent. ### Freesound.org Best for: recorded SFX (footsteps, doors, ambience) you can't easily synthesize. Massive library. Filter by license: stick to CC0 if you don't want to track attribution. ### Zapsplat Best for: high-quality recorded SFX, especially ambience and Foley. Free tier requires attribution; paid tier removes it. Quality is well above Freesound's average. ## Music Either find an existing CC-licensed track that fits, or compose your own. Both work; the time-to-quality ratio favors finding existing tracks unless you have music skills. ### Incompetech (Kevin MacLeod) Best for: the canonical free music library. Hundreds of tracks across genres, all CC-BY (just credit Kevin MacLeod in your game and link incompetech.com). Used in roughly half of all indie YouTube videos in existence, but for good reason. ### Free Music Archive Best for: a more curated alternative to Jamendo. Browse by genre, filter by license. Mostly CC-BY and CC-BY-SA. Lots of indie / experimental tracks that don't sound like every other "epic adventure" stock score. ### Jamendo Best for: bigger catalog than incompetech. Free for non-commercial use; commercial requires Jamendo's licensing tier. Read carefully before using in a paid game. ### everysong.app Best for: "I have a track in mind from a copyrighted source and I need a license-clear alternative for my game." Upload the reference track, get back 20 similar tracks from a 3,300+ commercial-safe CC catalog (Jamendo + FMA, all CC0 / CC-BY / CC-BY-SA, no BY-NC), plus 13 audio traits (BPM, key, LUFS, mood) so you can shortlist by feel. What it isn't: a music generator. It searches existing licensed tracks, doesn't synthesize new ones. Disclosure: made by Pixeldex's maintainer. Listed here because it solves the "find similar but free" problem better than the other entries on this page; if it didn't, it wouldn't be on the list. ### Bosca Ceoil Best for: composing your own simple tracks if you don't read music. Built by Terry Cavanagh (VVVVVV, Super Hexagon) for non-musicians. Click notes on a piano roll, pick instruments, export. Genuinely the lowest-friction way to make a "good enough" original track. ## DAWs and audio editors For trimming, mixing, applying effects, or actually composing. The free options handle 95% of solo dev needs. ### Audacity Best for: trimming, normalizing, removing background noise, basic effects. The standard audio editor. Not a real DAW, multitrack composition is technically possible but slow. ### Reaper Best for: a real DAW for the cost of a video game. Lifetime license, no subscription. The default upgrade path once Audacity stops fitting. Personal license is honor-system; commercial license is $225 once. ### LMMS Best for: a free DAW for tracker-style composition. Built-in synths, beat patterns, sample-based composition. The interface is dated but the output can be excellent for chiptune / electronic styles. ### FamiStudio Best for: NES / chiptune music with the actual NES sound chip emulated. If you're making a Pico-8 or NES-style game, this gets the right "feel" instantly. ## Voice and TTS For dialogue, narration, or character barks. Voice acting is expensive; TTS has gotten good enough for indie scope. ### ElevenLabs Best for: high-quality TTS for short character barks ("Got it!", "Watch out!", "Level complete"). The free tier is enough for a small game with limited dialogue. Read the commercial use terms before shipping. ### Coqui TTS (open source) Best for: running TTS locally with no usage limits, if you have a GPU and patience for setup. Quality is below ElevenLabs but acceptable for retro / robotic voices. ## In-engine implementation Most engines have decent audio APIs out of the box. Patterns for using them well. ### Pitch jitter on repeated SFX Why: playing the exact same coin-pickup SFX 20 times in 5 seconds sounds robotic. Add ±5% pitch jitter on each play and it sounds organic. Implementation example in the platformer walkthrough's AudioBus prompt. ### Crossfade between music tracks Why: hard cuts between tracks (level transition, boss start) are jarring. A 1.5-2s linear crossfade, fade old track volume out while fading new track in, is the basic dynamic music technique that elevates a prototype. ### Audio buses (master / sfx / music) Why: separate volume sliders for SFX vs music are the absolute floor of audio settings. Players notice the absence. Most engines (Unity AudioMixer, Godot AudioBus, Phaser SoundManager) make this a 10-minute setup. ## The shipping rule Audio is the cheapest perceived-quality upgrade in solo dev. Going from no audio to placeholder audio is a 10x quality jump. Going from placeholder to polished is another 1.5x. Spend the 60 minutes on placeholder before you ever skip audio entirely. ## Updates and corrections Tool prices and licensing terms change. This page is hand-verified, if you find a tool listed with stale info, that's a bug. Open an issue on Pixeldex's eventual GitHub or wait for the next refresh; "Last verified" date sits at the top of the page. ### Build a 2D platformer in a weekend Uses the SFX-jitter pattern and the AudioBus prompt referenced above. ### Cost guide for indie shipping Where audio fits in the three budget tiers. #### On this page - 60-minute path - Sound effects - Music - DAWs / editors - Voice / TTS - Implementation - The shipping rule ================================================================================ # Blog index URL: https://pixeldex.dev/blog/ TITLE: Blog · Pixeldex DESCRIPTION: Long-form posts on shipping games with Claude as your co-dev. Cost breakdowns, engine comparisons, prompt patterns, real walkthroughs from solo devs. # The Pixeldex blog Walkthroughs, cost breakdowns, engine comparisons, and honest takes on shipping games with Claude as a co-dev. Written by one person, who's built and shipped on this stack. New post every couple of weeks. ## The 5 Claude prompts every solo game dev should keep in a file Five copy-paste Claude prompts that solve the five most-recurring problems in indie game dev. Player controller. State machine. Save system. Level loader. Game-feel patch. Save them somewhere you can find them, because you'll reach for them on every project. ## How much does it actually cost to ship an indie game in 2026? A real breakdown by category: engine, art, audio, distribution, and the hidden cost of time. Three tiers, real prices, no affiliate links, and a recommendation for solo devs working on a budget that's basically zero. ### What's coming next on the blog These are being written or fact-checked right now. Bookmark and check back as each one ships. - Build a 2D platformer with Claude in a weekend, end to end - Claude vs Cursor vs ChatGPT for solo game dev: a 2026 honest take - How to stretch the free Claude tier 5x with smarter context handling - From jam build to itch page: a no-marketing release checklist - When to switch engines, and when to stop reading engine comparisons ================================================================================ # Unity engine track URL: https://pixeldex.dev/engines/unity/ TITLE: Unity · Pixeldex engine track DESCRIPTION: The most-shipped indie engine. Solid for both 2D and 3D, with a free Personal license up to $200K USD revenue. Pixeldex prioritizes Unity prompts because m # The Unity track The most-shipped indie engine. Solid for both 2D and 3D, with a free Personal license up to $200K USD revenue. Pixeldex prioritizes Unity prompts because most readers have it installed. ## ★ Recommended starter sequence If this is your first time touching UNI-CUBE, follow these in order. ### Top-down 2D player controller, grid-snapped ### Platformer controller with coyote time and jump buffer ### JSON save and load via PlayerPrefs ### Walkthrough: 2D platformer in a weekend ## Prompts (3) ### Top-down 2D player controller, grid-snapped Single C# MonoBehaviour. WASD, sprite flip, animator hooks, input buffer for snappy dashes. ### JSON save and load via PlayerPrefs Versioned save/load, migrates on schema change. Handles missing keys. ### 2D platformer with coyote time and jump buffer The "feel" details that make a platformer playable. ## Walkthroughs (1) ## Build a 2D platformer with Claude in a weekend End-to-end project guide. Every prompt included inline. Finishable. ### What's coming for UNI-CUBE - A* enemy pathfinding on a tile grid - 2D top-down zelda-like camera - UI Toolkit menu starter - Cinemachine setup for 2D ================================================================================ # Godot engine track URL: https://pixeldex.dev/engines/godot/ TITLE: Godot · Pixeldex engine track DESCRIPTION: Free, open source, lightweight. Smaller install than Unity, simpler scene model, friendlier to small projects. Picking up rapidly in the indie space. # The Godot track Free, open source, lightweight. Smaller install than Unity, simpler scene model, friendlier to small projects. Picking up rapidly in the indie space. ## ★ Recommended starter sequence If this is your first time touching GODO-BOT, follow these in order. ### Tilemap from CSV (one-shot script) ### FSM-based player controller for Godot 4 ### Godot walkthrough coming next ## Prompts (2) ### FSM-based player controller for Godot 4 Idle / Run / Jump / Fall states with clean transitions. GDScript, no plugins. ### Load a tilemap from a CSV file Parse a CSV grid into a TileMap node. Bounds-safe, comment support. ### What's coming for GODO-BOT - Branching dialogue system, JSON-driven - Top-down dungeon crawler walkthrough - Save / load with versioned migration - Resource-based item database ================================================================================ # Phaser engine track URL: https://pixeldex.dev/engines/phaser/ TITLE: Phaser · Pixeldex engine track DESCRIPTION: A JavaScript / TypeScript game framework that runs in any browser. The fastest way to ship something playable on the web, no build target hell, no platfor # The Phaser track A JavaScript / TypeScript game framework that runs in any browser. The fastest way to ship something playable on the web, no build target hell, no platform store approval. ## ★ Recommended starter sequence If this is your first time touching PHAZE, follow these in order. ### Pixel-perfect camera with deadzone follow ### Walkthrough: Phaser web game in an evening ## Prompts (1) ### Pixel-perfect camera with deadzone follow Snap to integer pixel coords. Deadzone follow with smooth lerp. TypeScript-strict. ## Walkthroughs (1) ## Ship a Phaser web game in an evening End-to-end project guide. Every prompt included inline. Finishable. ### What's coming for PHAZE - Boot / preload / main scene scaffold - A* pathfinding on a Phaser tile grid - Real save system using localStorage - Mobile touch controls ================================================================================ # LOVE2D engine track URL: https://pixeldex.dev/engines/love2d/ TITLE: LOVE2D · Pixeldex engine track DESCRIPTION: A tiny Lua framework that does 2D and audio and not much else. Beloved by jam devs because it gets out of the way. The smallest install of any engine on th # The LOVE2D track A tiny Lua framework that does 2D and audio and not much else. Beloved by jam devs because it gets out of the way. The smallest install of any engine on this list. ## ★ Recommended starter sequence If this is your first time touching LOVELING, follow these in order. ### Tile-based collision for top-down LOVE2D ### Particle system in pure Lua, no shaders ### LOVE2D walkthrough coming next ## Prompts (2) ### Tile-based collision for top-down LOVE2D Bump-style sweep test against a tile grid. Slopes, one-way platforms, push-out. ### Particle system in pure Lua, no shaders Custom emitters with lifetimes, gravity, color tween. Hit sparks and pickup glitter for free. ### What's coming for LOVELING - Save and load via .love archive bundles - Sprite animator with key poses - Top-down jam game walkthrough - Export to standalone .love bundle ================================================================================ # Pico-8 engine track URL: https://pixeldex.dev/engines/pico8/ TITLE: Pico8 · Pixeldex engine track DESCRIPTION: A # The Pico8 track A "fantasy console" with hard limits: 128x128 screen, 16 colors, 8KB RAM. Constraints make small games finishable. Pico-8 is paid ($15 one-time), the only paid tool we recommend. ## ★ Recommended starter sequence If this is your first time touching PICOMON, follow these in order. ### Walkthrough: Pico-8 puzzle game in 4 hours ### Sprite sheet loader with palette swap ## Prompts (1) ### Sprite sheet loader with palette swap Token-budget Pico-8 helper for runtime sprite recolor. Same enemy at 3 colors without doubling the sheet. ## Walkthroughs (1) ## Ship a Pico-8 puzzle game in 4 hours A complete Sokoban-style box pusher: walk on a grid, push boxes onto target tiles, advance through three levels. Token-budget conscious. Every prompt inline. ### What's coming for PICOMON - A* pathfinding with Pico-8 token budget - Tilemap collision in token-budget Lua - Pico-8 puzzle game walkthrough (4 hours) - BBS publish + cart sharing ================================================================================ # Walkthrough: Build a 2D platformer with Claude in a weekend URL: https://pixeldex.dev/walkthroughs/build-2d-platformer-with-claude-in-a-weekend TITLE: Build a 2D platformer with Claude in a weekend · Pixeldex walkthrough DESCRIPTION: A real, working 2D platformer in Unity, built end to end with Claude as your co-dev. From empty project to itch.io upload in 12 hours over a weekend. Free, no fluff, every prompt included. # Build a 2D platformer with Claude in a weekend A real, working 2D platformer in Unity, built end to end with Claude as your co-dev. From empty project to a playable game uploaded to itch.io. No fluff, no skipped steps, every prompt included. About 12 hours of focused work spread across two days. ## What you'll build A small but complete 2D platformer with: - A character that moves and jumps with real game feel (coyote time, jump buffer, variable jump height) - 3 hand-built tilemap levels - One enemy type that patrols and damages on contact - Coin pickups with a score display - A flag at the end of each level that loads the next - Sound effects for jump, pickup, and hurt - A pause menu - A WebGL build uploaded to itch.io that anyone can play in their browser Nothing is hand-waved. Every script in this guide is generated by Claude using a real prompt that you can copy. By the end, the entire game lives in a single Unity project you can keep building on. ## What you need before you start - Unity 2022.3 LTS installed (free, ~5 GB download from unity.com/download) - A free Claude account at claude.ai (the free tier is enough for this project; Pro removes the per-day cap if you marathon) - A free itch.io account (we'll publish to it on Day 2) - About 12 hours spread however suits you. The original test build was 6 hours Saturday + 6 hours Sunday with breaks. - Comfort opening Unity and dragging components onto a GameObject. We'll explain everything else. ## How to use this guide Read it sequentially. Don't skip ahead, each step's output becomes the next step's input. If something breaks, the gotchas at the end of each step have the most common fix. If a prompt doesn't return clean output the first time, paste back any errors and ask Claude to fix them. The full prompts here are tested but Claude's outputs will vary slightly run-to-run. Each step is a self-contained chunk of work with a time estimate. You can pause between any of them. ### Create the project Open Unity Hub. Click New Project. Pick the 2D Core template (NOT 3D, NOT 2D URP, keep it simple). Name it weekendplatformer. Wait for Unity to load (it will take a minute on first run). In the Project pane, create these folders so things don't end up in a chaotic flat list later: - Scripts/ - Sprites/ - Audio/ - Tiles/ - Scenes/ The default scene is called SampleScene. Rename it to Level01 and drag it into the Scenes/ folder. Save. (File → Save.) ### A placeholder character sprite You have two free options. Pick whichever is faster for you: - Use a Pixeldex sprite. Go to the sprite library, download any of the engine mascots as PNG (256 size works well), drag the file into Unity's Sprites/ folder. Unity will auto-import it as a Sprite. - Draw your own. Open Aseprite or Krita. New file, 32×32 pixels, transparent background. Sketch a humanoid blob. Export as PNG. Drag into Unity. Once the sprite is in the Project pane, drag it into the Scene view. You should see your character on a blank gray background. Don't worry about the art yet. A working blob beats a beautiful nothing. ### Movement that feels good This is the foundation. If movement feels stiff, nothing else you build will be fun. We'll use Pixeldex's coyote-time platformer controller prompt, it bakes in the three "feel" details (coyote time, jump buffer, variable jump height) that separate a playable platformer from a frustrating one. Open claude.ai/new, go to the prompt page, click Copy prompt, paste into Claude, send. Save the output as Scripts/PlatformerController.cs. Now wire it up in the scene: - Select your character GameObject. Click Add Component → Rigidbody 2D. Set Body Type to Dynamic, Gravity Scale to 3, and check Freeze Rotation Z. (No-rotation is what stops the character from tumbling on a slope.) - Add Component → Box Collider 2D. Adjust the size to roughly match the sprite. - Right-click the character in the Hierarchy → Create Empty. Name it GroundCheck. Position it at (0, -0.5, 0) relative to the character (so it sits at the bottom). - Add Component → PlatformerController (our script). Drag GroundCheck into the script's groundCheck field in the Inspector. - In the top-right of the editor, click the layer dropdown and create a new layer called Ground. Set the script's groundLayer mask to Ground. - Create a long, thin rectangle GameObject below the character to act as a temporary floor. Set its layer to Ground. Add a Box Collider 2D. Press Play. WASD or Arrow keys move you. Space jumps. Walk off the edge of the temporary floor, you should still be able to jump for ~0.1 seconds after leaving the ground. That's coyote time. Hold space briefly = short jump; hold longer = full jump. That's variable jump height. Tune until it feels right. Don't move on until movement is satisfying. The default values in the SerializeField fields are a starting point. Try speed = 7, jumpForce = 14, coyoteTime = 0.1, jumpBufferTime = 0.1. If it feels floaty, raise gravity scale to 4. Common gotcha: if the character jitters when moving, set the Rigidbody2D's Interpolation to Interpolate. If you can't jump at all, your GroundCheck is probably overlapping the Ground layer at rest, move it down by 0.1 units. ### A real tilemap level Now we turn the temporary floor into a real level. Unity's Tilemap system handles this nicely. - Right-click in Hierarchy → 2D Object → Tilemap → Rectangular. This creates a Grid + a Tilemap child. Set the Tilemap's layer to Ground. - Add a Tilemap Collider 2D component to the Tilemap. Then add a Composite Collider 2D (which auto-adds a Rigidbody2D, set its Body Type to Static). Check the Tilemap Collider's Used By Composite box. This merges all your tile colliders into one efficient shape. - Create some tile assets. Right-click in Tiles/ → Create → 2D → Tiles → Rule Tile. Or for the simplest start: drag any 32×32 PNG into Tiles/, then right-click it → Create → 2D → Tiles → Tile. Repeat for a few different colors so you have a tile palette. - Open Window → 2D → Tile Palette. Create a new palette in Tiles/Palette/. Drag your tile assets into the palette window. - With the Tilemap selected, use the brush in the Tile Palette window to paint a level. Make it small at first, 30 tiles wide, 15 tall. Leave gaps for jumping. Add a high platform that requires variable jump to reach. Press Play. Walk and jump across the level. Iterate, paint, test, paint, test. Don't worry about pretty art yet. Worry about whether the jump distances feel possible. Common gotcha: if the character falls through tiles, the Tilemap Collider isn't set up. Re-check that you added Composite Collider, set Rigidbody2D to Static, and checked Used By Composite on the Tilemap Collider. ### A goal that loads the next level Right-click in Hierarchy → Create Empty. Name it Goal. Add a Sprite Renderer with a flag-shape sprite (or any colored rectangle for now). Add a Box Collider 2D and check Is Trigger. Now we need a script that triggers a scene load when the player touches it. Send this prompt to Claude: $ Build me a Unity 2022.3+ GoalTrigger MonoBehaviour. // behavior - On OnTriggerEnter2D with a GameObject tagged "Player", load the next scene. - nextSceneName is a public string, SerializeField. - A 0.5s fade-to-black before SceneManager.LoadScene. - Use a CanvasGroup the script finds at runtime (or auto-creates if missing). // constraints - Single file, no dependencies beyond UnityEngine + UnityEngine.SceneManagement + UnityEngine.UI. - No coroutines if avoidable; use a simple float timer in Update. // return format - One file GoalTrigger.cs in a code block. - No prose before or after. Save as Scripts/GoalTrigger.cs. Attach to the Goal GameObject. Set nextSceneName to Level02. Tag your character: select it, in the Inspector click the Tag dropdown → Add Tag → create Player → assign to character. Add Level02 and Level03 scenes (Save Scene As) and add them to File → Build Settings → Scenes In Build. Otherwise SceneManager won't find them. Test: walk into the goal. Screen fades, next scene loads. (Level02 will be empty for now, that's fine, you'll paint it next time you have an hour.) ### An enemy that hurts you An enemy needs three parts: a sprite, a patrol behavior, and a damage interaction. Sprite: drag any 24×24 colored PNG into the Sprites folder, or use the PICOMON mascot from the sprite library. Drag it into the scene at a location the player can reach. Patrol behavior: send this prompt to Claude: $ Build me a Unity 2022.3+ enemy patrol controller. // shape - Single C# MonoBehaviour, EnemyPatrol.cs. - Requires Rigidbody2D (Kinematic) and BoxCollider2D. - A SerializeField float patrolDistance (default 3) and patrolSpeed (default 2). // behavior - Enemy moves left and right within patrolDistance units of its starting position. - Flips its Sprite Renderer's flipX when changing direction. - Uses Rigidbody2D.MovePosition in FixedUpdate. // damage - A separate method TakeDamage() that destroys the enemy (we'll wire this to player-jumps-on-head later). - A public int contactDamage = 1; (used by the player on collision). // return format - One file. Brief comments only. - No prose before or after. Save as Scripts/EnemyPatrol.cs. Attach to your enemy. Add Rigidbody2D (Kinematic), Box Collider 2D. Test in Play mode, enemy should patrol back and forth. Damage interaction: we need the player to take damage when they touch an enemy. Send this prompt: $ Build me a Unity 2022.3+ PlayerHealth MonoBehaviour. // shape - Single file PlayerHealth.cs. - SerializeField int maxHP = 3. - A public method TakeDamage(int amount). - A public int CurrentHP property. // behavior - On OnCollisionEnter2D with a GameObject containing an EnemyPatrol component, call TakeDamage(enemy.contactDamage) and brief invincibility for 1s. - During invincibility, flash the Sprite Renderer alpha between 1 and 0.3 at 10Hz. - On HP <= 0, reload the current scene. // constraints - No coroutines. Use a float timer in Update. - Single file. Brief comments only on the invincibility flash logic. // return format - One file PlayerHealth.cs in a code block. - No prose before or after. Save as Scripts/PlayerHealth.cs. Attach to the player. Test: walk into the enemy. Player should flash, take damage, and reload the scene if hit 3 times. Common gotcha: if nothing happens on contact, you probably need a non-Trigger collider on both objects. Trigger colliders fire OnTriggerEnter, not OnCollisionEnter. ### Coin pickups + score display Send this prompt to Claude: $ Build me two Unity 2022.3+ scripts: Coin.cs and ScoreManager.cs. // ScoreManager.cs - A singleton MonoBehaviour. Static instance. - Public method AddScore(int amount). - A public int CurrentScore property. - Updates a TextMeshProUGUI label assigned in the inspector. Format: "Score: 123". - Persists across scene loads (DontDestroyOnLoad). // Coin.cs - Requires BoxCollider2D set to Trigger. - SerializeField int value = 10. - On OnTriggerEnter2D with the player, call ScoreManager.instance.AddScore(value), play a quick scale-down animation (0.15s, lerp scale from 1 to 0), then Destroy. // constraints - Two files in two code blocks, with file paths as headers. - Coin animation: simple Update timer, no coroutines. - Brief comments only on the singleton pattern. // return format - Two code blocks, no prose before or after. Save as Scripts/Coin.cs and Scripts/ScoreManager.cs. Set up the score UI: - Right-click Hierarchy → UI → Canvas. (Unity will add an EventSystem too.) - Right-click the Canvas → UI → Text - TextMeshPro. Pop up appears asking to import TMP Essentials, accept. - Position the text in the top-left corner. Default text "Score: 0". - Create an empty GameObject called ScoreManager. Attach ScoreManager.cs. Drag the TextMeshPro text into the script's label field. Create coin GameObjects: drag a coin sprite into the scene, add Box Collider 2D (Is Trigger), attach Coin.cs. Duplicate (Cmd+D / Ctrl+D) and place 10 around the level. Test. Coins should disappear with a scale-down when collected, score should increment. ### Sound effects + screen shake Game feel comes from juice. Two cheap upgrades give you most of it. Free sound effects: head to sfxr.me (more options on the audio toolkit page) (free, in-browser, CC0). Generate three SFX: - Jump (use the "Jump" preset, randomize until you like one) - Coin pickup (use the "Pickup/Coin" preset) - Hurt (use the "Hit/Hurt" preset) Download each as WAV. Drag into Audio/. Send this prompt to Claude: $ Build me a Unity 2022.3+ AudioBus singleton. // shape - Single file AudioBus.cs. - Static instance, DontDestroyOnLoad. - An AudioSource component (auto-add in Awake). - A public method PlayOneShot(AudioClip clip, float volume = 1). - SerializeField AudioClip references: jumpClip, coinClip, hurtClip. - Convenience methods: PlayJump(), PlayCoin(), PlayHurt() that wrap PlayOneShot with a small pitch jitter (+- 0.05) so identical SFX don't sound mechanical when triggered rapidly. // constraints - Single file. Brief comments only on the pitch jitter logic. // return format - One file AudioBus.cs in a code block. - No prose before or after. Create an empty GameObject called AudioBus, attach the script, drag in the clips. Now from your other scripts, call AudioBus.instance.PlayJump() in the jump method, PlayCoin() in the coin script, PlayHurt() in PlayerHealth. Screen shake on hit: send this prompt: $ Build me a Unity 2022.3+ ScreenShake MonoBehaviour. // shape - Attach to the Main Camera. - Static method ScreenShake.Trigger(float duration, float magnitude). - Stores the camera's resting position on Awake. // behavior - For 'duration' seconds, jitter the camera position by Random.insideUnitCircle * magnitude each frame. - Snap back to resting position when done. // constraints - Single file. No coroutines. // return format - One file ScreenShake.cs in a code block. - No prose before or after. Attach to Main Camera. From PlayerHealth's TakeDamage method, call ScreenShake.Trigger(0.2f, 0.15f). Damage now feels weighty. ### A pause menu Send this prompt: $ Build me a Unity 2022.3+ PauseMenu MonoBehaviour. // shape - Attach to a Canvas with a child Panel containing two Buttons: Resume, Quit-to-Title. - SerializeField references to: pausePanel (GameObject), resumeButton, quitButton. // behavior - Press Escape to toggle pausePanel and Time.timeScale (1 / 0). - Resume button hides the panel and sets Time.timeScale = 1. - Quit button loads scene "Title" with timeScale reset to 1. - On scene load, ensures the panel starts hidden and timeScale = 1. // constraints - Single file. No coroutines. // return format - One file PauseMenu.cs in a code block. - No prose before or after. In the scene: Right-click Canvas → UI → Panel. Add two TextMeshPro buttons inside: Resume, Quit. Style them to taste. Attach PauseMenu.cs to the Canvas, wire the references. Test: press Escape mid-game. Game pauses, panel appears. Press again to resume. (For "Title" scene, just Save Scene As → Title with a single TMP text saying "WeekendPlatformer · Press Space to start" and a script that loads Level01 on Space.) ### Build and ship to itch.io Build to WebGL: - File → Build Settings. Add all your scenes (Title, Level01, Level02, Level03) in order. - Switch platform to WebGL. (First time will install the WebGL module if you didn't earlier, about 2 GB download.) - Player Settings (button at bottom): set Compression Format to Disabled (itch.io doesn't serve compressed builds well by default). Set Resolution to 960×540. - Click Build. Save to a folder called Build/. Wait ~5 minutes. Upload to itch.io: - Zip the entire Build folder. - itch.io → Upload new project. Name it. Set Kind of project to HTML. Pricing: Free (or "no payments"). - Upload your zip. Check This file will be played in the browser. Set the embed dimensions to 960×540. - Add a screenshot (just take a Cmd+Shift+4 of your game running in the editor). - Save and view page. Test by playing in the browser. Your game is live on the internet. Share the URL on r/gamedev, in your Discord, with three friends. ## What to do next You now have a foundation. Things to add when you have another evening or weekend: - Save and load. Use the Unity JSON save / load prompt to persist score across sessions. - More enemy types. The EnemyPatrol script is a starting pattern. Make a JumpingEnemy, ShootingEnemy, BossEnemy by copying and modifying. - A proper level select. List all the levels with stars based on coins collected. - Better art. Now that the game is fun, replace the placeholder sprites. Use the sprite spec builder to plan multi-directional character sprites if you want to expand to top-down. - Music. incompetech.com has free CC-BY tracks. Drop one into Audio/ and play it in a single AudioSource on the Main Camera. - Submit it to a game jam. itch.io is the home of game jams. The friction to enter one is "you have a playable game on itch." You do. ## Why this works Three things make this 12-hour walkthrough actually finish-able: - Scope is locked. One enemy type. One pickup type. One goal type. Three short levels. The scope of "what counts as done" is tiny on purpose. Most solo platformer attempts die because scope creeps. - Claude does the boilerplate. You're not staring at a blank script wondering how to write a state machine. You're reading Claude's output and tweaking. The cognitive load is review, not generation. - Movement comes first. If movement feels good, everything else is decoration. Step 3 takes 60 minutes on purpose. Don't skimp. ## License + sharing This walkthrough is CC0. Copy from it, fork it, sell something built with it. Same for the prompt outputs Claude returned, they're yours. If you ship something with this guide, a link back to pixeldex.dev in your itch description helps the next solo dev find this. No requirement, just appreciated. > If we shut down Pixeldex one day, all of this, guides, prompts, sprites, the spec builder, goes open source. The promise on every page applies to this walkthrough too. ### Browse all prompts Every prompt used in this walkthrough plus more, all standalone. ### Sprite spec builder If you want better art for your platformer, use this to spec it out for an AI image tool. #### This walkthrough - What you'll build - What you need - How to use it - ⎯⎯ Day 1 ⎯⎯ - 01 · Project - 02 · Sprite - 03 · Movement - 04 · Tilemap - 05 · Goal - ⎯⎯ Day 2 ⎯⎯ - 06 · Enemy - 07 · Coins - 08 · Sound - 09 · Pause - 10 · Ship - What's next - Why this works ================================================================================ # Walkthrough: Ship a Phaser web game in an evening URL: https://pixeldex.dev/walkthroughs/ship-a-phaser-web-game-in-an-evening TITLE: Ship a Phaser web game in an evening · Pixeldex walkthrough DESCRIPTION: A working Phaser 3 / TypeScript arcade dodger game, built and shipped to itch.io in about 4 hours. Every prompt included. Free toolchain, browser-deployable, embeddable on your own site. # Ship a Phaser web game in an evening A working arcade dodger in Phaser 3 / TypeScript. Move left and right, dodge falling debris, collect coins, watch your score climb until something hits you. Built and uploaded to itch.io as a playable web embed in about 4 hours. Every prompt included, no skipped parts. ## What you'll build A short arcade dodger game. The kind of thing you'd bookmark for a 5-minute coffee break, not a 50-hour campaign. By the end you'll have: - A player ship that moves left/right with arrow keys - Obstacles that fall from the top at increasing speed - Coins that fall and award points when collected - A score HUD that updates as you play - A "you died" screen with a one-key restart - Sound effects for pickup and collision - The game embedded as a playable web build on itch.io The whole thing fits in about 250 lines of TypeScript across 3 scenes (Boot, Main, GameOver). Every line of code is generated by Claude using a real prompt you can copy. ## What you need before you start - Node.js 18+ installed (free, nodejs.org) - A code editor (VS Code is fine, free) - A free Claude account - A free itch.io account - Roughly 4 hours, can be one evening ## How to use this guide Read sequentially. Don't skip ahead. The 4 hours are 4 hour-long blocks; you can pause between any of them. Each block has a single prompt and a clear deliverable. By Hour 4 you have a shipped game URL. ### Project scaffold and Phaser hello world Open a terminal in a fresh folder. Run: $ npm create vite@latest dodger -- --template vanilla-ts $ cd dodger $ npm install phaser $ npm run dev Vite gives you instant hot reload. Open http://localhost:5173. You'll see Vite's default page. We'll replace its content next. Now use Pixeldex's pixel-perfect camera prompt as a reference for Phaser+TS structure, then send this scaffold prompt to Claude: $ Build me a Phaser 3.70+ TypeScript scaffold for an arcade dodger game. // shape - Three scenes: BootScene, MainScene, GameOverScene. - Game config: 320x480 logical resolution, scale Phaser.Scale.FIT, autoCenter. - BootScene generates colored rect Texture2Ds at runtime for: player (green 24x16), obstacle (red 20x20), coin (yellow 14x14). Use this.textures.generate or this.add.graphics + generateTexture. No external assets. - MainScene draws a starfield background (30 tiny white pixels at random positions, rendered via this.add.graphics). // behavior - BootScene immediately starts MainScene after generating textures. - MainScene shows the player at the bottom-center, no movement yet. - GameOverScene shows a "GAME OVER" text + "Press SPACE to restart" + final score (passed via scene data). // constraints - TypeScript strict mode. No any, no //@ts-ignore. - One file per scene (boot.ts, main.ts, gameover.ts) plus main.ts entry that creates the game. - Use a single shared CONSTANTS object (export const) for: WIDTH, HEIGHT, PLAYER_Y. // return format - Four files in separate code blocks: boot.ts, main.ts (scene), gameover.ts, index.ts (entry). - A snippet showing what to put in index.html. - No prose before or after. Save each file in src/. Update index.html to match. Reload, you should see a black starfield with a green rectangle (the player) at the bottom. End of Hour 1: a Phaser game running with three scenes wired up. ### Player movement and falling obstacles Send this prompt: $ Extend MainScene to add player movement and falling obstacles. // player - Create the player sprite at (CONSTANTS.WIDTH / 2, CONSTANTS.PLAYER_Y). - Arrow keys move it left/right at 220 px/s. Clamp to screen bounds. - Read input via this.input.keyboard.createCursorKeys(). // obstacles - A Phaser group of obstacles at this.obstacles. - Spawn one obstacle every 700ms via a Phaser timer event. - Spawn position: random x in [10, WIDTH-10], y = -20. - Each obstacle moves down at 160 px/s. Destroy it when y > HEIGHT + 20. // collision - this.physics.overlap(player, obstacles, () => this.scene.start('GameOverScene', { score: this.score })) - For now, this.score = 0; we'll increment in the next step. // constraints - Use Phaser arcade physics. Add this.physics.world.setBounds. - All numbers (spawn rate, fall speed, etc.) as named constants at the top of MainScene. // return format - One updated main.ts file in a code block. - No prose before or after. Reload. Use the arrows to dodge the falling red rectangles. When one hits you, you flip to the GameOver scene. End of Hour 2: the core gameplay loop is alive. ### Coins, score HUD, and difficulty ramp $ Extend MainScene with coins, a score HUD, and a difficulty ramp. // coins - A separate group this.coins. - Spawn one coin every 1100ms (use a separate timer from obstacles). - Coins fall at 120 px/s. - this.physics.overlap(player, coins, (p, c) => { c.destroy(); this.score += 10; }) // score HUD - A Phaser text object at (8, 8) showing "Score: 0". - Updates every frame from this.score. - Use Phaser's built-in font (no need to load). - Style: 14px monospace, white. // difficulty - Every 10 seconds, increase obstacle fall speed by 20px/s and decrease spawn delay by 50ms (clamp delay to 200ms minimum). - Use a this.time.addEvent loop with delay 10000 and loop true. // game over - When transitioning to GameOverScene, pass { score: this.score } as scene data. - GameOverScene displays the final score below "GAME OVER". // return format - Updated main.ts and gameover.ts in two code blocks. - No prose before or after. Reload. Now you collect coins, score climbs, the game gets harder over time. The GameOver screen shows your final score. End of Hour 3: a real game with difficulty curve. ### Sound, polish, and ship to itch.io Sound: grab two free CC0 SFX from sfxr.me (more options on the audio toolkit page), one "pickup/coin" and one "explosion/hit." Save in public/sounds/ as coin.wav and hit.wav. Send this prompt: $ Add sound, screen flash, and a build step. // audio - BootScene preloads /sounds/coin.wav and /sounds/hit.wav via this.load.audio. - MainScene plays this.sound.play('coin') on coin pickup, 'hit' on collision. - Add a small pitch jitter (+- 0.05) on coin so identical SFX don't sound mechanical. // screen flash on hit - On collision, before transitioning to GameOver, run this.cameras.main.flash(200, 255, 100, 100) and delay scene transition by 300ms. // vite build for itch.io - Add a build script step. The output should go to dist/ and use relative paths (./assets/...) so itch.io can serve it as a zipped folder. - In vite.config.ts: base: './'. // return format - Updated boot.ts, main.ts, vite.config.ts in code blocks. - No prose before or after. Run npm run build. You get a dist/ folder. Test it locally: cd dist && python3 -m http.server 8000, open localhost:8000, game should run. Upload to itch.io: - Zip the entire dist/ folder. - itch.io → Upload new project. Name it "Dodger" (or whatever). Kind: HTML. Pricing: free. - Upload the zip. Check This file will be played in browser. Set viewport: 320x480 (or 640x960 for embedded display). - Save and view. Game should run in browser. Share the URL. ## What to do next - Add a high-score system. Use the JSON save prompt approach but in localStorage instead of PlayerPrefs. - Better art. Replace the colored rectangles with real sprites. Use the sprite spec builder to plan multi-directional ship art. - More obstacle types. A homing seeker, a faster zig-zagger, etc. Each is one new sprite + one new behavior method. - Mobile controls. Add this.input.on('pointermove') for touch dragging the player. Phaser handles the mobile event mapping for you. - Submit to a game jam. Phaser games are jam favorites because they run anywhere. ## Why this works Three reasons this 4-hour walkthrough actually finishes: - The web is forgiving. No build target hell, no platform store approval, no App Store review. Zip + upload + done. - Phaser hides the boilerplate. No window/canvas setup, no game loop you write by hand. Scene + sprites + arcade physics is enough. - Scope is locked. One enemy type. One pickup. One difficulty curve. No menus, no levels, no save system. Three or four hours is exactly enough for this scope. ## License + sharing This walkthrough is CC0. The Claude prompts are CC0. The output Claude returns is yours. If you ship a game with this guide, link to pixeldex.dev in your itch description so the next solo dev can find it. ### Build a 2D platformer with Claude in a weekend A bigger walkthrough if you want a longer-form project. ### Pixel-perfect camera with deadzone follow Add this if you want sprite art that doesn't sub-pixel jitter. #### This walkthrough - What you'll build - What you need - ⎯⎯ The 4 hours ⎯⎯ - 01 · Scaffold - 02 · Movement - 03 · Score + difficulty - 04 · Polish + ship - What's next - Why this works ================================================================================ # Walkthrough: Ship a Pico-8 puzzle game in 4 hours URL: https://pixeldex.dev/walkthroughs/ship-a-pico8-puzzle-game-in-4-hours TITLE: Ship a Pico-8 puzzle game in 4 hours · Pixeldex walkthrough DESCRIPTION: A complete Sokoban-style puzzle game built in Pico-8 with Claude as co-dev, in 4 hours. Three levels, win + restart, sound. Token-budget conscious. Every prompt included. # Ship a Pico-8 puzzle game in 4 hours A complete Sokoban-style box pusher in Pico-8: walk on a grid, push boxes onto target tiles, advance through three levels, hear a satisfying chime when you win. Built with Claude as co-dev in about 4 hours of focused work. Token-budget conscious, every prompt inline. ## What you'll build - A grid-based Sokoban-style puzzle game - 4 sprite types: player, box, wall, target - Player moves one tile at a time with arrow keys - Push a box onto a target to "complete" it - When all targets are completed, advance to the next level - 3 hand-authored levels of increasing difficulty - Move counter + level display in the HUD - A clear "you won" screen with restart - Sound effects on push, target-hit, and level complete Total ~150 lines of Pico-8 Lua. The whole thing fits comfortably in Pico-8's token budget. ## What you need - Pico-8 ($15 one-time, includes the editor and sprite/sound tools) - A free Claude account - ~4 hours, doable in one sitting ## How to use this guide Pico-8 has its own integrated editor. We'll write Lua in there, draw the sprites in Pico-8's sprite editor, and stay inside the Pico-8 environment for everything except the Claude prompts. Each step has a single Claude prompt and a deliverable. ### Sprites and grid renderer Open Pico-8. ESC to flip between code and sprite editor. Press F4 to enter the sprite editor. Draw 4 sprites in the first 4 slots (sprite indices 1, 2, 3, 4): - Sprite 1: player. A simple 8×8 character. Color suggestion: green (color 11) on transparent. - Sprite 2: wall. A solid block with subtle texture. Purple (color 2) is good. - Sprite 3: box. Wood-tone block. Orange/brown (color 9 or 4). - Sprite 4: target. An empty outlined square or X marker. Mint/cyan (color 11 or 12). Make sprite 1 (the player) have transparent background, color 0 is the default Pico-8 transparent. Now ESC back to the code editor and send Claude: $ Build me a Pico-8 grid-based puzzle game scaffold. // shape - The level is a 2D table 'grid' where each cell is one of: 0 (empty), 2 (wall), 3 (box), 4 (target). - Player position is stored as (px, py) tile coordinates, separate from the grid. - Grid is 10 wide x 8 tall, drawn at offset (24, 16) so it's centered. // _init - Define a small starter level as a table of strings (e.g. "##########", "#.....p..#", etc) where # = wall, p = player, b = box, t = target, . = empty. - Parse it into the grid + (px, py). // _draw - cls(0) for black background. - Draw HUD at top: "LV 01" left, "M:0" right (move counter, starts at 0). - For each grid cell, call spr() with the appropriate sprite index at the cell's pixel position. - Draw the player sprite at (px, py) in pixels. // _update - Empty for now (we'll add input next hour). // constraints - Single Pico-8 Lua block. Keep under 200 tokens for the scaffold. - No globals beyond grid, px, py, level, moves. // return format - One .p8 lua block of code. - A separate small block showing the starter level string table. - No prose before or after. Paste into Pico-8's code editor. Ctrl+R to run. You should see your sprites laid out as a grid, walls around the edge, the player somewhere inside, maybe a box and a target. End of Hour 1: a static level renders with all four sprite types. ### Player movement on the grid Send this prompt: $ Extend _update to handle grid-based player movement. // movement - On btnp(0) (left) / btnp(1) (right) / btnp(2) (up) / btnp(3) (down), attempt to move the player one tile in that direction. - Compute target_x, target_y for the destination. - If grid[target_y][target_x] is a wall, block the move. - If the destination is empty (or a target tile, since target is walkable), accept the move and increment moves. - If the destination has a box, check the cell beyond the box. If THAT cell is empty (or a target), push the box: clear the box's old position, place box at the new position, advance player. Increment moves. Else, block the move. // constraints - Single _update function. No coroutines. - Use btnp (button press, fires once per press) not btn (held). - Keep token cost low. // return format - Updated _update function only, in a code block. - No prose before or after. Replace your _update. Run. Arrow keys should move the player one tile at a time, blocked by walls. Walking into a box pushes it (if there's space behind). End of Hour 2: a working playable Sokoban-style mover. ### Targets, win condition, and 3 levels Send this: $ Add targets, a win condition, and three levels. // targets - The grid stores tiles as a number per cell. Targets must persist when a box is on top of them. - Refactor: each cell has TWO layers, base (empty / wall / target) and top (box / nothing). Use two parallel grids: base[y][x] and top[y][x]. - Player walks on base, can push tops if base behind is walkable and top behind is nil. - A box ON a target = box visually highlighted. Use spr() for the box but draw a thin mint outline behind it via rectfill or similar. // win condition - After each move, count: do all base[y][x] == TARGET cells have top[y][x] == BOX? - If yes, transition to a "level complete" state: brief flash, advance to next level after 1s. // 3 levels - Define LEVELS = { L1, L2, L3 }, each a table of strings. - L1: trivial (1 box, 1 target, 4 moves). - L2: 2 boxes, 2 targets, requires planning. - L3: 3 boxes + a corridor that traps you if you push wrong. - A level_index variable tracks current level. // level transition - On level complete, show "LEVEL CLEAR" centered for 1s, then load the next level. - After L3, show "YOU WIN, Z TO RESTART" until btnp(4) is pressed. // constraints - Refactor minimally, keep the same _init/_update/_draw structure. - Token budget still under 800 total. // return format - Updated full Pico-8 Lua block in one code block. - No prose before or after. Paste, run. You should now have three levels with increasing complexity. Solving L1 advances you to L2, etc. Solving L3 shows the win screen. End of Hour 3: a complete game loop. ### Sound + ship Pico-8's built-in sound editor (F2) lets you compose chiptunes. For our puzzle game we just need three SFX: - SFX 0: a soft "click" for player movement (use the noise instrument, single short note) - SFX 1: a "thud" for box push (slightly lower pitch, also short) - SFX 2: a "ding" arpeggio for target-completion (3-4 ascending notes) - SFX 3: a longer chord for level-clear (5+ notes, mixed instruments) Authoring SFX in Pico-8 is fast, pick the instrument, click notes on the piano roll, hit play to test. ~15 minutes for all four if you're not picky. Then send Claude: $ Wire up SFX into the puzzle game. // triggers - On player move (no box involved): sfx(0). - On box push: sfx(1). - When pushing a box onto a target: sfx(2) (in addition to sfx(1)). - On level complete: sfx(3). // constraints - Add the sfx calls inline in the existing movement logic. Don't refactor. // return format - Just the changed lines, with line context (e.g. "in the 'box push' branch, after updating top[ty][tx], add sfx(1) and conditionally sfx(2)"). - Or the full updated _update function if cleaner. - No prose before or after. Apply, run, push a box onto a target. You should hear it. To export and share: - In Pico-8, SAVE puzzle.p8 in the editor (saves your cart). - EXPORT puzzle.html to make a web-playable HTML build. - Pico-8 also generates a label image, set one with F7 while playing on a frame you like. - Upload puzzle.p8 to the Pico-8 BBS (lexaloffle.com/bbs) for the Pico-8 community, or zip the HTML build and upload to itch.io. ## What to do next - Add an undo button. Push a snapshot of (px, py, top grid) before each move; pop it on Z. Reframes the game from "memorize the right moves" to "experiment freely." - Use the palette swap prompt to recolor the boxes per level for variety. - Save best-move counts per level using Pico-8's cartdata() persistence. - More levels. The hand-built level format means each new level is one new entry in LEVELS. - Submit to a Pico-8 jam. Pico-8 jams happen constantly, every month or so. The barrier to entry is "you have a finished cart." You do. ## Why this works - Pico-8's constraints are the gameplay. 128x128, 16 colors, integer-grid movement, these aren't limitations to fight, they're the game's vibe. Sokoban-on-Pico-8 looks right because it's already low-resolution and grid-based. - The 4-hour scope means 3 levels. Not 30. Not 100. Three. You hand-author them like you'd hand-author a song's verses, and that's the right scope for this format. - The Claude prompt asks for token-budget code. Pico-8's hard token limit makes terse code a real constraint, and Claude responds well to "keep it under N tokens." ## License + sharing Walkthrough is CC0. Prompts are CC0. The cart you make is yours. If you publish on the Pico-8 BBS, a link to pixeldex.dev in your cart description helps the next solo dev find this. No requirement. ### Ship a Phaser web game in an evening Same time scope, different engine, different game type. ### Sprite sheet loader with palette swap Recolor your puzzle boxes without doubling the sprite sheet. #### This walkthrough - What you'll build - What you need - ⎯⎯ The 4 hours ⎯⎯ - 01 · Sprites + grid - 02 · Movement - 03 · Targets + 3 levels - 04 · Sound + ship - What's next - Why this works ================================================================================ # Blog: How much does it cost to ship an indie game in 2026? URL: https://pixeldex.dev/blog/cost-of-shipping-indie-game-2026 TITLE: How much does it cost to ship an indie game in 2026? · Pixeldex DESCRIPTION: A real cost breakdown for shipping an indie game in 2026. Three tiers ($0, ~$20/mo, ~$100/mo), real prices verified May 2026, by category: engine, art, audio, distribution, AI tools. # How much does it actually cost to ship an indie game in 2026? A real breakdown by category. Three budget tiers, real prices verified in May 2026, no affiliate links, no sponsored picks. If you're a solo dev wondering whether you can ship something on a budget that's basically zero, the answer is yes, and here's the math. ## The short answer Shipping an indie game in 2026 costs somewhere between $0 and $200 a month, depending on how much of your toolchain you upgrade out of the free tier. The dollar number you actually see depends almost entirely on three categories: your AI assistant, your art tool, and whether you need Unity Pro (you almost certainly don't). The category most solo devs underestimate is time. Every free tool costs more time per task than the paid one in the same category. If you're racing a deadline, $20 a month buys you back hours that would otherwise vanish into wrestling with the free tool. If you're learning and have time but no money, the free tools will get you there. ## The cost categories Every shipped indie game involves spend in some combination of these: - Game engine, Unity, Godot, Phaser, LOVE2D, Pico-8, Unreal. - Code editor + AI, VS Code, JetBrains Rider, Cursor; plus Claude / ChatGPT / Gemini if you use one. - Art, sprite editor, illustration, 3D modeling. - Audio, DAW for music, SFX library or generator. - Distribution, itch.io, Steam, mobile stores. - Marketing, landing page hosting, email tool, screenshot/video software. - Hosting, server-side multiplayer, leaderboards, analytics. For a solo dev shipping a singleplayer 2D game, the last two are usually free or near-free. The first five are where every dollar goes. ## Tier 1, The genuinely $0 stack Yes, you can really ship a game for nothing. Here's the full stack: This is not a hypothetical. It's the stack used by most jam games, most students learning, and a non-trivial number of shipped commercial titles. Godot and Unity Personal are both fully featured for solo-dev needs. Krita is a real digital painting tool. Audacity is the standard audio editor for a generation of YouTubers. itch.io is a legitimate storefront where small games regularly do five-figure revenue. The only thing the $0 stack costs you is some time: each free tool is a little slower per task than the paid alternative in the same category. We'll come back to that. ## Tier 2, Small upgrades that matter If you have a small budget and want to spend it well, here are the upgrades that move the needle, in priority order: - Claude Pro, $20 a month. The single biggest leverage upgrade. Free Claude has usage limits that hit hardest exactly when you're in flow on a hard problem. Pro removes that bottleneck for ~95% of solo dev sessions. If you only buy one thing, buy this. - Aseprite, $20 once (not a subscription). If you're doing pixel art, this is the tool. One-time purchase, no monthly fee, lasts forever. The free LibreSprite alternative works but is meaningfully clunkier on animation. - Reaper, $60 once (personal license). A real DAW. Lifetime license, no subscription. Drops a ceiling that Audacity has if you start composing original music or doing serious mixing. Total: $20 a month recurring + $80 one-time, and that gets you 80% of the value of a $200/month stack. itch.io stays free, the engine stays free, the editor stays free. ## Tier 3, The "I'm trying to make this commercial" stack Beyond Tier 2, costs balloon fast and the marginal return on each dollar drops. You'd only enter this tier when something specific is blocking you, not because you assume "more expensive = better." The biggest mistake here is paying for tools before you have a game that benefits from them. Steam Direct's $100 is the one cost that's unavoidable if you ship on Steam, but everything else in this tier should be paid for reactively, not proactively. ## The hidden cost: time Free tools are not free. They cost time per task instead of dollars per month. Some examples: - Animation in Krita vs Aseprite. Aseprite has onion-skinning, frame tagging, and a tile mode that makes 32×32 sprite cycles take five minutes. Doing the same in Krita is more like fifteen. - Music in Audacity vs Reaper. Multitrack composition is technically possible in Audacity, but every step takes longer than it should. Reaper's MIDI piano roll is a real piano roll. - Free Claude vs Pro. Hitting a usage cap mid-feature and having to wait two hours costs more than $20 worth of attention loss, every time it happens. The math is roughly: if you're shipping for income, time is more valuable than the upgrade cost almost immediately. If you're shipping as a hobby with no income riding on it, the free tools are doing exactly what they're designed to do. ## A note on Claude, specifically Pixeldex is opinionated about Claude as a co-dev, so worth being explicit: - Claude free tier is usually enough for evening work on a small project. You'll hit limits if you have a marathon Saturday and try to refactor a whole system in one go. - Claude Pro at $20 a month is the difference between "ran out of messages mid-feature, came back tomorrow" and "actually finished the feature today." It's the single best $20 a solo dev can spend on tools per month. - Claude Code is included with Pro at no extra cost and makes refactoring across multiple files dramatically faster. It uses your message budget faster than chat does, but the per-task savings outweigh that. If you have to choose between Claude Pro and any other paid tool in this article, choose Claude Pro. ## My recommendation, if this is your first game - Start at Tier 1, full $0. Don't pay for anything until you've finished and shipped at least one game, however small. The act of shipping is more valuable than the marginal speed of any paid tool. - If you're doing pixel art, buy Aseprite once, lifetime. $20, never again. - Once you're past your first jam build, upgrade Claude. $20 a month, cancel any month you're not actively building. - Steam Direct's $100 is the only cost you can't avoid if you ship on Steam. Save it for game two. - Everything else, wait. Adobe, Unity Pro, premium asset packs, fancy DAWs, none of these unlock shipping. They marginally speed up specific tasks. Solve those tasks with the free tool first, and you'll know exactly which upgrade is worth paying for. ## Last thought Tools don't ship games. People do. Keep your costs tight enough to keep going, because the only thing that actually matters is whether you're still working on the game six months from now. "I can't afford the right tools" is almost never the real blocker for a solo indie. Almost every commercial indie hit started out being built on the free tier of something. Yours can too. > If we shut down Pixeldex one day, the code goes open source. The promise on every page of this site applies to this article too: nothing here is hidden behind a future paywall. If you found this useful, share it, copy from it, build something with it. ## Related Want a copy-paste prompt to start your first game today? The Unity top-down player controller prompt takes about two minutes to run and gives you a working character. The Godot FSM controller prompt is the next step up if you want a cleaner architecture from day one. Both are free, no email gate. For the audio side of the budget, every SFX generator, free DAW, and CC music library worth knowing about, see the audio toolkit page. ### All prompts 6 prompts shipped, more arriving weekly. Filter by engine and difficulty. ### Back to Pixeldex home Pick an engine track, browse the full catalog, see what's coming next. #### On this page - Short answer - Cost categories - Tier 1 · $0 - Tier 2 · $20/mo - Tier 3 · $100+ - Hidden cost: time - On Claude - Recommendation - Last thought ================================================================================ # Blog: The 5 Claude prompts every solo game dev should keep in a file URL: https://pixeldex.dev/blog/5-claude-prompts-every-solo-game-dev TITLE: The 5 Claude prompts every solo game dev should keep in a file · Pixeldex DESCRIPTION: Five copy-paste Claude prompts that every solo game dev should have ready: the player controller, the FSM, the save system, the level loader, and the polish patch. With links to the full prompts and what each one is best at. # The 5 Claude prompts every solo game dev should keep in a file Five copy-paste Claude prompts that solve the five most-recurring problems in indie game dev. Player controller. State machine. Save system. Level loader. Game-feel patch. Save them somewhere you can find them, because you'll reach for them on every project. ## Why these five Every game ever made by a solo indie has needed roughly the same scaffolding: a character that moves well, structure as that character grows, persistence between runs, levels described as data, and the small "feel" patches that turn a tech demo into a game. These five prompts cover all five. You'll change engines. You'll switch genres. The shape of the problems stays the same. The prompts below are tested in real projects and are shaped to return drop-in code that does one thing well, with no fluff. ## The drop-in player controller Use it for: the first 30 minutes of every new project. You need a character moving on screen so you can verify your scene is set up before you build anything else. Why this version is good: it bakes in the small details most beginner tutorials skip, normalized diagonal movement so diagonals don't speed-cheese, an input buffer so a keypress at the edge of a frame still registers, proper Update vs FixedUpdate separation so the character doesn't stutter at low frame rates. It's the controller you'd actually keep in a real project, not a stripped-down demo you have to rewrite the moment you add real gameplay. Get it: Top-down 2D player controller, grid-snapped. ~2 minutes to run. Single C# MonoBehaviour, no packages. If your game is a platformer, swap it for the platformer variant with coyote time and jump buffer, same shape, more "feel." ## The state machine you'll wish you'd started with Use it for: the moment your player controller has 3+ states (idle, walk, jump, dash, hurt) and your Update method is starting to look like a 200-line if-else stack. That's the signal to move to a finite state machine. Why this version is good: it splits each state into its own file, with a base class that defines enter / exit / update. The Player script just holds the current state and calls its methods each frame. Adding a new state means writing one new file and adding one transition line, not unscrambling 200 lines. Most "FSM tutorials" are written for OOP textbooks, not games. The pattern Pixeldex uses is the same one most mid-to-large indie Godot games actually ship with. Easy to read, easy to extend, easy to debug. Get it: FSM-based player controller for Godot 4. ~5 minutes to run. The pattern ports cleanly back to Unity if that's your engine. ## The save system that doesn't break next year Use it for: the moment you have anything you want to persist between play sessions, score, current level, settings, unlocked items. Why this version is good: it has versioned migration baked in from the start. Most save-system tutorials skip this; they show you how to write a JSON file and call it done. Then six months later you add a new field, your existing players load the game, and their saves become corrupted because the deserializer can't handle the missing field. This prompt's output handles missing keys gracefully, logs a warning instead of crashing on bad data, and includes a SCHEMA_VERSION constant so all you do when you change the schema is bump a number. It's the difference between "this works for the demo" and "this works for the patch you ship in 2027." Get it: JSON save and load via PlayerPrefs (Unity). ~4 minutes to run. The pattern is identical for any engine, only the storage call changes. ## The level loader that lets you edit in a spreadsheet Use it for: the second your levels start feeling samey because you're hand-painting each one in the engine's tile editor. Switching to data-driven levels, CSVs, JSON, or anything you can edit in a text file, makes iteration roughly 10x faster. Why this version is good: it parses CSV with comments, handles missing tile IDs gracefully (warns instead of crashing), and puts everything in one runtime script. No build pipeline, no special editor extension. You drop a CSV in the project and the script loads it on Play. The bigger win: once levels are CSVs, you can edit them in Google Sheets or Numbers, share them with collaborators by paste-link, and even auto-generate them from procedural code. Your level format becomes the seam where humans and code meet. Get it: Load a tilemap from a CSV file (Godot 4). ~3 minutes to run. Works in any engine that has a tilemap concept. ## The game-feel patch Use it for: the moment your prototype runs but feels stiff. The character moves, the levels load, the game loop closes, but something feels off and you can't name what. Why this version is good: the answer is almost always one of three things, coyote time (you can still jump for a fraction of a second after walking off a ledge), jump buffer (a jump press just before landing still triggers the jump on landing), and variable jump height (holding the button gives a longer jump, tapping gives a short one). These three are the floor of "a platformer that feels good," and most beginner tutorials skip all of them because they're not strictly required for the character to move. Adding all three is roughly 30 lines of code. Doing it correctly is harder than it looks, there are common bugs (jumps register twice, coyote timer never decrements, variable jump cut feels too aggressive). The prompt includes the full implementation plus a "what good output looks like" checklist for catching those. Get it: Unity 2D platformer with coyote time and jump buffer. ~3 minutes to run. ## How to use this list Save these five prompts in a markdown file in your dotfiles, your Notion, your Obsidian, wherever you keep snippets. Don't memorize them, that's the wrong cognitive load. Just know that they exist and where they are. When you start a new project: - Run prompt #1 to get a character moving in 30 minutes. - If you start adding states, switch to prompt #2 before your Update hits 100 lines. - Run prompt #3 the moment you have anything worth saving. - Run prompt #4 the second you wish you could edit a level outside the engine. - Run prompt #5 when the prototype works but feels stiff. Each prompt is a finished, tested, opinionated piece of code. Together, they cover most of the scaffolding work in a small game project. The remaining 90% is the actual game, the part that makes it interesting, and that's the part you should spend your time on. ## More like this Pixeldex's full prompt library has more, pixel-perfect cameras, tile collision, save migration, sprite-sheet recolor for Pico-8, and new ones ship every couple of weeks. The library is filterable by engine and difficulty. If you want to see how these prompts fit together in a real project, the 2D platformer walkthrough chains five of them into a finished game across a weekend. > If we ever shut Pixeldex down, every prompt and walkthrough on the site goes open source. The whole project is bet on the idea that solo devs shouldn't have to start from scratch on the same five problems. ### Full prompts library 9 prompts shipped, more arriving weekly. ### All walkthroughs End-to-end project guides, every prompt inline. #### The 5 prompts - Why these five - 01 · Player controller - 02 · State machine - 03 · Save system - 04 · Level loader - 05 · Game-feel patch - How to use them - More ================================================================================ # Prompt: Top-down 2D player controller (Unity) URL: https://pixeldex.dev/prompts/unity-top-down-2d-player-controller TITLE: Top-down 2D player controller for Unity, grid-snapped · Pixeldex prompt DESCRIPTION: Copy-paste Claude prompt that builds a Unity 2D top-down player controller. WASD movement, sprite flip, animator hooks, input buffer for snappy dashes. Single MonoBehaviour, no packages. - Unity Beginner Run · 2 min Genre · Top-down Top-down 2D player controller, grid-snapped A copy-paste Claude prompt that returns a single C# MonoBehaviour. WASD movement with normalized diagonals, sprite-renderer flipping, animator hooks, and a small input buffer so dashes still feel responsive even if you tap a frame too early. ★ Prompt No.001 Last verified · 2026-05-09 Tested on · Unity 2022.3 LTS EngineUnity 2022.3 LTS or newer LanguageC# Time to run~2 minutes LevelBeginner, comfortable opening Unity OutputOne file, ~80 lines DependenciesNone. No packages, no plugins. The prompt Open a fresh chat at claude.ai/new, paste this in as your first message, and hit send. Don't add anything else. $ Build me a top-down 2D player controller for Unity 2022.3+ // constraints - Single C# MonoBehaviour, no external packages. - WASD movement. Normalize the input vector so diagonals don't sprint. - Speed is a [SerializeField] float, default 5. - Sprite-renderer flip on horizontal input, only when input != 0. - Animator parameters: speedX (float), speedY (float), isMoving (bool). - Input buffer of 0.05s so dashes feel responsive if pressed a frame too early. - Snap-to-pixel option, toggleable via [SerializeField] bool, default off. // physics - Use Rigidbody2D for movement, MovePosition in FixedUpdate. - Read input in Update. Don't write physics from Update. // return format - One file. No prose before or after the code. - Comments only where the constraint is non-obvious. - File should be named PlayerController.cs. Copy prompt Open in Claude ▸ Run · 2 min What this gets you A working top-down character that moves predictably in eight directions. Nothing fancy, but the kind of "feel" details that usually get cut from beginner tutorials are baked in: normalized diagonals so you can't speed-cheese, an input buffer so a dash press near the edge of a frame still triggers, and proper Update-vs-FixedUpdate separation so the character doesn't stutter at low frame rates. It's the controller you'd actually keep in a real project, not a stripped-down demo you have to rewrite the moment you add real gameplay. ★ NEW Drop-in starter ~30 sec setup Skip the copy-paste, download the starter pack Two files: the controller plus an Editor utility that creates a fully-wired Player GameObject (Rigidbody2D + collider + sprite + animator hooks) with one menu click. Drop into Unity, hit Pixeldex → Spawn Top-Down Player, press Play. CC0, no attribution required. ↓ Download starter (.zip · 4 KB) Read the setup steps What good output looks like If Claude got this right, the script should pass these checks. Read the output before you paste it into Unity. One file, no companion classes. If Claude split it into a State, Input, and Movement class, ask it to consolidate. The point is a drop-in starter. - FixedUpdate moves the Rigidbody2D, Update reads input. If physics is being written in Update, ask Claude to fix it before you paste. - Diagonal movement is normalized. Look for .normalized or an explicit length check on the input vector. - The input buffer actually buffers. Look for a small float field (e.g. bufferTime or lastInputAt) that gates dash availability. - Animator parameters are set every frame, not in conditionals. If speedX only updates when input != 0, dropping input won't blend cleanly back to idle. - No magic numbers. Speed, buffer time, and snap toggle should all be SerializeField, so you can tune them without recompiling. ## How to wire it up - Save Claude's output as PlayerController.cs in your Assets/ folder. - Create a 2D GameObject for your player. Add a Rigidbody2D (set Gravity Scale to 0 for top-down) and a BoxCollider2D. - Add an Animator component. Either drop in your existing controller or right-click → Create → Animator Controller and add float parameters speedX, speedY, plus a bool isMoving. - Attach PlayerController.cs to the GameObject. - Press Play. WASD should move you smoothly. The sprite should flip when you press A or D. ## Common gotchas ### The character jitters when moving Almost always a Rigidbody2D Interpolation issue. Set Interpolation to Interpolate on the Rigidbody2D component. If you also have Cinemachine following the player, set the Cinemachine Brake Update Method to FixedUpdate so they tick on the same clock. ### The animator doesn't transition to idle You probably have an empty Animator Controller. Claude assumes you've at least set up the parameters. Add an Idle and a Walk state, set the transitions, and make sure your transitions read the isMoving bool, not the speed floats. ### The pixel-snap option looks blurry Pixel snap only works if your camera is sized to your pixels-per-unit. Set Camera Pixel Perfect to true (or use the Pixel Perfect Camera component from URP). If you're not doing pixel art, leave the snap toggle off. ## Where to go next This is intentionally minimal. When you're ready to extend it, here's the order I'd add things: - Dash. Modify the input buffer field, add a velocity burst on space-bar. - Sprint hold. Multiplier on speed while shift is held. Two lines of code. - Knockback. A coroutine that overrides movement input for N frames after a hit. - State machine. Once you have 3+ states (idle, walk, dash, hurt) it's worth promoting to an FSM. See the FSM-based controller prompt for a clean structure you can port back to Unity. ## Why this prompt is shaped this way Three things make this prompt work better than "write me a Unity player controller": - Constraints, not requests. Telling Claude what the output cannot do (no packages, no companion classes) is more reliable than asking nicely for what you want. - Return format up top. "One file. No prose before or after the code." cuts out the explanation Claude would otherwise write, which clutters the paste. - Specify the version. Unity APIs change. Pinning 2022.3 means Claude won't suggest something deprecated, and won't reach for the new Input System unless you ask. ## Use it however you want The prompt itself is CC0, paste it, modify it, sell something built with it. No attribution required. Same for the output Claude gives you. If you're feeling generous, a link back to pixeldex.dev in your project's README helps the next solo dev find this stuff. ### JSON save and load via PlayerPrefs Persist any C# class to disk, with versioned migrations. ### FSM-based player controller for Godot 4 The next step up: clean state-machine structure for richer movement. #### On this page - The prompt - What this gets you - What good looks like - How to wire it up - Gotchas - Where to go next - Why this shape - License ================================================================================ # Prompt: Unity 2D platformer controller with coyote time and jump buffer URL: https://pixeldex.dev/prompts/unity-2d-platformer-coyote-time TITLE: Unity 2D platformer controller with coyote time and jump buffer · Pixeldex prompt DESCRIPTION: Copy-paste Claude prompt that builds a Unity 2D platformer player controller with coyote time, jump buffer, and variable jump height. Single C# MonoBehaviour, no packages. The # 2D platformer controller with coyote time and jump buffer A Unity 2D platformer controller that includes the small "feel" details that separate a playable platformer from a frustrating one. Coyote time gives players a grace window after walking off a ledge. Jump buffer accepts the input slightly before they land. Variable jump height responds to how long the button is held. Single C# MonoBehaviour, drop-in. ## The prompt Open a fresh chat at claude.ai/new, paste, and send. $ Build me a Unity 2022.3+ 2D platformer player controller with coyote time, jump buffer, and variable jump height. // shape - Single C# MonoBehaviour, file PlatformerController.cs. - No external packages, no input system package. - Requires Rigidbody2D, BoxCollider2D, and a serialized Transform groundCheck child. // movement - Horizontal: A/D or Left/Right, normalized speed. - Speed: [SerializeField] float, default 7. - Acceleration / deceleration: smooth out velocity changes (use a SerializeField smoothing constant, default 0.06). // jump feel - Coyote time: 0.1s grace window. Player can jump for that long after walking off a ledge. - Jump buffer: 0.1s. If player presses jump just before landing, register it on landing. - Variable jump height: if jump button is released before peak, cut velocity.y by 50% (configurable). - Jump force: [SerializeField] float, default 14. // ground check - Use Physics2D.OverlapCircle on the groundCheck Transform with a small radius (0.15) and a SerializeField LayerMask called groundLayer. - Update isGrounded once per FixedUpdate. // constraints - Read input in Update, apply physics in FixedUpdate. - Coyote time and jump buffer are tracked with a single timer field each, decremented in Update. - No magic numbers. Everything tunable is SerializeField. // return format - One file. No prose before or after the code. - Brief comments only on the coyote-time and jump-buffer mechanics, since they're the non-obvious bit. Copy prompt Open in Claude ▸ Run · 3 min What this gets you The difference between "this platformer is unplayable" and "this platformer feels good." Coyote time and jump buffer are the two single biggest "game feel" features a platformer can have, and most tutorials skip them because they're not strictly required for the character to move. They are required for the character to feel like a character. Variable jump height is the third thing every commercial platformer has. Together, these three are the floor, not a polish layer. ### Skip the copy-paste, download the starter pack If watching the prompt-output go in script-by-script feels slow, grab the pre-tested zip instead. Two files: the controller script + an Editor utility that creates a fully-wired Player GameObject in your scene with one menu click. Drop into your Unity project, hit Pixeldex → Spawn Platformer Player, press Play. CC0, no attribution required. ## Why these three matter ### Coyote time Without coyote time, when a player runs off the edge of a platform and presses jump 1 frame too late, the jump is silently swallowed. The player perceives this as "the game ate my input." With a 0.1s grace window after leaving the ground, the jump still registers and the platformer feels responsive instead of unforgiving. ### Jump buffer The flip side. If the player presses jump just before they land, without a buffer the input is lost. With a 0.1s lookback window, the press is remembered and consumed the moment they touch ground. This is what makes "press jump as I land to chain a second jump" feel possible. ### Variable jump height Holding the button gives a longer jump; tapping it gives a shorter one. Without this, every jump is full-height and platforming feels rigid. The implementation is one line: if the player releases jump while velocity.y is still positive, multiply velocity.y by 0.5. ## What good output looks like - Two timer fields, decremented in Update. coyoteTimer and jumpBufferTimer. Both should count down each frame and reset to their max value at the right moment (coyote on leaving ground, buffer on jump press). - Coyote time resets when grounded. Look for coyoteTimer = coyoteTime inside the grounded branch, not at the top of Update. - Jump buffer is consumed, not just checked. When the buffered jump triggers, set the timer to 0 immediately so the same press doesn't fire two jumps. - Variable jump cut is in Update. Reading the button release belongs with input. Velocity write happens once, not in a loop. - Ground check uses a small overlap circle, not a raycast. Raycasts miss the corners of platforms; circles don't. ## How to wire it up - Save Claude's output as PlatformerController.cs. - Create a 2D player GameObject. Add Rigidbody2D (Dynamic, Gravity Scale 3, Freeze Rotation Z true), BoxCollider2D. - As a child of the player, create an empty Transform called GroundCheck. Position it at the bottom of the collider. - Attach PlatformerController.cs to the player. Drag GroundCheck into the script's groundCheck field. - Set the groundLayer mask in the inspector to whatever layer your tilemap is on. - Press Play. Walk off a ledge, then press jump 0.05s later. It should jump. ## Common gotchas ### The character double-jumps Almost certainly because jumpBufferTimer isn't being zeroed when the buffered jump fires. Look for the line that triggers the jump and add jumpBufferTimer = 0; right after. ### Coyote time doesn't trigger Usually the timer gets reset every frame in Update, before it has a chance to count down. The reset should only happen when isGrounded is true, not unconditionally. ### Variable jump cut feels too aggressive The 0.5 multiplier is a starting point. Try 0.3 for a heavier feel, 0.7 for a floatier one. The whole point of SerializeField is so you can tune this in the inspector without rebuilding. ## Where to go next - Wall jump. Add a wall check (overlap on the side), set jump direction based on which side the wall is on. - Dash. A timed velocity override on a key press. Reuse the buffer pattern for the input. - Apex hangtime. Reduce gravity briefly when velocity.y is near zero. Adds the floaty feel of Hollow Knight. - Convert to FSM. Once you have 4+ movement features, consider porting to the FSM structure, the same pattern works in Unity. ## Use it however you want The prompt is CC0, paste it, modify it, ship a game with it. The output Claude gives you is yours. A link back to pixeldex.dev in your project's README helps the next solo dev find this stuff. ### Top-down 2D player controller, grid-snapped The simpler sibling, for non-platformer projects. ### FSM-based player controller for Godot 4 When you outgrow a single MonoBehaviour, this is the structure. #### On this page - The prompt - What this gets you - Why it matters - What good looks like - How to wire it up - Gotchas - Where to go next - License ================================================================================ # Prompt: Unity JSON save and load via PlayerPrefs URL: https://pixeldex.dev/prompts/unity-json-playerprefs-save TITLE: JSON save and load via PlayerPrefs (Unity) · Pixeldex prompt DESCRIPTION: Copy-paste Claude prompt for a Unity JSON save/load system using PlayerPrefs. Auto-versioned, migrates on schema change, handles missing keys. # JSON save and load via PlayerPrefs A small static SaveSystem class that serializes any data class to JSON, persists it via PlayerPrefs, and migrates the data structure cleanly when you add new fields. Handles the case where someone updates the game and their old save is missing keys. ## The prompt Open claude.ai/new, paste, and send. $ Build me a SaveSystem for Unity 2022.3+ that persists a SaveData class to PlayerPrefs as JSON. // shape - A static class SaveSystem with: Save(SaveData data), Load() → SaveData, Has() → bool, Delete(). - A serializable SaveData class with example fields: int level, float playtime, string lastScene, int version. - Use JsonUtility.ToJson and FromJson. Store under PlayerPrefs key "save_v1". // behavior - Load() returns a default SaveData if no key exists or JSON parse fails. - Save() always sets data.version to the current SCHEMA_VERSION constant before serializing. - A private Migrate(SaveData old) method handles version mismatches: returns a new SaveData with old fields copied where compatible, defaults elsewhere. - Logs a warning (not an exception) if migration is needed. // constraints - No try/catch swallowing all exceptions. Catch JsonException specifically. - No async / coroutines. Saves are synchronous, small, and rare. // return format - One file, named SaveSystem.cs. - Include the SaveData class in the same file. - No prose before or after the code. Copy prompt Open in Claude ▸ Run · 4 min What this gets you The version-migration piece is the part that usually gets skipped in tutorials, and it's the part that breaks players' saves a year later when you add a new field. This prompt builds it in from the start, so adding a new SaveData field never costs anyone their progress. ### Skip the copy-paste, download the starter pack Single C# file. Drop into Assets/Scripts/, call SaveSystem.Save(data) / SaveSystem.Load() from anywhere. Versioned schema migration built in. CC0, no attribution required. ## Quick checklist - SCHEMA_VERSION lives at the top. Bumping a number is the only thing you should need to do when changing the schema. - Load() never throws on bad data. A corrupted save returns defaults plus a warning, not a crash. - Migrate() does explicit copies, not reflection. Reflection-based migration is harder to debug and slower. Prefer 6 lines of explicit copying. ## Full breakdown coming soon This page is the prompt itself plus a minimal checklist. The deeper writeup with worked examples, common gotchas, and how to extend with binary encryption is on the roadmap. Bookmark this page or check back on the blog as it ships. ### Top-down 2D player controller, grid-snapped Pair this save system with a working controller and you've got a playable loop. ### Browse the full prompts library 6 prompts shipped, more arriving weekly. #### On this page - The prompt - What this gets you - Checklist - Coming soon ================================================================================ # Prompt: Godot FSM-based player controller URL: https://pixeldex.dev/prompts/godot-fsm-player-controller TITLE: FSM player controller for Godot 4 · Pixeldex prompt DESCRIPTION: Copy-paste Claude prompt for a finite-state-machine player controller in Godot 4. Idle / Run / Jump / Fall states, debug overlay, GDScript only, no plugins. - Godot Intermediate Run · 5 min Pattern · State machine FSM-based player controller for Godot 4 A finite state machine that splits player behavior into Idle / Run / Jump / Fall states, each in its own script. Cleaner than a giant _physics_process match statement, and easy to bolt new states on as your game grows. ★ Prompt No.003 Last verified · 2026-05-09 Tested on · Godot 4.2.1 EngineGodot 4.2 or newer LanguageGDScript Time to run~5 minutes LevelIntermediate, comfortable with node hierarchies and inheritance Output5 files (Player + 4 states), ~150 lines total DependenciesNone. No plugins. The prompt Open a fresh chat at claude.ai/new and paste this in. Don't add anything before or after. $ Build me a finite-state-machine player controller for Godot 4.2+ in GDScript. // shape - Player is a CharacterBody2D with child node "State" (Node) holding state scripts. - One file per state: State_Idle.gd, State_Run.gd, State_Jump.gd, State_Fall.gd. - A small base class State.gd that defines: - enter(player), exit(player), update(player, delta), physics_update(player, delta) - Player.gd holds the current_state, calls its update + physics_update each frame, and exposes a change_state(name) method. // behavior - Idle: zero velocity. Transitions to Run on horizontal input, Jump on jump pressed, Fall if not on floor. - Run: applies horizontal velocity, flips sprite. Same transitions as Idle. - Jump: applies upward velocity once on enter. Transitions to Fall when velocity.y > 0. - Fall: gravity only. Transitions to Idle on landing (is_on_floor() and no input), Run on landing with input. // debug - A simple Label child that shows the current state name. Update it in change_state. // physics - Use move_and_slide(). Read input in physics_update. - Constants at the top of Player.gd: SPEED = 200, JUMP_VELOCITY = -400, GRAVITY = 980. // return format - 5 files, in separate code blocks, with file paths as headers (e.g. # res://player/Player.gd). - No prose before or after the code blocks. Copy prompt Open in Claude ▸ Run · 5 min What this gets you A platformer-style player that's structured the way you'd actually want to maintain it. Each state is its own file, so adding a Dash state means writing one new file and adding one transition line, not unscrambling a 200-line _physics_process. This is the structure used by most mid-to-large indie Godot games. If you're past the "single script throws everything into _physics_process" stage, this is the next move. ★ NEW Drop-in starter ~30 sec setup Skip the copy-paste, download the starter pack A full Godot 4.2+ project: Player.tscn with the node hierarchy pre-wired, 5 GDScript files (Player + 4 states), and a configured Input Map. Import the folder, press F5. CC0, no attribution required. ↓ Download starter (.zip · 6 KB) Read the setup steps What good output looks like If Claude got it right, the output should pass these checks before you paste it: States inherit from a common base. Look for extends State at the top of each State_*.gd file. Without inheritance you can't swap states polymorphically. - change_state lives on Player.gd, not on individual states. States should request a transition by calling player.change_state("Run"), not by reaching across to siblings. - enter() runs setup, exit() runs cleanup. If the Jump state applies its upward velocity in physics_update, you'll get infinite jumps. Velocity should be applied once in enter(). - Gravity is applied in Fall and Jump, not Idle and Run. If gravity runs in every state, the player will sink through the floor on Idle. - The Label updates as the state changes. Easiest sanity check that the FSM is actually transitioning. - No match on state strings inside Player.gd. If Claude wrote match current_state: "idle": ... it didn't actually build a state machine, just renamed if-statements. Ask it to refactor. ## How to wire it up - Save the 5 files at the paths Claude returned (typically res://player/). - Create a scene with this hierarchy: Player (CharacterBody2D) → Sprite2D, CollisionShape2D, State (Node) → 4 child State nodes (one per state script), Label. - Attach Player.gd to the root, and one State_*.gd to each of the 4 child State nodes. - In the editor, drag the State node onto Player.gd's exported state_root field. - Add an Input Map action called jump bound to space. - Run the scene. The Label should read "Idle". Press D to enter Run, space to enter Jump. ## Common gotchas ### The player snaps back to Idle every frame This happens when transition logic in Idle.update() doesn't actually break after calling change_state. In GDScript, change_state won't halt the rest of update() unless you return right after it. Add an early return. ### Jump triggers, but the player doesn't actually rise Almost always because velocity.y is being overwritten by gravity in Jump's physics_update before move_and_slide is called. Make sure gravity is only applied in Fall, and Jump should transition to Fall as soon as velocity.y crosses zero. ### The state machine works but feels stiff Add a coyote-time grace window in Fall (e.g. 0.1s where Jump is still allowed even though the player technically left the floor). This is the single biggest "feel" upgrade for a platformer and worth a follow-up prompt. ## Where to go next - Dash state. One new file: enter() applies a velocity burst, physics_update counts down a timer, transitions to Fall when done. - Wall slide / wall jump. Two new states (WallSlide, WallJump), plus is_on_wall() checks in Fall. - Hurt / Dead. Add a global event bus (autoload Events) so any damage source can request a state change without coupling to player. - Hierarchical FSM. Once you have 8+ states, group related ones (Grounded → Idle/Run, Airborne → Jump/Fall) so transitions can be shared. ## Why this prompt is shaped this way Three small choices that make this prompt land more reliably: - Specifying the file structure up front. Without "5 files in separate code blocks with file paths as headers", Claude tends to dump everything into one file or wrap it in a markdown narrative. Telling it the output format saves you a follow-up. - Naming the constants. SPEED = 200, GRAVITY = 980 keeps Claude from picking weird defaults that feel either floaty or rigid. - Calling out the bad pattern. Saying "no match on state strings" preempts the most common shortcut Claude takes when asked for a state machine. ## Use it however you want The prompt is CC0, free to remix, no attribution. The output Claude returns is yours. If it helped, a link to pixeldex.dev in your jam build's credits keeps the lights on. ### Top-down 2D player controller, grid-snapped The simpler Unity equivalent if you're not ready for an FSM yet. ### Load a tilemap from a CSV file Pair this with the FSM controller and you've got a playable level. #### On this page - The prompt - What this gets you - What good looks like - How to wire it up - Gotchas - Where to go next - Why this shape - License ================================================================================ # Prompt: Godot tilemap CSV loader URL: https://pixeldex.dev/prompts/godot-tilemap-csv-loader TITLE: Load a tilemap from a CSV file (Godot 4) · Pixeldex prompt DESCRIPTION: Copy-paste Claude prompt for a Godot 4 script that parses a CSV file and populates a TileMap node. Handles bounds, missing tiles, autotiles. # Load a tilemap from a CSV file A small GDScript that reads a CSV file (numbers as tile IDs) and pours it into a TileMap node. Bounds-safe, logs unknown tile IDs instead of crashing, supports comment rows. Useful for hand-edited levels or jam projects where you want to tweak in a spreadsheet. ## The prompt Open claude.ai/new and paste this in. $ Build me a Godot 4.2+ GDScript that loads a tilemap from a CSV file. // shape - A Node script TilemapLoader.gd with one public method: load_from_csv(tilemap: TileMap, path: String, layer: int = 0). - Each row in the CSV is a row of tiles. Cells are integers = tile source IDs. - A cell of -1 means "leave empty" (don't write any tile). - Lines starting with # are comments and skipped. - Rows with different lengths log a warning and pad/truncate to the longest row. // behavior - Use FileAccess.open(path, FileAccess.READ). - Use tilemap.set_cell(layer, Vector2i(x, y), source_id) to place tiles. - If source_id is not in tilemap.tile_set, log a warning with the row/col and skip that cell. // example data - After the script, include an example CSV (5 rows × 8 columns) demonstrating: comments, the -1 empty marker, and a missing-tile case. // return format - One .gd file in a code block, one .csv file in a separate code block. - No prose before or after. Copy prompt Open in Claude ▸ Run · 3 min What this gets you The "edit in Google Sheets / Numbers, drop the CSV in, hit play" workflow. Faster than the built-in TileMap editor for prototyping, especially during a jam. ### Skip the copy-paste, download the starter pack TilemapLoader.gd plus an example CSV showing the format. Drop the script into your project, point it at a CSV, and a TileMap node populates. CC0, no attribution required. ## Quick checklist - Uses set_cell with the layer index. Godot 4 made layer-aware setting mandatory; passing 0 is fine, but the parameter must exist. - Handles trailing newlines and BOMs. If you exported from Excel, expect ugly invisible characters. - Logs warnings, doesn't crash. A typo in the CSV shouldn't kill the loader. ## Full breakdown coming soon The walkthrough with a worked example, autotile handling, and a Tiled-format alternative is on the roadmap. Bookmark this page or check back on the blog. ### FSM-based player controller for Godot 4 Pair this loader with the FSM controller for a playable level. ### Browse the full prompts library 6 prompts shipped, more arriving weekly. #### On this page - The prompt - What this gets you - Checklist - Coming soon ================================================================================ # Prompt: Phaser pixel-perfect camera URL: https://pixeldex.dev/prompts/phaser-pixel-perfect-camera TITLE: Pixel-perfect camera with deadzone follow (Phaser) · Pixeldex prompt DESCRIPTION: Copy-paste Claude prompt for a Phaser 3 / TypeScript pixel-perfect camera. Snaps to integer pixel coords, deadzone follow, smooth lerp. No sub-pixel jitter. - Phaser Beginner Run · 3 min Pattern · Camera Pixel-perfect camera with deadzone follow A small camera helper for Phaser 3 / TypeScript that snaps the viewport to whole pixels every frame so sprites don't sub-pixel jitter. Configurable deadzone (camera doesn't move while target is inside a center box) and smooth lerp on exit. ★ Prompt No.005 Last verified · 2026-05-09 Tested on · Phaser 3.70 EnginePhaser 3.60 or newer LanguageTypeScript Time to run~3 minutes LevelBeginner, comfortable with Phaser scenes OutputOne TS class (~70 lines) DependenciesNone beyond Phaser itself. The prompt Open claude.ai/new and paste this in. $ Build me a pixel-perfect camera helper for Phaser 3.60+ in TypeScript. // shape - A class PixelCamera that wraps a Phaser.Cameras.Scene2D.Camera. - Constructor: PixelCamera(scene, target: Phaser.GameObjects.Sprite, options). - Options object: { deadzoneWidth: 80, deadzoneHeight: 60, lerp: 0.1 }. - One public method: update() to be called from the scene's update loop. // behavior - Each frame, compute desired camera center. - If target is inside the deadzone rect (centered on current camera center), don't move. - If outside, lerp camera center toward target by options.lerp (per second, frame-rate independent). - After lerp, snap the camera scrollX and scrollY to Math.floor(). - Set camera.roundPixels = true on construction. // constraints - TypeScript strict-mode safe: no any, no //@ts-ignore. - Use Math.floor on scrollX/scrollY only after the lerp, not during. // return format - One file PixelCamera.ts in a code block. - Include a 6-line example showing how to use it from a scene's create() and update(). - No prose before or after. Copy prompt Open in Claude ▸ Run · 3 min What this gets you Pixel art that stays pixel-perfect even when the camera is following a moving target. Without this, sprites get drawn at fractional pixel coordinates and look slightly fuzzy or strobe-y in motion. ★ NEW Drop-in starter ~30 sec setup Skip the copy-paste, download the starter pack Complete Phaser 3 + TypeScript + Vite project. npm install, npm run dev, and you have a working demo with arrow-key movement and a pixel-perfect deadzone camera in 2 minutes. CC0, no attribution required. ↓ Download starter (.zip · 6 KB) Read the setup steps Quick checklist roundPixels = true is set. This is half the fix. The other half is the floor on scrollX/Y. - Lerp uses delta time. If lerp doesn't account for delta, your camera will move at different speeds at different frame rates. - The deadzone is a real rectangle. If it's just a distance check, diagonal movement will feel wrong. ## Full breakdown coming soon The walkthrough with screenshots and a worked example for parallax layers is on the roadmap. Bookmark this page or check back on the blog. ### Tile-based collision for top-down LOVE2D If you're picking between Phaser and LOVE2D, this is the LOVE side of the line. ### Browse the full prompts library 6 prompts shipped, more arriving weekly. #### On this page - The prompt - What this gets you - Checklist - Coming soon ================================================================================ # Prompt: LOVE2D bump-style tile collision URL: https://pixeldex.dev/prompts/love2d-bump-collision TITLE: Tile-based collision for top-down LOVE2D · Pixeldex prompt DESCRIPTION: Copy-paste Claude prompt for a Bump-style sweep collision in LOVE2D. Tile grid, slopes, one-way platforms, push-out resolution. Single love.update hook. - ! LOVE2D Intermediate Run · 4 min Pattern · Collision Tile-based collision for top-down LOVE2D A Bump.lua-flavored sweep collision module for LOVE2D, but written from scratch and scoped to tile grids. Handles axis-separated movement, slopes, one-way platforms, and push-out resolution. One file, drops into love.update. ★ Prompt No.006 Last verified · 2026-05-09 Tested on · LÖVE 11.5 EngineLÖVE 11.x LanguageLua 5.1 (LuaJIT) Time to run~4 minutes LevelIntermediate, comfortable with Lua tables and OOP-via-metatables OutputOne module (~120 lines), ready to require DependenciesNone. Pure Lua. The prompt Open claude.ai/new, paste, send. $ Build me a tile-grid collision module for LÖVE 11.x in pure Lua. // shape - A module returned via "return Collision" exposing: - Collision.new(tile_grid, tile_size) → returns a world instance - world:move(entity, dx, dy) → returns actual_dx, actual_dy, hit_horizontal, hit_vertical - entity is a table with x, y, w, h fields. - tile_grid is a 2D table where grid[y][x] = tile_id. - A tile is solid if tile_id > 0 and not in the world.passable set. // behavior - Move axis-separated: resolve X first, then Y. This avoids corner snags. - For each axis, compute the candidate AABB at the new position, query overlapping grid cells, find the first solid one in the direction of travel, snap entity flush to its edge. - If no collision, accept the full motion. // extras - world:set_passable(tile_id) and world:set_one_way(tile_id, "up" | "down" | "left" | "right"). - One-way tiles: only block when entity is moving in the blocked direction AND was not already overlapping the tile. // constraints - No global state. Each world is independent. - No external libs. Bump.lua-style API but reimplemented. // return format - One file collision.lua in a code block. - Include a 10-line example showing how to use it from love.update. - No prose before or after. Copy prompt Open in Claude ▸ Run · 4 min What this gets you The collision system that's "good enough for jam, good enough for shipped indie." Nothing fancy, no broadphase optimization, no rotated AABBs. But the axis-separated resolution avoids the most-common collision bug (catching on tile corners), and the one-way platform support is the thing that makes this go from "tutorial code" to "actually usable". ★ NEW Drop-in starter ~30 sec setup Skip the copy-paste, download the starter pack collision.lua plus a runnable demo (main.lua + conf.lua). Drag the folder onto LÖVE and you get a tilemap room with a pink box that bonks off walls. Use the .lua module standalone in your project. CC0, no attribution required. ↓ Download starter (.zip · 4 KB) Read the setup steps Quick checklist X is resolved before Y, in separate passes. If both axes resolve simultaneously, you'll snag on tile corners. - One-way tiles check the entity's previous frame position. Otherwise you can't drop through a one-way platform by holding down. - The world doesn't store entities. Each move() call is stateless. Cleaner architecture, easier to reason about. ## Full breakdown coming soon The deeper writeup with slopes, swept-circle alternative, and a worked platformer example is on the roadmap. Bookmark this page or check back on the blog. ### FSM-based player controller for Godot 4 A different engine's take on movement architecture, worth reading. ### Browse the full prompts library 6 prompts shipped, more arriving weekly. #### On this page - The prompt - What this gets you - Checklist - Coming soon ================================================================================ # Prompt: LOVE2D particle system in pure Lua URL: https://pixeldex.dev/prompts/love2d-particle-system TITLE: LOVE2D particle system in pure Lua · Pixeldex prompt DESCRIPTION: Copy-paste Claude prompt for a custom LOVE2D particle system in pure Lua, no shaders. Emitters, lifetimes, gravity, color tween. Drop-in module. # Particle system in pure Lua, no shaders A small custom particle module for LOVE2D. Emitters with configurable lifetimes, velocities, gravity, and color tweens. No shaders, no SpriteBatch tricks. Drops directly into love.update / love.draw with a one-line setup. ## The prompt Open claude.ai/new, paste, send. $ Build me a custom particle system module for LÖVE 11.x in pure Lua. // shape - A module returned via "return Particles" exposing: - Particles.new_emitter(opts) → emitter instance - emitter:emit(n), spawn n particles - emitter:update(dt) - emitter:draw() // emitter options - position: { x, y } - lifetime: { min, max } seconds - speed: { min, max } pixels/sec - direction: { angle, spread } radians (angle = base direction, spread = +- random offset) - gravity: { x, y } pixels/sec^2 - size: { start, end } pixels (linearly interpolated over particle lifetime) - colors: { start, end } each = {r,g,b,a} (linearly interpolated) // behavior - update(dt) advances every particle: position by velocity * dt, velocity by gravity * dt, age by dt. Removes particles whose age > lifetime. - draw() iterates particles. For each: compute t = age / lifetime, lerp size and color, draw a love.graphics.rectangle("fill", ...) at the current position with the lerped size. // constraints - Pure Lua, no external libs. - No globals. Each emitter is independent. - Use love.graphics.setColor / love.graphics.rectangle. No SpriteBatches, no shaders. - Cap particles at 500 per emitter. Drop new emits if at cap. // return format - One file particles.lua in a code block. - Include a 12-line example showing a "coin pickup" sparkle effect from love.update. - No prose before or after. Copy prompt Open in Claude ▸ Run · 4 min What this gets you "Game feel" without locking into a framework. Hit sparks, pickup glitter, dust on landing, all of these are five-line emitter configs with this module. Building your own gives you exactly the parameter set you need; LOVE's built-in ParticleSystem covers a different surface area and is more verbose for simple effects. ### Skip the copy-paste, download the starter pack particles.lua plus a runnable demo. Drag onto LÖVE, click anywhere to spawn a sparkle burst, ambient dust drifts in the background. Drop the module into your project to use in your own game. CC0, no attribution required. ## Quick checklist - Color is lerped, not stepped. Look for math.lerp / linear interpolation on r, g, b, a separately. - Velocity is in absolute units, not normalized. Setting speed = {min=20, max=80} and direction = {angle=0, spread=math.pi/4} should give particles moving rightward at 20-80 px/sec. - Particles are removed in-place, not via table copy. A simple iterator-and-swap-with-end pattern. Don't allocate a new table every frame. ## Full breakdown coming soon The deeper writeup with worked examples (sparkle, dust, fire, sparks) and how to switch to image-based particles is on the roadmap. Bookmark this page. ### LOVE2D engine track All LOVE2D prompts and recommended starter sequence. ### Tile-based collision for top-down LOVE2D Pair this with the particle module for hit sparks on collision. #### On this page - The prompt - What this gets you - Checklist ================================================================================ # Prompt: Pico-8 sprite sheet loader with palette swap URL: https://pixeldex.dev/prompts/pico8-sprite-sheet-palette-swap TITLE: Pico-8 sprite sheet loader with palette swap · Pixeldex prompt DESCRIPTION: Copy-paste Claude prompt for a Pico-8 sprite sheet helper with palette-swap recolor. Token-budget conscious, uses pal() for runtime recoloring. Single Lua block. # Pico-8 sprite sheet loader with palette swap A small token-budget helper for drawing Pico-8 sprites with runtime palette remapping. The same character at three different team colors, or a flash-white-on-hit, is one function call away. Single Lua block, fits in a Pico-8 cart's tight token budget. ## The prompt Open claude.ai/new, paste, send. $ Build me a Pico-8 sprite drawing helper with palette swap. // shape - A function spr_swap(n, x, y, swaps) that draws sprite n at (x, y) using a per-call palette remap. - swaps is a table mapping source color to target color, e.g. { [8] = 11, [2] = 3 }. - spr_swap restores the default palette after drawing (pal()). // extras - A flash_white(n, x, y) helper that draws the sprite with all colors mapped to color 7 (white). Uses spr_swap internally. - A predefined PALS table with named team palettes: {red = {[11]=8}, blue = {[11]=12}, gold = {[11]=10}}. // constraints - Token budget: keep the entire helper under 100 tokens. - No globals beyond the function names and the PALS table. - Pure Lua, no Pico-8 SDK extensions. // return format - One .p8 lua block of code with the helpers and the PALS table. - A 3-line example showing how to use it from _draw(). - No prose before or after. Copy prompt Open in Claude ▸ Run · 3 min What this gets you Per-instance recolor without doubling your sprite sheet. The same enemy sprite at three colors (red elites, blue mooks, gold bosses) costs the same tokens as one. The flash-white-on-hit gives you "got hit" feel for free. ### Skip the copy-paste, download the starter pack A standalone .p8 cart with the spr_swap and flash_white helpers + a working demo showing 5 palette variants of the same sprite. Open in Pico-8, press Cmd/Ctrl+R. CC0, no attribution required. ## Quick checklist - pal() reset after drawing. Without the reset, the next sprite draw inherits the swap. Easy to miss in code review. - Iterates only over the swap table. Don't loop 0..15, token cost matters. - flash_white reuses spr_swap. Don't write a second drawing function; just build a 16-entry table where every color maps to 7. ## Full breakdown coming soon The deeper writeup with actual token counts, hit-flash timing, and screen-shake combo is on the roadmap. Bookmark this page for the heads-up. ### Pico-8 engine track All Pico-8 prompts, walkthroughs, and recommended starter sequence. ### Browse the full prompts library Filter by engine and difficulty. #### On this page - The prompt - What this gets you - Checklist ================================================================================