A release checklist for your first playable build

A prototype that runs on its creator’s machine is not yet a reliable shared build. Before sending it to a tester, make the journey from download to exit as clear as possible. The checklist should reflect the actual project rather than every feature a commercial release might eventually need.

Check the complete player path

Start from the packaged build, not the editor. Confirm that the player can enter the game, understand the basic controls, reach the intended endpoint, restart and quit. If an unfinished feature is visible, either make its status clear or remove the misleading entry point from this build.

Test a fresh start and a second run. If settings or progress are stored, check what persists. A prototype that always opens in your personal test state can confuse a new player before the first interaction.

Inspect the package

Include the files required by the export process and a short readme with the platform, controls, known limitations and feedback request. Avoid shipping source credentials, private notes or unrelated personal files. Keep the project source and the distributable package in clearly separate locations.

Record the build version and date. Put the same version in the readme and your own test notes. When someone reports a problem, you need to know which package they used. Do not reuse a filename in a way that makes two different builds indistinguishable.

Test outside the working folder

Copy the package to a clean location and launch it there. If possible, ask a trusted tester to try it on a supported system. A local copy test can reveal missing paths, but it does not establish compatibility with every machine.

Check screen size, text readability, keyboard navigation where applicable and basic audio controls. Make sure a player can leave the application without knowing a developer shortcut. Test the actual export you intend to share after the last change.

Ask for specific feedback

Include a short request such as “please note where the objective becomes unclear and whether restarting works”. Give the tester a suitable private route for reporting issues. Do not collect extra personal information just because a feedback form makes it easy.

Keep the released package unchanged in an archive while you work on the next version. That lets you reproduce reports and compare behaviour. A careful first release does not need to look finished; it needs to be understandable about what works, what is being tested and how the player can complete the intended experience.