Exercise 10 — Test & Iterate

GAME 1303-001 · Unity 6.x · Week 14 — Tuesday, November 24
In class, 10:30 – 11:45 · 2 points · Submit by end of class

The skill

You cannot playtest your own game. You know where everything is, what every button does, and what you meant. You are the only person who will ever play it with that information.

Playtesting is the practice of getting information you cannot get any other way. It has one rule, and the rule is hard:

Say nothing.

Not "try pressing space." Not "oh, that's a bug." Not even "hmm." The instant you help, you have replaced the data you needed with data about how well you explain things.

Today you watch three people play your game, in silence, and then fix the most expensive thing they found.

By the end of the block you will have: three playtest sessions, a prioritized fix list, and one fix implemented and verified.

This feeds Milestone 5 — Game Build (Week 15), next week, worth 25 points. Everything your testers get stuck on, the grader will get stuck on.

What you need

A build that runs. Not a project — a build. If you don't have one, make it now; you cannot do this exercise without it.
PlaytestLogger from the helper package
Three testers. The people either side of you, and one more.

Part 1 — Instrument the build (10 min)

1. Add the logger

Empty GameObject → add PlaytestLogger. Set testerName to tester-01.

Hook it up so it records without you doing anything:

Health.OnDeath → PlaytestLogger.LogDeath()
GameStateManager.OnWin → PlaytestLogger.LogWin()
Checkpoint.OnActivated → PlaytestLogger.LogCheckpoint()
Your level-end trigger → PlaytestLogger.LogLevelComplete()

2. Find the log file

Press Play once. The Console prints the path. It lives in Application.persistentDataPath —

C:/Users/YOU/AppData/LocalLow/CompanyName/ProductName/

Open it and confirm lines are appearing. Do this now, not after your testers have gone home.

3. Build it

Into MyGameName/PC_Builds/Ex10/. Test that the build itself runs before anyone sits down.

✅ Checkpoint 1 — a running build that writes a log file.

Part 2 — Three sessions (35 min, ~10 min each)

4. Set up

Change testerName between testers, or rename the log file after each. Three sessions blurred into one file is three sessions wasted.

Have paper ready. You will write while they play.

5. The script — say exactly this and nothing else

"This is my game. Play it however you want. I'm going to be quiet and take notes — that's not rude, it's the exercise. Think out loud if you can."

Then stop talking. For ten minutes.

This is genuinely difficult. You will want to help within about forty seconds. Every time you don't, you learn something.

6. Write down only what you observe

Write this	Not this
"Pressed W three times at the first gap"	"Didn't understand the jump"
"Went left, came back, went left again"	"Got lost"
"Said 'wait, am I supposed to...' then stopped"	"Was confused"
"Died four times at the second hazard"	"Found it too hard"

Behaviour, not interpretation. You interpret afterwards; if you interpret during, you will record your theory instead of what happened.

Mark anything they do that you didn't expect with a star. Those are the valuable ones.

7. Two questions afterwards

Only after they stop playing:

"What were you trying to do when [specific moment]?"
"What did you think would happen when you pressed that?"

Do not ask "did you like it?" You will get politeness, which is worthless. Ask about intention and expectation; those are answerable and true.

✅ Checkpoint 2 — three sessions run, notes written as observed behaviour, logs saved.

Part 3 — Prioritize and fix (15 min)

8. Build the fix list

Every observation goes in one of four buckets:

Priority	Definition	Example
P0 — Blocker	A tester could not continue	Fell through the floor · no way out of a room · didn't know a control existed
P1 — Confusion	Two or more testers hit the same wall	All three tried to jump the gap you meant to be dashed
P2 — Friction	Slowed them down but they got through	Menu button too small · unclear which door is next
P3 — Polish	You noticed; they didn't mention it	Animation pops · sound slightly too loud

The rule: two or more testers hitting the same thing is a design problem. One tester hitting it might be that tester. That distinction is the whole value of testing three people rather than one.

9. Fix the top P0

One fix. Implement it now, in class.

Then verify it: play through the exact sequence that broke, and confirm it no longer does. An unverified fix is a rumour.

If you have no P0 — genuinely possible, and good news — fix the top P1 instead and say so in your notes.

10. Write it up

Docs/Ex10_notes.txt:

Testers: 3   Build: Ex10   Logs: 3 files attached

OBSERVED
  T1  0:20  walked past the key, reached gate, wandered 40s, quit trying
      1:30  died 3x on hazard 2, then stopped attempting the dash route
  T2  0:18  same — walked past the key
      0:55  found key by accident on the way back
  T3  0:22  same — walked past the key
      2:10  finished, 4 deaths total

FIX LIST
  P0  none — nobody got permanently stuck
  P1  All 3 walked past the key. It is behind the player's entry
      direction, so it is literally off-screen when they pass it.
  P1  T1 and T3 both tried to JUMP hazard 2 rather than dash. My
      teach beat for the dash is before the first checkpoint and
      both had forgotten it by then.
  P2  T2 said the pause menu font was hard to read.
  P3  Landing dust plays one frame late.

FIXED TODAY: the key placement (P1, hit by 3/3).
  Moved it 4 units right, into the entry sightline, and tinted it the
  same red as the gate.
VERIFIED: replayed the opening 6 times from a cold start. The key is
  now visible in the first frame after entering the room.

NEXT: move the dash teach beat to just before hazard 2.

✅ Checkpoint 3 — prioritized fix list, one fix implemented and verified.

Part 4 — Submit (5 min)

11. Rebuild and submit

Rebuild with the fix into PC_Builds/Ex10/.

Zip as lastname_ex10.zip: the build, three log files, and Docs/Ex10_notes.txt.

Canvas → Assignments → Exercise 10.

Rubric — 2 points

Criterion	Pt	Met when
Implementation	1	Build runs and is instrumented · three sessions run with three log files · one fix implemented and the rebuilt build contains it
Design decision	1	Notes record observed behaviour rather than interpretation · fix list prioritized P0–P3 · the chosen fix is justified by how many testers hit it · fix verified by replaying the broken sequence

Troubleshooting

I can't find the log file.
Right-click PlaytestLogger in the Inspector → Print Log Path, or read the Console line on Play. In a build it's under AppData/LocalLow/<Company>/<Product>/.

The log is empty.
Nothing is calling it. Confirm the UnityEvents are hooked — both an object and a function.

I couldn't stop myself helping.
Everyone struggles with this. Sit slightly behind them and physically write while they play; having a pen in your hand makes silence much easier.

All three testers did completely different things.
That's real data — your game may not be communicating any intended path. Look for what they all didn't do.

Nobody found any problems.
Almost certainly you helped, or they were being kind. Ask the two questions in step 7; expectations reveal what politeness hides.

If you finish early

Fix your second P1 and verify it too.
Log a custom event at the point testers hesitated: PlaytestLogger.Log("entered room 3"). Timestamps turn "it dragged a bit" into a number.
Test one more person who has never seen a game like yours. They find different things, and usually more important ones.

Before next week

Week 15 is Milestone 5 — Game Build, worth 25 points — a quarter of your course grade.

Work your fix list in priority order. The 8 completeness points are the ones to protect: if you are behind, cut content until what remains is finishable. That is the correct decision and it is worth more than anything else you could do with the time.

The last honest question: can someone finish this without me in the room? You now have real evidence either way — you watched three people try.

Read milestone-5-game-build.md and run the ⑦ Game Build tab of the course checklist.