A checklist before you share a prototype

You are about to hand a prototype to someone who does not live in your project folder. They do not know the secret key, the correct scene, or that the game only runs if a specific headphone is unplugged. A checklist will not make the toy good. It will make the toy visible. Feedback on a build they could not start is feedback on your zip file, and you will mistake it for a design opinion.

The build they actually launch

Package a build. Do not send the project and a paragraph about which engine version you believe you used. A stranger's machine is not your machine. Start the build on a computer that is not your authoring machine if you can, or at least in a clean user account. Version control for a student game project should already hold the source. The share is a build, with a note of the date, so you know which snapshot the comments refer to. A link to a folder named NEW is not a version.

The first minute, unassisted

Write the controls in the place the player is looking, not in a chat message above the download. Bindings, the goal of this prototype, and how to restart: three lines. If you need more, the prototype is asking them to attend a lecture. Common mistakes in a first playable build covers the deeper cut. This list is the doorway. Launch it yourself and put your hands in your lap. Anywhere you feel the urge to speak, the build needs a fix or the note needs a sentence.

Saves, crashes, and the way out

Tell them if progress will not save. A prototype may honestly forget. A prototype that claims to save and deletes the hour is a betrayal. Include a quit that does not require the task manager. Decide the window resolution instead of spawning a giant borderless surprise on a laptop. UI readability in small indie games is worth a glance even now. If the goal text is the same color as the floor, you are about to receive notes about graphics when the camera was the problem.

What you ask them to tell you

Ask one question. Was the jump readable. Did you understand the loss. Where did you get bored. A form with thirty items produces shrugs. Leave room for the comment you did not expect, and do not argue in the moment. You are collecting evidence, not defending a weekend. Thank them. If they could not play because of a crash, that crash is the entire report. Fix it before you collect a second opinion about balance.

After they leave

Label the notes with the build date. Change one thing before you send the next build, so you know what the new notes are about. Delete debug spam you only left in because you were afraid. A prototype can look unfinished and still feel intentional. An asset pipeline from file to playable is how the next share stays replaceable. The checklist is done when another person can reach the toy without you in the room. That is a higher bar than it sounds, and it is the bar.

Frequently asked questions

Can I just stream the prototype instead of sending a build? You can, and you will talk over it. A build they play alone gives you better silence. A stream is a performance. Know which one you wanted.

Should the prototype include a tutorial level? Include the minimum that prevents a stuck player. A tutorial that is longer than the toy is a different project. Three lines and a kind restart beat a guided tour.

What if the engine's license forbids sharing builds? Read the current terms before you send anything. If you cannot distribute, run the playtest on a machine you control and say so. Do not assume classroom use covers a public link.