Most game ideas sound good in your head. Before building for months, prove the one thing that actually kills your risk — that a specific player clearly wants more.
A lot of indie devs open with the same question: "Is my game idea good?"
I think that's the wrong question. "Good" is a verdict you can argue about forever without learning anything, and it usually shows up after you've already sunk six months into a build. By then it's quietly become "please tell me this wasn't a waste of time," which is a much worse place to ask from.
Here's the question I'd ask instead:
What can I prove in 7 days?
Not "will everyone like this." Not "is this a complete game." Just: in a week, with the smallest possible version, what can I learn that I don't currently know? A prototype isn't a tiny version of your finished game. It's an instrument for reducing uncertainty — and uncertainty is the only thing that actually kills a project before it starts.
The one-sentence hook test
Before you build anything, hand the idea to someone who's never heard your pitch and ask them to explain it back. Not the lore. Not the feature list. Just the core promise.
The bar is one sentence:
"I run a potion shop where every customer is secretly lying."
"It's chess, but every piece is a monster I can evolve."
"I manage a tiny train station during the apocalypse."
If your hook needs five paragraphs, you don't have a marketing problem yet. You have a clarity problem. And clarity is cheap to fix now and expensive to fix after the store page is live.
A prototype should answer one dangerous question
The mistake almost everyone makes is building a prototype that tries to prove the whole game — systems, levels, enemies, polish, all of it scaled down. That's not a test. That's a small, slow version of the thing you weren't sure about in the first place.
A good prototype answers a single dangerous question:
Is there something here that players actually react to?
The reaction is the data. A laugh, a flinch, curiosity, tension, the quiet "wait, can I try that again?" If the smallest version of your idea produces no emotion, more content won't rescue it. You'll just have more of something nobody felt anything about.
The rule: before adding more systems, levels, enemies, or polish, first prove the smallest version of the idea creates a real player reaction. That's validation. Not "will everyone like it?" but "is there a specific kind of player who clearly wants more?"
What Steam Next Fest tells you about validation
If you still think the hard part is making a demo, look at what discovery actually looks like now. A recent Steam Next Fest had 4,347 playable demos (per PC Gamer's coverage) — enough that playing each for just 30 minutes would take about 90 straight days.
The takeaway isn't "don't make a demo." It's that you're not only competing against bad games, you're competing against overwhelming choice. The market isn't short on demos. It's short on demos that communicate, in seconds, a clear reason to care — which is exactly the hook you should have tested already.
The upside: developers who treat the demo seriously get more than wishlists out of it — feedback, publisher attention, community energy, and roadmap changes. One dev called it "early access for Early Access." A demo isn't only marketing. It's a public design test you run in front of real players.
Why Steam wishlists aren't validated demand
Here's the trap: a single platform signal feels like proof, and it isn't. Planet Centauri is the cautionary version — a game with a reported 130,000+ wishlists that, after a wishlist-notification issue around its 1.0 launch, sold only 581 units in its first five days.
Wishlists matter. But a wishlist is a maybe — a low-cost intention recorded months before any money changes hands. Real validation stacks proof points that are harder to fake:
Hook clarity — strangers can repeat what your game is
Demo reaction — players feel something in the first few minutes
Community behavior — people ask when it releases, not whether it will
Conversion — interest survives the moment a price appears
When Polygon asked devs how their games found the first 1,000 players, nobody pointed to a magic trick. It was demos, wishlists, social, streamers, niche targeting, and emotional appeal — repeated proof, over time, that a specific audience cared.
Validate the core loop, not just the mechanic
There's one kind of validation a hook test and a vertical slice can't give you, and it quietly sinks the most projects: does the core loop still hold up after the novelty wears off?
"Is this mechanic surprising in minute one?" is a hook question. "Is this loop still worth playing in hour ten?" is an economy question. For most games the loop is an economy — resources in, resources out, progression living in the gap. If sources outpace sinks, players drown in currency and stop caring. If sinks outpace sources, they hit a wall and quit. Either way it felt fine in a 20-minute demo and fell apart over a real session.
You don't need months of content to find that out. You can model the loop before you build it — map your sources and sinks, set the progression curve, and simulate how the numbers behave across hours of play instead of guessing and finding out post-launch. A hook test tells you whether players want to start. An economy sim tells you whether they'll want to keep going.
A 7-day validation plan
If you've got an idea and a week, here's a version that proves risk instead of building features:
Write the hook in one sentence. Read it to three people who've never heard the pitch.
Ask each to explain it back. If they can't, fix the idea — not the wording.
Build the smallest playable version that can produce one emotion. Nothing else.
Watch someone play it without you talking. Note the first real reaction and where it dies.
Model the core loop's sources and sinks and check whether it survives ten hours, not ten minutes.
Decide the dangerous question you actually answered — and the next one worth a week.
None of this proves your game is good. That was never the useful question. What it proves is narrower and far more valuable: that there's a specific player who clearly wants more, and a loop underneath them worth building toward.
Curious how other people here handle this — what's the best way you've found to validate a game idea before building too much?
I wrote the full version, with the economy-validation breakdown, on the Itembase blog: Stop asking if your game idea is good — ask what you can prove in 7 days
