Game Bug Triage Before Release: What Actually Blocks Shipping

For a small indie team, game bug triage before release should answer one question: does this issue make the current build unsafe to ship, or can it be deferred without misleading or blocking players? Judge impact first, then urgency, then fix risk. A crash on the critical path may block release; a visible but harmless animation glitch may not. Late in production, fixing every known bug is usually riskier than deciding deliberately which bugs must move.

Separate severity from shipping priority

Do not use one label to mean both “how bad is this?” and “what do we fix next?”

GitLab’s issue-triage guidance recommends defining both severity and priority criteria. That distinction is useful for games because a severe issue can be rare or platform-specific, while a modest issue can deserve immediate attention if it affects every new player in the opening minutes.

For release triage, define severity as player impact:

• Blocker: prevents launch, progression, input, saving, loading, purchase-required flow, or another critical path.
• Major: seriously damages the intended experience but has a workable path around it.
• Minor: visible defect with limited gameplay impact.
• Cosmetic: presentation issue that does not change play.

Then assign shipping priority separately: fix before release, investigate before release, defer with a known limitation, or close as not worth the change risk.

Godot’s public release-priority criteria use similar signals for its own release process: regressions, significant crashes, showstoppers, data loss, security problems, hardware-specific failures, and new platform requirements receive special attention. Your game needs its own thresholds, but the principle transfers well: prioritize failures that break expected behavior or remove a viable path forward.

Run every candidate bug through five questions

Use the same gate for every issue discussed in the final release window.

Release blocker test

1. Can a player hit it in a supported configuration? Record platform, input method, save state, and build.
2. What does it stop? Launch, progression, persistence, controls, purchase flow, or only presentation?
3. Is there a reliable workaround? A workaround lowers urgency only if a normal player can reasonably discover or use it.
4. How broad is the impact? One optional edge case is different from the first-run path or a common controller.
5. What is the regression surface of the fix? A one-line data correction and a late save-system rewrite should not be treated as equivalent.

That last question matters near release. A “small” player-facing bug can require a high-risk code change. If the defect is deferrable and the fix touches several stable systems, shipping with a documented known issue can be safer than destabilizing the candidate.

This complements a Definition of Done for game features. Definition of Done tells you whether new work is complete; release triage tells you what to do with defects that still exist when the build is otherwise approaching shipment.

Example: triaging four bugs in one candidate build

Consider a hypothetical three-person PC team preparing a release candidate.

They have four open bugs:

• Game freezes after loading a save created before a recent inventory change.
• Controller focus disappears in an optional credits screen.
• One enemy animation clips through a wall.
• Alt-tabbing can reset an audio slider.

The save freeze is a release blocker if existing saves are supported: it stops progression and risks player data expectations. The credits-screen controller issue is major or minor depending on whether the player can exit using another supported input. The wall clipping is cosmetic. The audio-slider reset is minor unless it exposes a wider settings-persistence problem.

Now add fix risk. Suppose the save freeze is fixed by a narrow migration guard with a reproducible test, while the credits issue requires replacing a shared UI-navigation layer days before release. The team may reasonably fix the save bug, defer the credits issue, and leave the cosmetic bug alone.

That is triage: not ranking annoyance, but choosing the safest release decision.

A compact bug card can capture the decision:

Build: RC-04
Repro: exact steps and configuration
Severity: Blocker / Major / Minor / Cosmetic
Player path affected:
Workaround: None / reliable / obscure
Fix risk: Low / medium / high
Decision: Fix / investigate / defer / close
Owner:
Verify in build: exact route that must pass

Verify the fix in the release candidate

A bug is not cleared because the developer says the code is fixed. Verify the affected player route in the packaged candidate.

Valve’s Steam build review documentation says submitted products must launch on supported operating systems, include supported features listed on the store page, and should be near-final when sent for review. Steam also documents beta branches for testing updates, letting teams test a specific build separately from the public version.

For a small team, use that separation to protect the candidate. After every approved blocker fix:

• build the exact candidate package;
• rerun the original reproduction steps;
• test the adjacent player path that could regress;
• record the verified build ID;
• reopen the bug if the packaged build still fails.

Do not reopen broad polish work because one blocker was fixed. If you already use a demo or release freeze, let triage decide which defects are allowed through that boundary.

A release build does not need zero known bugs. It needs zero unaccepted release blockers. Before your next candidate, run every open issue through the same five questions, record the decision, and retest only the fixes you deliberately admit. If you plan releases in PlayablePlan, add this blocker test to the release milestone so “ship” becomes an explicit decision rather than the moment the backlog finally looks quiet.