Game developers

A game plan has to protect the one thing you cannot fully specify up front: whether it is fun. The rest — systems, content, milestones — you can structure. This setup keeps that structure light so it stays out of the way of iteration, and points your coding agent at the mechanical work while you keep judgment over feel. The example below is a solo developer building a 2D action roguelike toward a vertical slice.

Recommended setup at a glance

Part	Example setup
Project	Lanternfall
Product context	A fast 2D action roguelike where each run descends a different floor of a collapsing tower, for players who want Hades-style runs in short sessions
Areas	Combat, Movement, Generation, UI, Audio
Active release	Vertical slice
Starter tasks	Build the core run loop, hand-author floor one, add three enemy types and one boss, tune hit feedback
Ownership and cadence	You own every task; play your own build daily; review what felt wrong each week
Agent role	Turn a system into scoped tasks, build mechanics and tools, and keep gameplay code tied to the pillars

Write the game's pillars as your product context

Your product context for a game is its pillars: what the player does moment to moment, the feeling you are chasing, and why someone picks it over the game next to it. For Lanternfall that might be: "Tense, fast runs you can finish in fifteen minutes. Every floor is different, death always feels fair, and one more run is hard to resist."

Keep it short. You will not write fun into existence from a document, but a clear pillar statement is what you hold a messy build against — and it is what your coding agent reads before it proposes work. When a feature does not serve a pillar, that is your signal to cut it. See Product context.

Name releases after milestones you can play

Game milestones are already outcome-shaped, so use them directly. A useful ladder for most indie games:

• Vertical slice — one slice that feels finished: the core loop, a few enemies, one boss, real feedback and audio.
• Playable demo — the slice hardened for strangers, ready for a festival like Steam Next Fest.
• Early Access — enough content and stability for players to buy and shape.
• 1.0 — the full game.

Keep one release active and name it after the milestone you are reaching for, not a date. The vertical slice is done when you can hand someone the build and the core loop holds up — not when the calendar says so. Put only the tasks that milestone needs inside it; everything else waits in the backlog. See Releases.

Turn game systems into areas

Areas are the systems your game is built from: Combat, Movement, Generation, UI, Audio. They persist across every milestone, so a task or bug always has an obvious home.

Games have more candidate systems than a typical app, so resist mapping all of them. Start with the three to six that own real ongoing work and fold the rest in — Save and Meta-progression can share one area until they are big enough to split. Content such as levels, enemies, art, and audio belongs as tasks under the relevant system, not as its own area. And keep phases like "demo" or "polish" out of areas; those are releases.

Plan the next milestone tightly, the rest loosely

You cannot plan a whole game up front, and pretending you can is how plans rot. Keep the active milestone tight and specific; keep everything past it as a loose backlog you expect to rewrite.

Work in a short loop: decide the next playable thing, build it, play it, and let what you feel reshape the plan. A task that sounded essential last week can be cut the moment the build proves it is not fun. That is the process working, not failing.

Get feedback from players, not just your own taste

You will go blind to your own game. Get builds in front of people early — friends, a Discord, a public demo — and route what comes back through the Feedback Hub or the lighter public bug reporter so it lands in one queue instead of scattered DMs.

Watch for patterns, not one-off opinions. Three players bouncing off the same fight is signal; one person's wishlist is not. Convert a report into a task only when you understand the problem and it belongs in the current milestone — a bug can be real and still wait.

Put your agent on systems, keep feel for yourself

Connect Claude Code or Codex to the project and your engine, whether that is Unity, Godot, or Unreal. The agent reads the same pillars, active milestone, areas, and tasks you do, then works on a named task — building mechanics, tools, and the boilerplate around them — instead of guessing from a one-off prompt. The agent plugin guide covers linking the repository.

Keep the judgment that cannot be delegated: what feels good, how hard is too hard, and whether a system earns its place. Let the agent build the combat system; you decide whether the combat is fun.

Run a weekly playtest and plan check

1. Play your own build, ideally a fresh run, and note what felt wrong before you fix anything.
2. Check the active milestone still describes the next thing worth making playable.
3. Cut or defer tasks the latest build proved unnecessary, then pull in the next ones that serve the milestone.
4. Review player feedback for repeated problems and turn only those into tasks.

Fifteen minutes is enough when you are playing the game through the week.

Apply this setup

1. Write your pillars on the Product page — what the player does, the feeling, and the hook.
2. Create three to six system areas and keep content as tasks beneath them.
3. Make the vertical slice your active release, with only the tasks it needs.
4. Connect your coding agent to your engine and let it build systems while you judge feel.