How to playtest a Unity game

To playtest a Unity game, ship the smallest slice that answers your question, get it in front of testers with the least friction possible (a WebGL build in the browser is usually the answer), and instrument the moments you care about so you learn what players did, not just what they remember. Unity's advantage over other engines here is that you can ask the player a question inside the game, at the exact second something happens, instead of hoping they recall it twenty minutes later.

This guide covers the Unity-specific parts. For the session design underneath it, read how to playtest your indie game first.

WebGL or a desktop build?

This decision has more effect on your results than anything else on this page, because it decides how many invited people actually play.

My rule: if the question is about clarity, onboarding, first impressions, or store framing, ship WebGL even if you have to strip half the content to fit. If the question is about performance, save files, or a two-hour session, ship desktop and accept a smaller sample.

Trimming a Unity WebGL build so people wait for it

• Set compression to Brotli and make sure your host serves the right Content-Encoding header.
• Strip engine code (IL2CPP with managed stripping on high) and cut unused packages from the manifest.
• Turn on Addressables or at least move the test slice into its own scene so you are not loading the whole game.
• Compress textures properly for web, and drop audio to a format and bitrate that is not carrying your build.
• Put a real loading screen in front of it with a progress bar. Silence during a long load reads as broken.

You do not have to host the build yourself if you do not want to. A Unity WebGL build on itch.io can be pointed at directly, and PlayProbe can embed a WebGL build or simply redirect testers to an itch.io page, a Steam Playtest, or any URL, with an optional session timer.

What should you instrument in a Unity playtest?

Surveys tell you what players thought. Instrumentation tells you what happened. You need both, and the second one is where Unity earns its keep.

In-game events

Log a custom event at the moments that would change your design if they went wrong. A short, opinionated list for most games:

• The player performs the core verb for the first time (jump, shoot, place, trade).
• The tutorial or first objective completes.
• Each death or fail state, with the cause.
• Each level or chapter boundary.
• The first time each major UI screen opens.
• Any optional content being discovered.

That is usually eight to fifteen events. Resist the urge to log everything, because a hundred event types produce a dashboard you never read. Name them consistently (tutorial_complete, boss_defeat, shop_open) so they group cleanly.

The single most valuable thing this gives you is a drop-off picture. When you can see that seven of ten sessions ended between level_1_start and level_1_complete, you no longer need anyone to describe the problem to you in words.

FPS and crashes

Frame rate is one of the few things testers systematically fail to report. People assume a stuttering indie build is normal and say nothing. Capturing average and minimum FPS per session, alongside crash and exception data, turns "it felt kind of janky" into a specific scene and a specific machine.

The PlayProbe Unity SDK captures FPS and crashes automatically once it is installed, along with the custom events you log, and it ties all of that to the same session as the survey answers, so you can look at one tester's answers and their telemetry together.

Mid-game surveys: the part you can only do in-engine

Here is the pattern that changed how I run playtests. Instead of collecting all opinions at the end, you attach a one-question survey to an in-game event, and it appears in the moment.

A player dies to the same boss three times. On the third death, a small panel appears: "Did that feel fair?" with Yes and No. They answer in a second and carry on. You now have an emotional reading taken at the peak of the frustration, not a sanitised memory of it collected after they finally won and felt good about themselves.

Post-session surveys are systematically biased toward how the session ended. Mid-game surveys are not, and that is the whole argument.

Practical rules I follow:

1. One question per trigger. Two is already an interruption.
2. Three or four triggers per session, maximum. Beyond that testers start resenting the panel and answering to dismiss it.
3. Never during active input. Fire on death, on level complete, on menu open, on idle. Never mid-fight.
4. Use fast formats. Yes/No and emoji scales are answered honestly at speed. Save open text for two or three triggers where you genuinely need words.
5. Pause if your game is real-time. If you cannot pause, only trigger in safe states.
6. Trigger on state, not time. "Sixty seconds in" hits ten different points in ten different sessions. "Third death on the same encounter" hits the same experience every time.

There is a full list of trigger-and-question pairs in playtest survey questions that get real answers.

In-game feedback the player initiates

The other half of in-the-moment feedback is letting the player raise their hand. A persistent feedback button in the corner, which captures a screenshot along with whatever they type, turns "there was a weird floating tree somewhere in level 2" into an image with the exact spot in it. PlayProbe's Instant Feedback does this from inside the game, and answers can carry tags so you can group the pile afterwards instead of reading it linearly.

Bug reports collected this way are dramatically cheaper to reproduce than bug reports collected from memory an hour later.

Setting up a Unity playtest end to end

1. Pick the question. One, written down. Everything else serves it.
2. Cut the slice to roughly fifteen minutes and build it for the platform that matches your question.
3. Install the SDK and log your events. Start with the eight to fifteen listed above.
4. Attach mid-game surveys to three of those events. The ones nearest your question.
5. Write a short pre-survey (genre experience, platform, expectations) and a post-survey of five to eight questions.
6. Turn on screen recording if you want to watch the sessions rather than infer them. PlayProbe records the session in the browser on the Pro plan, stored for thirty days and visible only to you.
7. Publish the test as unlisted while you run one session yourself, end to end, exactly as a tester would.
8. Share the link. No account, no download on their side.
9. Read the first two sessions before the rest arrive, and fix anything blocking so later testers reach new ground.

Step seven is not optional. Playing your own test as a stranger catches the broken embed, the missing question, and the survey that fires during the boss.

Reading the results

Look at them in this order, because the order stops you from rationalising.

1. Drop-off by event. Where do sessions end? This is your hardest fact.
2. Time between key events. A tutorial you designed for ninety seconds that takes four minutes is a finding regardless of anyone's rating.
3. Mid-game answers. These are your emotional truth, taken in the moment.
4. FPS and crashes. Rule out technical causes before you redesign a system that was only failing because it ran at 12 FPS.
5. Post-session survey. Now the opinions, read in the context of everything above.
6. Recordings, selectively. Watch the two sessions that ended earliest and the one that ended latest. Not all of them.

If a mid-game answer and a post-session answer contradict each other, believe the mid-game one. The player was closer to the truth then.

Does this work if you are not on Unity?

Most of it, yes. The session structure, the survey design, and the WebGL friction argument apply to Godot, GameMaker, Unreal, or a hand-rolled engine. Because PlayProbe is link-based, testing a non-Unity game works the same way for the tester: one link, browser, no account. What you give up without the SDK is the in-engine layer, so the mid-game questions, FPS, crashes, and in-game events. Screen recordings plus a well-timed post-survey cover a surprising amount of that gap.

You can see what a live test looks like from the tester's side on the open playtests page, and if you need players in the first place, how to find playtesters for your indie game is the companion to this guide.

The Unity SDK sits on PlayProbe's Pro plan at $19 a month, but the link-based playtest, the pre and post surveys, and the results dashboard are all on the free plan. Start there, get one round of sessions in, and add the in-engine layer when you know which moment you want to be standing next to.