# 5. Worked Example Classroom Playtest Loop Part of [[Playtest Telemetry and Heatmaps]]. Previous: [[4. Editor Heatmap Window]]. Next: [[6. Telemetry Pitfalls and Privacy]]. > [!warning] Code not compiled > The C# here is unchanged from parts 2 to 4. The PowerShell script below has not been run against a Quest; `adb` paths are the standard Android app-specific storage path and should be checked on your headsets. ## 5.1 The level Use any short level with a clear route and at least one hazard. A good candidate: the spike / key / door / checkpoint course from [[5. Worked Example Spike Key Door Checkpoint]], blocked out with the landmark from [[5. Worked Example Landmark Blockout]]. Three checkpoints, one optional "finger" with a pickup reward. Write the three playtest questions from part 1 on the board, for example: 1. Where do players die, and is it the hazard we intended? 2. Does anyone take the optional finger? 3. Where do players stop and look around? ## 5.2 Instrument (10 minutes) 1. Add **PlaytestTelemetry** to the bootstrap scene; set `buildLabel` to `A`. 2. Add **TelemetryPathSampler** and **TelemetryEventHooks** to the player (part 3). For a VR build, sampler `target` = Main Camera. 3. Wire death, the three checkpoints (`CP_01`..`CP_03`) and the finger pickup (`finger_reward`). 4. Play once in the Editor; open the Heatmap window and confirm your own run shows up. ## 5.3 Run the playtest (20 minutes) - **Desktop builds:** each lab PC writes to its own `%userprofile%\AppData\LocalLow\<Company>\<Product>\Telemetry`. Ask each tester to copy that folder into a shared drive folder named after their **seat number**, not their name. - **Quest builds (Unity 6.3 LTS):** sideload the same build to each headset ([[4.Quest 2 Testing and Deployment]]). Each headset writes to its own app storage. Rules for the room, straight from good playtest practice (not from Rogers, whose book is light on method): - Do not explain the level. Do not answer "where do I go?" Write the question down instead; it is data. - One observer per tester takes paper notes with timestamps (the CSV `time` column lines up with a phone stopwatch started at launch). - Five minutes per tester is enough for a gray-box. ## 5.4 Pull logs from every headset Connect the headsets by USB (or use `adb connect` over Wi-Fi as in [[4.Quest 2 Testing and Deployment]]). This PowerShell script pulls each headset's `Telemetry` folder into a per-device subfolder. Set `$package` to your **Package Name** from Player Settings. ```powershell # pull-telemetry.ps1 - pull PlaytestTelemetry CSVs from every connected Android/Quest device. # Not run against a Quest yet. Requires adb on PATH (Android SDK Platform-Tools). param( [string]$Package = "com.yourschool.playtestlevel", [string]$Destination = "C:\Playtests\$(Get-Date -Format 'yyyy-MM-dd_HHmm')" ) New-Item -ItemType Directory -Force -Path $Destination | Out-Null $lines = & adb devices $serials = @() foreach ($line in $lines) { if ($line -match '^(\S+)\s+device ) { $serials += $Matches[1] } } if ($serials.Count -eq 0) { Write-Warning "No devices in 'adb devices'. Put the headset on once and accept the USB debugging prompt." return } $index = 1 foreach ($serial in $serials) { # Folder name is a seat-style number, not the serial, so the folder does not identify a device owner. $target = Join-Path $Destination ("headset{0:D2}" -f $index) New-Item -ItemType Directory -Force -Path $target | Out-Null $remote = "/sdcard/Android/data/$Package/files/Telemetry" Write-Host "Pulling $remote from device $index into $target" & adb -s $serial pull $remote $target $index++ } Write-Host "Done. Point Tools > Playtest > Telemetry Heatmap at $Destination" ``` Write the serial-to-headset-number mapping on a sticky label on each headset (Marshall's class set is about five Quest 2s), so `headset03` always means the same physical device. ## 5.5 Read the data (15 minutes, whole class) 1. **Browse** the Heatmap window to the `C:\Playtests\...` folder (it searches subfolders). **Load**. 2. `death`, blur 1: is the hottest cell the hazard you meant to be hard, or something accidental (a jump just past the metrics from [[2. Movement Metrics Asset]], a fall off an unrailed edge)? 3. Filter **Label contains** `Spike`: are spike deaths spread across the trap (fair, players misjudge timing) or piled at its entrance (unfair, the telegraph is not readable; see [[1. Telegraph-First Hazard Design]])? 4. `idle`: idle heat at a junction means the next goal is not visible. That is a landmark problem ([[3. Weenies Landmarks and Lighting as Wayfinding]]). 5. `pickup`, label `finger_reward`: how many sessions reached it? If almost none, the finger is either invisible or the reward is not worth it (Level 9: every finger needs a reward; Level 13: the best rewards are hard won). 6. Open one session CSV in a spreadsheet and compute **time between checkpoints**. A section that takes three times longer than the others is Rogers' *"too long"*. ## 5.6 Change one thing, then compare Pick **one** change per problem (move the spike telegraph earlier, add a light on the landmark, widen the gap tolerance). Build again with `buildLabel = B`. Run the same five testers (or a fresh five; fresh testers are better for "where do I go" questions). Load both folders into one parent folder, then use **Build label contains** `A` and `B` to flip between them. Note the counts on the top cells before and after. That before/after pair, with a screenshot of each, is a solid evidence slide for a Level 18-style pitch ([[Level Up! (Review)]]). ## 5.7 Checklist - [ ] Recorder in the bootstrap scene, `buildLabel` set - [ ] Sampler on the player (camera for VR) - [ ] Death, checkpoint, pickup hooks wired with stable ids - [ ] One test run visible in the window before the class starts - [ ] Testers' folders named by seat or headset number - [ ] One change per problem between builds A and B Next: [[6. Telemetry Pitfalls and Privacy]]