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.
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."
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."
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.
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.
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).
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."
Sparkles, dust, hit-sparks. Drop-in module, configurable emitters.
Same sprite at 3+ colors without doubling the sheet.
Stops sprites sub-pixel jittering when the camera moves.
Current gaps we're working on: