DEV Community: Moha Saker

A game release calendar is a dependency map, not a task list

Moha Saker — Fri, 02 Oct 2026 11:58:51 +0000

A small game can have a short feature list and still miss its launch window. The usual culprit is not a single difficult task. It is the handoff between decisions: a mechanic is approved too late for level design, a device test arrives after release assets are prepared, or a store requirement is discovered when the build is already considered finished.

Here is a practical way to build a calendar that exposes those dependencies before they become surprises.

Start with a playable question

Before scheduling every screen and asset, decide what the first playable build must prove. For a mobile action game, the question might be whether the core control loop remains readable and responsive on a physical phone. A prototype that only works in the editor has not answered it.

The first review should therefore include a target device, a short play scenario, acceptance criteria, and the person who can approve the result. Give that person a decision date. “Prototype complete” is not a useful milestone if nobody has time to play or accept it.

Put approval time on the critical path

A schedule often treats client feedback as instant. It rarely is. A two-day art task can turn into a two-week delay if its visual direction is approved after the next environment batch starts.

For every approval, record four things:

What build or artifact will be reviewed?
Who gives one consolidated decision?
What is the latest decision date that protects the next dependency?
What happens if the decision is late: pause, use a pre-agreed fallback, or move the release date?

This makes the calendar a shared decision tool, not just a developer estimate.

Schedule risk checks before polish

Move uncertain work toward the beginning. If input latency, device heat, save recovery, multiplayer connection quality, or store compliance could change architecture, test them before the content pipeline is full.

A useful sequence for a modest mobile game is:

Validate the core loop on a real target device.
Lock the control and camera assumptions needed by content production.
Build one representative level or progression slice.
Run performance, save/recovery, and interruption checks on supported devices.
Enter content production only after the riskiest assumptions are tested.
Reserve a separate window for store assets, submission, review feedback, and fixes.

The durations vary by project; the ordering is the important part. Polishing every environment before testing an actual release build creates the wrong kind of progress.

Define what “ready to ship” means

A calendar needs a release gate with evidence. For example: the release candidate has passed on the agreed device set; blocking defects are resolved; save data survives interruption and update scenarios; the store listing and privacy details match the shipped build; and someone owns the decision to submit.

Without that gate, “development finished” is easily mistaken for “ready for customers.” They are different dates.

Keep one visible buffer, not hidden padding everywhere

Distributed padding makes a plan look safer while concealing what it protects. A visible contingency window at the end of each risky phase is easier to manage. Name the risks it covers, review whether they materialised, and release unused buffer only after the gate is met.

A schedule can still change. What matters is whether the team can explain why a date changed, which dependency moved, and what decision is needed next.

For a fuller buyer-side framework, our game development timeline guide maps discovery, prototyping, production, testing, client reviews, and release readiness into one plan. If you are commissioning a game, ask for the dependency map and approval owners before asking for a final delivery date.

A telemetry contract for a mobile game soft launch

Moha Saker — Thu, 01 Oct 2026 00:24:34 +0000

A limited release only produces useful evidence when the build, events, and decision rule agree. Before opening a mobile game to a small real audience, write a one-page telemetry contract. It prevents a team from calling a broken event trigger “poor retention.”

Start with a question, not an event list

Suppose the launch question is: can a new player complete the first mission without help on the target device class? Name the build version, audience, observation window, and owner. Then define only the events needed to answer it: session_started, mission_started, mission_completed, and an abandonment or failure state. A crash trace and device/build identifier provide context; they do not replace player behavior.

Each event needs a trigger, allowed properties, and an expected count. For example, mission_completed should fire once after the game state commits the result, not every time a completion animation replays. If the game works offline, document how events queue and how duplicates are handled after reconnecting. Without that rule, a retry can make a completion funnel look healthier than it is.

Separate test traffic from release traffic

Validate events in a development or test environment before the limited release, then verify that the production build sends to the intended production environment. Unity Analytics supports environment separation; an impressive graph is not evidence if internal QA sessions are mixed with real players.

Run a small acceptance matrix before opening the audience:

Scenario	Expected evidence
Install and complete mission	One start and one completion for the correct build
Exit halfway	A start without a completion, with no invented success
Lose connection and retry	No duplicate completion after recovery
Crash before objective	Crash and last known stage can be correlated
Internal QA session	Excluded or clearly segmented from release analysis

Do not put personal identifiers into public reports. Decide what data is actually needed and check consent and privacy requirements before instrumenting a user journey.

Make the decision before seeing the graph

The contract should say which outcome means continue to the next bounded audience, which means fix and retest, and which means stop or rescope. A tiny or biased cohort should be labelled inconclusive. If the build changes during the test, split the results by version. If an event is unreliable, mark the measurement invalid; do not treat missing data as player failure.

This is only one part of a wider release decision. Build stability, support load, store availability, and the actual first-session experience matter too. Our broader game soft-launch decision guide covers the difference between beta testing, limited-market release, and staged app updates, plus the evidence a game owner should ask the development team to deliver.

The useful deliverable is not a wall of charts. It is a versioned build, a verified event contract, and a written go/fix/stop decision that another person can audit.

Why our game brief scorer stops at 16 points instead of estimating price

Moha Saker — Sat, 26 Sep 2026 10:15:18 +0000

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.