How to validate a game idea before prototyping it

Validating means reducing risk, not proving success

No check can guarantee that a game will be liked. But a few hours of preparation can save weeks of prototyping on a badly formulated idea or one that is already well covered. The goal is to state what you believe is true, look for evidence against it and decide what to test first. Do this work before opening your game engine.

1. Write the idea as one sentence and one bet

Complete: "The player will do X because Y." For Dicebound, the fictional dice roguelike: "The player will lock a die and reroll the others, because the risk of losing a good result creates a real decision." A clear bet can be wrong, and that is what makes it useful. Avoid sentences like "a fun and original game".

2. Look for close games

Search Steam, itch.io and videos for games that already do something close. Paste the most relevant ones on the board with a note: what they do the same, what they do differently. An occupied genre is not a red light: it shows that an audience exists. But an idea identical to an existing game needs a clear reason to exist.

3. Read the Steam signal without over-interpreting it

On an Impstash Steam card, look at the review count, the percentage of positive reviews and the player estimate, which remains an estimate. Good figures on close games suggest an audience responded; weak figures may come from a niche, a recent release or low visibility. They prove neither that your idea will work nor that it will fail.

4. Define the smallest playable test, and its criterion

Choose the smallest test that answers your bet: one fight, three dice, one enemy. Before the test, decide what you will count as a positive sign: for example, three testers out of five voluntarily reroll after understanding the rule. If you decide afterwards, you will interpret the results so that they prove you right.

5. Decide: continue, pivot or drop

After the test, sort the idea: kept, to explore or dropped. In Impstash, each idea carries one of these statuses, and you can turn it into a task. A dropped idea is not lost: write down why, so you don't propose it again in three months. If the bet was wrong but another lead appeared, state the next bet.

A prompt to adapt to your game

I am preparing a dice roguelike, Dicebound. My bet: the player locks a die and rerolls the others because the risk creates a decision. Play a skeptical reviewer. List five risks or fragile assumptions, the kinds of close games I should check myself on Steam, the smallest two-minute playable test and a success criterion to set before testing. Do not pretend to know sales or the market: tell me what I need to verify.

Replace the references and constraints with your own. The AI’s answers are leads to review; the choice remains yours.

References and communities to keep going

• Dicey Dungeons — Dice values turned into decisions: study equipment constraints.
• Slice & Dice — Visible enemy intents: compare risk, rerolls and dice teamwork.
• Dicey Dungeons — Creator notes and videos
• r/gamedesign — To discuss mechanics, rules, and design trade-offs.
• r/gameideas — To share a structured idea and explore its possibilities. Check the rules before publishing.