How to Review a Unity Project Before a Playtest

A Unity playtest can get derailed by surprisingly small setup problems.

A missing script on a prefab. A UI scene without an EventSystem. A startup scene that is not first in Build Settings. A camera with a second AudioListener. None of these issues are hard to understand, but they are easy to miss when a team is rushing toward a build.

Here is a practical review pass you can run before a playtest, milestone, or release candidate.

Start with the Build Path

Before reviewing individual scenes, check the path players will actually use.

Open Build Settings and confirm:

• the intended startup scene is first
• test scenes and scratch scenes are not included by accident
• required scenes are included
• scene order matches the loading code
• renamed or moved scenes are not leaving stale assumptions behind

This catches a lot of “the build starts in the wrong place” and “loading this scene fails only in build” problems.

Scan for Missing Scripts

Missing scripts usually come from refactors, package changes, deleted prototypes, or prefab variants that did not get cleaned up.

Check both scenes and prefabs. Scene-only review is not enough, because a broken prefab can stay hidden until someone instantiates it during a specific test path.

For each missing script, decide whether the object should be repaired, removed, or marked as known technical debt. The important part is to make the decision visible before the playtest starts.

Review Common Scene Setup Issues

Each playable scene deserves a quick hygiene pass.

Look for:

• missing or duplicate EventSystem objects in UI scenes
• duplicate AudioListener components
• disabled cameras that should be active
• placeholder names on important objects
• empty references on scripts that drive core scene behavior
• audio sources set to play without clips
• animation components with missing controllers

The goal is not perfection. The goal is to catch obvious setup drift before it becomes a confusing QA note.

Check Prefabs and Selected Folders

If the team has been working in one feature area, review that area directly.

For example, before a combat playtest you might review enemy prefabs, spawn point prefabs, combat UI, and the scenes listed in the test plan. Before a UI pass, you might review only menus, HUD prefabs, and flow scenes.

Focused review is usually better than a huge audit when time is short.

Compare Against a Baseline

Repeated review passes are easier when you can separate old known issues from new issues.

A baseline can be as simple as a previous exported report, a checklist snapshot, or a known-issues file. On the next pass, compare what changed:

• new findings that need attention now
• known findings that are still acceptable
• resolved findings that can be removed from follow-up

This keeps the team from rereading the same old warnings every time.

Export the Results

When you find issues, write them down in a format the team can act on.

Good review notes include:

• the scene, prefab, or asset involved
• the issue
• severity or priority
• who should look at it
• whether it blocks the playtest
• whether it is new, known, ignored, or resolved

Markdown is useful for chat and documentation. CSV is useful when the team wants to sort or import the results elsewhere.

Use a Review Inbox When the List Gets Long

Manual checklists work for very small projects, but they get noisy fast. A review inbox helps when you want to scan a scope, click into findings, mark items as reviewed or ignored, compare against a baseline, and export results without rewriting everything by hand.

Project Review is built around that workflow. It scans Unity scenes, prefabs, selected assets, selected folders, and Build Settings, then groups findings into an editor-only inbox for setup review.

That makes it a good fit for pre-playtest cleanup, milestone checks, and release prep where the question is not “is every line of code perfect?” but “what obvious Unity setup issues should we catch before the team loses time?”

A Simple Pre-Playtest Checklist

Use this as a short pass before your next test build:

1. Check Build Settings scene order.
2. Open the main playable scenes.
3. Scan for missing scripts in scenes and prefabs.
4. Check UI scenes for EventSystem and input setup.
5. Look for duplicate listeners, broken references, and stale placeholders.
6. Review the feature folders touched since the last playtest.
7. Compare findings against the previous known-issues list.
8. Export or share the final notes.

The value is consistency. If you run the same kind of review before every playtest, setup problems become easier to catch, easier to assign, and less likely to interrupt the test itself.