Scope a playable experiment, observe versioned playtests and choose the next change using explicit work estimates, test records and build evidence.
Describe the player action, feedback and meaningful choice in a short design note. Choose an observable question such as whether players understand a risk-and-reward choice without coaching. State the target device, input method and intended players. List features deliberately outside this experiment; a prototype is useful when it informs a decision, even if it is discarded.
List the minimum tasks needed to start, play, reach an outcome and restart. Identify the riskiest dependency, then make a small technical spike before committing the rest of the work. Enter remaining task hours and genuinely available team hours in the capacity calculator. Record any additional work allowance explicitly and schedule reviews or waiting time separately.
Use readable placeholder assets and make failure and restart accessible. For a tile-based level, choose actual map and tile pixel dimensions and calculate the covering grid; account for partially used edge cells in the engine. Include a version label and simple controls screen so another person can run the build without the editor.
Give participants the same brief and record the device, build, task outcome, confusion and comments. Ask neutral follow-up questions after observing the attempt. Use named test cases for startup, the core action, ending and restart; record results and reproduction notes. If frame pacing interferes, convert the chosen FPS target to an interval and capture actual timings on the device.
Compare observations with the original question. Keep, revise or drop a mechanic with a written reason; split design uncertainty from a reproducible defect. Prioritize the next change and assign an owner. Repeat the same task after that change while keeping unrelated conditions stable.
Export a runnable build, test it outside your development folder and record its exact version, installation steps and known issues. Measure the real download size; use the build-size estimator only to compare explicitly measured components and packaging assumptions. Download the design note and matrix backup before closing these tools, then link those files from your own project record.
Draft and download the prototype question, observation log and next experiment.
Compare scoped work hours with explicit team capacity or observed team throughput.
Count a rectangular tile grid from map and tile pixel dimensions.
Generate named build, configuration and test combinations and record observed results.
Convert the chosen frame-rate target to a comparison interval.
Compare measured component sizes using an explicit packaging factor and overhead.
Loading your checklist…
Fill these fields from the actual experiment.
| Record | What to capture |
|---|---|
| Question | The player behavior or technical uncertainty under test |
| Conditions | Build, device, inputs, participant context and task brief |
| Observation | What happened, with a note or reproducible evidence |
| Decision | Keep, revise or stop; next experiment and owner |
Unity documents connecting its Profiler to a target build. Use the device and build conditions of your experiment when investigating performance.
Decide what observation will make the experiment useful before expanding the feature list.
Placeholder art still needs clear contrast, understandable controls and visible feedback.