Exercise 10 — Test & Iterate

GAME 1303-002 · Unreal Engine 5.8 · 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 packaged build that runs. Not a project — a build. If you don't have one, make it now; you cannot do this exercise without it.
• BP_PlaytestLogger from the helper pack
• Three testers. The people either side of you, and one more.

Part 1 — Instrument the build (10 min)

1. Add the logger

Drop BP_PlaytestLogger into your level. Set TesterName to tester-01.

Bind it so it records without you doing anything:

• BPC_Health → OnDeath → LogDeath
• BP_GameState → OnWin → LogWin
• BP_Checkpoint → OnActivated → LogCheckpoint
• Your level-end trigger → LogLevelComplete

2. Find the log file

Press Play once and confirm entries appear.

If your build of the helper uses the C++ SaveStringToFile node, the file lands in
MyGameName_Unreal/Saved/Playtests/. If you are using the no-C++ fallback, everything
goes to the standard log at Saved/Logs/<ProjectName>.log — open it and confirm your
lines are in there.

Do this now, not after your testers have gone home.

3. Package it

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

Packaged builds write their logs next to the executable, under
<Build>/<ProjectName>/Saved/Logs/, not in your project folder. Find that path
once now — students lose whole sessions to this.

✅ Checkpoint 1 — a running packaged 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

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:

1. "What were you trying to do when [specific moment]?"
2. "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:

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. Repackage and submit

Repackage 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

Troubleshooting

I can't find the log file.
In editor it's Saved/Logs/ in your project. In a packaged build it's <Build>/<ProjectName>/Saved/Logs/ — beside the executable, not in your project.

The log is empty.
Nothing is calling it. Confirm the dispatchers are bound with explicit Bind Event nodes, and that BP_PlaytestLogger is actually placed in the level.

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: BP_PlaytestLogger → LogCustom ("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.