When someone asks for a game development estimate, the difficult part is rarely choosing a number of screens. Two projects described as “a mobile game with levels” can differ radically in controls, online dependencies, content volume, transaction rules, device targets, and the evidence needed at handover. A form that asks for a genre and returns a price would make those unknowns look solved.
We built a small, browser-only Game Development Brief Scorer to expose those unknowns before a scoping conversation. It is deliberately a readiness check, not a cost calculator.
The model: eight decisions, three states
The tool asks about audience and platform, core loop, first playable proof, content boundaries, online dependencies, monetization, quality targets, and handover/ownership. Each area gets one of three answers:
| Answer | Points | What it means |
|---|---|---|
| Not defined | 0 | The decision still needs a conversation. |
| Partly defined | 1 | There is a direction, but no testable boundary. |
| Written and testable | 2 | Someone can point to a decision and an example or acceptance check. |
The total is 0–16, but the list of gaps matters more than the total. Two briefs can both score 10 and still need entirely different next steps. One may have a crisp playable loop but no ownership for store accounts; another may list every deliverable while leaving the multiplayer authority model undefined.
The application sorts all criteria below 2 so completely undefined items come first. In simplified JavaScript:
const gaps = scores
.map((score, index) => ({ score, index }))
.filter(({ score }) => score < 2)
.sort((a, b) => a.score - b.score);
The result gives a concrete question to answer for each gap, such as the target devices and controls for “audience and platform” or the build steps and account owner for “handover.” We intentionally do not multiply points by a guessed hourly rate. Brief completeness is not effort, schedule, technical risk, or commercial price.
What “testable” changes in a brief
“The game should feel smooth” is a useful goal but not an acceptance rule. A testable version names target devices, a performance floor, representative scenes, and the build on which to measure them. “We need multiplayer” becomes more useful when it states whether matches are synchronous, who owns authoritative game state, what happens on disconnect, and which failure case the first playable must demonstrate.
The same discipline applies to the first milestone. Instead of promising “a prototype,” define one slice, the behavior it must prove, and the decision it unlocks. If the slice cannot answer a real production question, adding content before that proof can make a bad assumption more expensive to change.
Why it stays in the browser
The current tool has no account, form submission, or analytics. Selections are scored in the page and the result can be printed. That is a modest architecture choice, but it fits the job: a prospective client can inspect the questions without handing over an unfinished idea or personal details. The scorer does not need that information to identify missing decisions.
This also limits the tool honestly. It does not save a project, compare teams, validate a proposed scope against source code, or turn a number into a reliable quote. A low score says “start with focused discovery,” not “your idea is weak.” A high score says the first estimate discussion can be more specific, not that the scope cannot change.
If you are building a similar planning tool, I would keep the output tied to specific unanswered decisions and make the limitations visible. A plausible-looking number without a trail of assumptions is less helpful than a short, actionable gap list.
The live scorer is free to try. We use it as an early conversation aid at Upload For Software, not as a substitute for a technical review or written project scope.
Top comments (0)