The 5 Claude prompts every solo game dev should keep in a file

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:

1. Run prompt #1 to get a character moving in 30 minutes.
2. If you start adding states, switch to prompt #2 before your Update hits 100 lines.
3. Run prompt #3 the moment you have anything worth saving.
4. Run prompt #4 the second you wish you could edit a level outside the engine.
5. 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.