There is a folder on every indie team's drive called ideas, and it has thirty-seven files in it. Some are a single sentence. Some are a 14-page design document written during a holiday. On a Friday afternoon, three people argue for two hours, pick the one with the best name, and start building it on Monday.
That Monday decision is the most expensive one your team will make all year. A three-person studio with an eighteen-month runway has roughly fifty-four person-months to spend. Choosing the wrong concept doesn't cost you a sprint — it costs you the entire budget, and you usually find out at month eleven, when the loop still isn't fun and nobody wants to say so out loud.
Concept selection deserves a process, the same way bug triage or milestone planning does. Here is one that takes about two weeks and kills nine ideas so you can commit to one without flinching.
Step 1: Force every idea into the same shape
You cannot compare a sentence to a 14-page document. Before anything gets scored, rewrite every candidate as an idea card with exactly six fields, each capped at two lines:
- Core verb — the thing the player does ten thousand times. Hook a ledge and swing. Rewind five seconds. Stack tiles.
- Fantasy — who the player becomes. Not a genre. "A salvage diver who is always slightly out of air" beats "atmospheric underwater exploration."
- Loop — the 30-second cycle. Scout → extract → spend → upgrade.
- Hook — the one sentence a streamer says when they clip it.
- Biggest risk — the thing that, if it doesn't work, kills the project. Be honest: it's usually "the core verb is only fun for twenty minutes."
- Nearest reference — an existing game, plus the one thing you'd do differently.
Half your folder dies here, and that's the point. An idea that cannot name its core verb is a mood, not a concept. Moods belong in a mood board; they do not belong in a greenlight review. Keeping these as structured entries in an idea log — rather than loose files — means next year's you can still read them, and the ones you reject stay searchable instead of being rediscovered from scratch.
Aim to arrive at this stage with eight to twelve cards. Fewer than five and you're not choosing, you're rationalising.
Step 2: Score against your constraints, not against fun
Everyone scores their own idea highest on "fun," so don't ask that question. Ask whether this specific team can finish this specific game. Use a 1–5 scale with weights, and score every card in one sitting so the scale stays consistent.
| Criterion | Weight | 1 point | 5 points |
|---|---|---|---|
| Team fit | ×3 | Needs skills nobody has (netcode, 3D animation) | Plays to what your team already ships well |
| Content cost per hour of play | ×3 | Hand-authored levels, 40 unique assets per hour | Systemic or procedural, assets reused across runs |
| Hook legibility | ×2 | Needs three minutes of explanation | Readable in a 6-second GIF |
| Risk retirement speed | ×2 | Core risk only testable after 6 months | Core risk testable in a week |
| Audience exists | ×2 | You can't name five comparable released games | Clear shelf, clear tags, clear players |
| Conviction | ×1 | Nobody will defend it in month nine | Someone genuinely won't let it die |
Note that conviction is weighted lowest, not highest. It is the tiebreaker, not the argument. Passion keeps a project alive through month nine; it does not make an 80-hour-per-player RPG buildable by two people.
Content cost per hour deserves the heavy weight it has. Estimate it concretely: if your concept needs 40 bespoke rooms and one person builds a finished room in three days, that's 120 person-days — about six months — for level geometry alone, before art passes, scripting or audio. A roguelite built from 25 reusable rooms recombined by rules buys similar play time for a fraction of that. Neither is wrong; the point is to know the number before you commit, not after.
Step 3: Spike the top three with kill criteria written in advance
Take your top three and give each one week of prototyping — no more. Before you start, write down what success looks like. Not "see if it's fun." Something a stranger could judge:
- A player who has never seen it performs the core verb successfully within 60 seconds, with no tutorial text.
- Five out of eight testers choose to start a second run without being asked.
- You can build one piece of content (a room, an enemy, a level) in under four hours by the end of the week.
- An outside observer watching a 20-second clip can describe what the player is trying to do.
Writing kill criteria beforehand is the whole trick. Afterwards, you will unconsciously lower the bar to match whatever you built — it's the easiest self-deception in game development, and a sentence written on Monday is the only reliable defence against it on Friday.
Timebox hard. A prototype that needs three weeks to be judged is itself a finding: your core risk retires slowly, which was criterion four.
Step 4: Write the pitch before you write the engine
For the surviving concept, write a one-page pitch before production starts: hook sentence, core loop, three screenshots or mockups, target platform, scope statement, and the one comparable game you'd sit next to on a store page. This is not a funding document — it's a commitment device. If you can't write a tight page about your own game now, the problem is the concept, not your writing. A pitch maker that forces the same fields every time is useful here precisely because it won't let you hide a vague hook behind pretty art.
Then do the uncomfortable part: write the scope statement as a number. "Three biomes, 25 rooms, 12 enemies, 6 weapons, target 4 hours to credits." You will be wrong. You will still be closer than a team that never wrote one, and every later cut has a baseline to cut from.
Step 5: Kill the other ideas out loud
Record the decision somewhere permanent: what you chose, what you rejected, the top two reasons for each rejection, and — this matters most — the condition that would reverse the call. Something like: "Rejected the co-op horror concept because neither of us has shipped netcode. Revisit if we hire a network engineer or the design survives being made two-player local."
Teams without this record re-argue the same decision every three months, usually at the worst possible moment, usually when someone is tired. A decision log entry takes four minutes to write and ends that conversation permanently — the answer is already there, with the reasoning attached.
The two-week checklist
- Every candidate rewritten as a six-field card; moods discarded
- 8–12 cards scored in one sitting, same scale, same day
- Weighted scores calculated — not debated
- Top three identified, one week each, no extensions
- Kill criteria written before the first line of prototype code
- Spikes run with at least four outside testers each
- One-page pitch written for the survivor
- Scope statement expressed in countable units
- Rejections logged with reasons and reversal conditions
- Rejected cards archived, not deleted
Why this is worth two weeks
Two weeks out of eighteen months is roughly one percent of your runway. The alternative is a Friday afternoon argument, a charismatic teammate, and the real possibility that you discover the problem at month eleven with nothing archived and nothing learned.
You will not pick the best possible game this way. You'll pick a game your team can finish, with its riskiest assumption tested first and its scope written down in numbers — and you'll have nine archived cards that cost you nothing to keep. One of them is your next project. Another one is the same idea you'll have again in eight months, except this time the card will tell you why you said no.