Test the build players will receive. A game that runs in the editor can still ship with missing assets, broken old saves or a storefront description that promises more than the package delivers. Give the release candidate a stable identifier and a short test matrix before testing begins.
Aim for three useful results: a tested package, a known-issue list and a support record. Choose checks around the game's systems and promised devices. A large test suite that only repeats implementation details can leave the problems players will encounter untouched.
Freeze a candidate you can identify
Record the source revision, engine version, content version and intended targets. Build from a clean workspace, or document its state. Once testing starts, check the effects of any further changes; an unrelated edit can still affect the candidate you are preparing to ship.
Keep the package and its checksum with the release notes. Ask testers to name that candidate, their device and the route they followed. A corrected development build should never be mistaken for the package they actually tested.
Cover important routes and state
Make a matrix covering every ending, major exclusive route, threshold and required unlock. Test a fresh start, save/load around choices, restart and supported update states, including old saves. Include skip, history and rollback wherever the game provides them. A working ending does not excuse a broken scene unlock along the way.
Check repeated events and exits from unusual states. A scene can look fine while granting a reward twice or leaving a route flag inconsistent. Turn defects found during development into focused regression checks, so the same bug does not quietly return in the next candidate.
Verify the intended interaction
Ask a tester to navigate without coaching. Check dialogue pacing, what menus communicate, legibility, keyboard or touch input, focus and settings. Watch for places where the player cannot find the next action. Your explanation of a button will not be bundled with the game.
Test audio controls and any motion or playback settings. Include interrupted sessions and returns from the background where relevant. Check that accessibility options behave reliably through routes and the save system; seeing the right toggle on the settings screen is only the start.
Inspect packaging and external dependencies
Install or extract the distribution outside the source project, then launch it there. Check for missing files, file-permission problems, save-location issues and required runtime components. Verify that the package contains no development secrets or unnecessary source data.
For a browser release, serve the actual export from the intended hosting context. Check asset paths, storage behavior and slow or failed loads. For a download, test the delivery archive and installation instructions on the supported operating system. The package players receive belongs in the test, too.
Match the public description to the build
Describe the available content, supported languages, system requirements, edition differences and known limitations accurately. Review the channel's current publishing and AI disclosure requirements. Choose public previews that meet the channel's content rules.
Do not label a prototype a finished game or present an estimate as a measured requirement. Use representative screenshots, and identify editorial illustrations when you use them. Resolve the payment and content approvals needed for the actual distribution route before release.
Release with a recovery path
Archive the candidate, editable sources, rights register and test evidence. Publish clear version information, a support contact and known issues. Keep a previous usable release where the distribution agreement allows it, so recovery does not depend on reconstructing an old build from memory.
When a report arrives, reproduce it against the affected version before making broad changes to the project. Fix the cause, check related state and update the regression matrix. Good support means being able to explain which build changed, what the fix covers and what you verified.
Key decisions
- Give the packaged candidate a stable ID and test that package.
- Cover route boundaries, required unlocks and supported old saves.
- Check controls, delivery and the public description together.
- Archive the release and add fixed defects to the regression matrix.
Guide files
Release checklist ↓Test matrix ↓External model communities and publishing sites may contain explicit material. Source links open in a new tab; this guide does not load their previews.
Sources & further reading +
Last checked 5 October 2026.