A lot of indie devs open with the same question: “Is my game idea good?”
It feels like the right thing to ask. It almost never is. “Good” is a verdict you can argue about forever without learning anything, and it tends to arrive after you’ve already sunk six months into a build. By then the question has quietly changed into “please tell me this wasn’t a waste of time,” which is a much worse place to ask from.
A better question
Try this one 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 is not a tiny version of your finished game. It’s an instrument for reducing uncertainty, and uncertainty is the only thing that can actually kill a project before it starts.
The one-sentence hook test
Before you build anything, test whether the idea survives contact with a stranger. Give it to someone who has never heard your pitch and ask them to explain it back to you. Not the lore. Not the feature list. Not the roadmap. 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. The systems, the levels, the enemies, the 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 will not 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 that the smallest version of the idea creates a real player reaction. That is 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 a discovery event actually looks like now. Steam Next Fest isn’t short on playable demos — it’s drowning in them.
4,347
playable demos in a single Next Fest, per PC Gamer’s coverage
~90 days
to play each one for just 30 minutes, back to back
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. That reason is exactly the hook you should have already tested.
The upside is that developers who treat the demo seriously get more than wishlists out of it. In GamesRadar’s interviews, teams described using demos to gather feedback, attract publishers, build community energy, and reshape their roadmaps before launch. One developer 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 of this story: 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. Years of work, a huge wishlist number, and a launch that the coverage framed as a visibility disaster.
Wishlists matter. But they are not the same as validated demand. A wishlist is a maybe — a low-cost intention recorded months before any money changes hands. Real validation comes from stacking 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 developers how their games found the first 1,000 players, no one pointed to a single magic trick. The answers were demos, wishlists, social, streamers, sharp niche targeting, and emotional appeal — repeated proof, over time, that a specific audience cared.
Validate the core loop, not just the mechanic
There’s a kind of validation that a hook test and a vertical slice can’t give you, and it’s the one that 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 come in, resources go out, and progression lives in the gap between them. If sources outpace sinks, players drown in currency and stop caring. If sinks outpace sources, they hit a wall and quit. Either way, the build felt fine in a 20-minute demo and fell apart over a real play 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.
The cheap test
A hook test tells you whether players want to start. An economy simulation tells you whether they’ll want to keep going. Running the second one early is the difference between validating a feeling and validating a game.
A 7-day validation plan
If you have 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 of them 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.
FAQ
How do you validate a game idea before building it?
Test the smallest version of the idea, not the whole game. Check the hook first — can a stranger explain your game in one sentence? Then build the smallest playable version that can produce one emotion, watch someone play it, and look for a genuine reaction. Last, model the core loop’s sources and sinks to confirm it holds up over hours of play, not just minutes.
When is a game ready for public feedback?
As soon as the smallest playable version can answer one specific question — like whether the core mechanic creates a reaction. You don’t need a vertical slice or a finished demo to learn whether players care. Show it the moment it can produce one real emotion in the first few minutes.
Are Steam wishlists a good validation signal?
They matter, but they aren’t validated demand. A wishlist is a low-cost intention recorded months before any purchase. Strong validation stacks several proof points: hook clarity, demo reaction, community behavior, and conversion once a price appears. Relying on one platform signal is where projects get burned.
How do you test a game’s core loop before building it?
Map the loop’s sources and sinks, set the progression curve, and simulate how the numbers behave across hours of play. If sources outpace sinks, players drown in currency; if sinks outpace sources, they hit a wall. Modeling the economy early shows whether the loop survives long sessions before you commit to months of content.