i use claude for game design before i open unity and it changed how fast my projects move
For two years I would open Unity and figure out what I was building as I built it. Systems would change halfway through because I had not thought them through. I would build the wrong thing, scrap it, and rebuild. Six months ago I started spending 20 minutes with Claude before opening Unity for any new feature or system. The projects I have shipped since then moved noticeably faster. This is the exact way I use Claude for game design and the prompts that actually produce useful output.
Marcus Webb
June 24, 2026
Before this workflow: I scrapped and rebuilt my inventory system twice on my last RPG project. Each rebuild took about a day. Total wasted time: two days. After adding the Claude design step before implementation: I have not scrapped and rebuilt a single system on my current project, which has been in development for four months. I am not claiming Claude prevents all rework. I am saying that thinking a system through before building it prevents most rework, and Claude makes that thinking session faster and more structured than doing it alone.
What I Was Doing Before and Why It Was Slow
The old process was: have an idea for a system, open Unity, start building. The problem is that ideas look simpler in your head than they are in code. An inventory system sounds straightforward until you start deciding whether items should be ScriptableObjects or plain classes, whether the UI should read from the inventory directly or through an event system, whether you want stacking and if so how stacking interacts with equipment slots. I was making these decisions mid build, which meant changing things I had already built, which meant debugging things I had just changed. The Claude design session before Unity is twenty minutes of making those decisions before any code exists. Changing a decision costs nothing before it is in code. After it is in code it costs an hour.
The Exact Prompts I Use
# My Claude game design prompts, written out exactly as I use them
## Prompt 1: System architecture before I write any code
I always start with this. I describe the system I want to build and
ask for the simplest architecture that achieves it. The key word is
simplest. Without that word Claude sometimes gives me
over-engineered answers.
Example:
---
I am building a save and load system for a 2D RPG in Unity 6.
The player needs to save: current position, inventory contents,
quest states as an enum per quest, and player stats as floats.
Saves should persist between sessions. The game will have
three save slots.
What is the simplest data architecture and C# class structure
for this? I want to be able to extend it later without rewriting
the core. Give me the class names and what each one owns.
Do not write the code yet.
---
Claude gives me a structure. I spend five minutes reacting to it.
Does this feel right. Is there anything missing. Do I understand
what each piece does. Then I ask a follow up.
## Prompt 2: Anticipating problems before I build
After I agree on the architecture I ask this:
---
Given the save system architecture you described, what are the
three most likely problems I will hit during implementation
or in testing? Be specific about Unity 6 and about solo dev
context. I want to know what to watch out for.
---
This is my favorite prompt in the whole workflow. Claude tells me
things like: make sure you handle the case where a save file
exists from a previous version of the game with different fields,
or: JSON serialization in Unity does not handle enums as strings
by default so you will need to use a converter.
I hit fewer surprises during implementation because I thought
about them before I started.
## Prompt 3: When I am stuck on a design decision
Sometimes I have two options and cannot decide which is better.
---
I am designing the combat system for my action RPG.
I am deciding between two approaches for player attack input:
Option A: Hold button to charge, release to attack.
Option B: Tap button for fast attack, hold for heavy attack.
The game has an emphasis on timing and rhythm.
What does each option do to the feel of combat and
which fits a rhythm focused design better?
---
Claude gives me a considered answer about what each option
feels like for the player. I do not always take its recommendation
but it almost always adds a consideration I had not thought about.
## Prompt 4: Checking a design for missing edge cases
Before I start building anything I run this:
---
I am about to build [system name] for my Unity game.
Here is how it works: [description].
What edge cases or player behaviors should I plan for
that might break this system or produce unexpected results?
---
The answers save me from edge cases I discover through
playtesting two weeks later.What Claude Gets Wrong on Game Design
- Claude gives generic game design advice when I ask about feel. When I ask whether a mechanic feels fun the answer sounds like it came from a game design textbook. Correct in principle. Not specific to my game. I have learned to ask Claude about structure and logic and to trust my own judgment about feel.
- Claude over-engineers architecture when I do not specify simplest. Without that constraint I have gotten save system designs that included abstract factory patterns and interface segregation principles that were completely unnecessary for a solo indie game. The word simplest in every architecture prompt is essential.
- Claude does not know my game unless I tell it. I have to provide context about the genre, the tone, the controls, and the existing systems every time. It does not remember previous conversations and it cannot read my project files. The design sessions are only as good as the context I provide.
- Claude occasionally suggests patterns that are technically correct but wrong for Unity specifically. I once got a design suggestion that recommended a dependency injection container. Absolutely valid pattern in some contexts. Not appropriate for a solo Unity project. Using Claude for architecture and Muse Chat for Unity specific validity checks catches most of these.
The 20 Minute Design Session in Practice
- Minutes 1 to 5: I describe the system I am building and ask for the simplest architecture. I read the response and note any parts I disagree with or do not understand.
- Minutes 6 to 10: I react to the architecture. I modify anything that feels wrong for my game. I ask follow up questions on anything unclear. I confirm the structure I am going to build.
- Minutes 11 to 15: I ask what problems I should watch out for during implementation. I write down anything that is non-obvious.
- Minutes 16 to 20: I ask for edge cases I should plan for from the start. I add any missing ones to my implementation notes.
- After 20 minutes I open Unity knowing exactly what I am building, why it is structured the way it is, and what to watch out for. The first hour of coding is more productive because there are no major decisions left to make.
Mistakes I Made Getting This Working
- Treating Claude design outputs as final without reviewing them myself: Once took a system architecture Claude suggested without questioning it. The architecture was technically sound but introduced a dependency between systems that made testing harder than it needed to be. I would have caught it if I had spent five minutes reviewing before accepting. The Claude session is a starting point to react to, not a final decision to execute.
- Skipping the edge cases prompt when I was in a hurry: Skipped it twice in two months. Both times I hit an edge case during testing that the prompt would have surfaced in advance. The 5 minutes on the edge cases question is not optional.
- Not giving enough context about my game: Early Claude design sessions produced too-generic architecture suggestions because I was describing the system in isolation without explaining the game it was for. Now I start every design session with two sentences about the game before describing the specific system.
- Using Claude for feel decisions and Muse Chat for architecture decisions: Got these backwards in month one. Claude is better at design reasoning. Muse Chat is better at Unity specific implementation knowledge. Each tool works best in its correct role.
Final Thoughts
Twenty minutes with Claude before opening Unity changed how my projects move more than any other single workflow change I have made. Not because Claude designs my games. Because thinking through a system before building it prevents the kind of mid build rework that used to cost me days. Claude makes that thinking session faster and more structured than doing it alone with a notebook. The projects still take the same amount of creative work. They just waste less time building the wrong version of things.