9.5 — Datasets: Insights from Playtest Data

Download the dataset. Grab playtests.csv — 32 rows and 14 columns. Every column is a variable: one thing somebody measured. Every row is one record: one run, by one tester. Open it in a spreadsheet and the row numbers down the left margin are the same ones the exam's 1-indexed lists use, so the file and the reference sheet count the same way.

#	Column	What it holds
1	section	Which part of the cave, 1 to 6. Six of them here — and the six are NOT the five named sections of your own gauntlet
2	run_id	Which run: R001 to R032, one row each
3	player_id	Which tester: P01 to P08
4	deaths	Deaths on this run, every cause added together — the column "which section is deadliest?" is really about
5	deaths_by_spikes	Deaths on this run caused by spikes
6	deaths_by_enemy	Deaths on this run caused by an enemy
7	deaths_by_fall	Deaths on this run caused by falling
8	time_seconds	Seconds spent in that section on that run
9	coins_missed	Coins the tester saw and did not get
10	jumps	Jump inputs pressed — how busy the section kept them
11	distance_to_boss_start	The same number on every row of a section, and never a different one. Check it
12	completed_boss	TRUE if the run finished, FALSE if it did not
13	rating	The tester's score for the run, 1 to 5
14	comment	The tester's own words. Three rows have none

Five things that are true of the whole file, before you compute anything. One cause of death leads all the others, and it is the cause the comments shout about — but not by the landslide they imply, and no section's deaths come near a majority of the file. Most of the runs finished the boss. One section takes more deaths than any other, and half of those are spikes. Three rows leave the comment column empty, which is a fact about the data rather than a hole in it — a blank is a value you have to decide what to do with.

And one warning before you compare this with your own notes. The six sections here are not the five sections your gauntlet had. Yours were named in 6.5 — the gap, the climb, the spike run, the soft gate, the end. This file numbers six parts of a whole cave and names none of them. Decide what a row is a row of before you average it, or you will average two different things and call the result a pattern.

Step 1 — eyeball then compute. Open the CSV in any spreadsheet tool (Numbers, Google Sheets). Predict three things from eyeballing, THEN compute them: total deaths per section (sort or sum), average time per section, and the completion rate (the completed_boss column: what fraction of the rows are TRUE?). A prediction next to a result is the whole scientific method in one spreadsheet — and the prediction is what makes a surprise visible instead of just a number.

Check your three predictions predict, then compute, then open this

Then compare. Every number here is two clicks away in your spreadsheet — what matters is which one surprised you, and why.

• Deaths per section: section 3 is the deadliest at 12, and half of those are spikes.
• Deaths by cause, whole file: 52 — 21 by spikes, 18 by enemy, 13 by fall. Spikes lead at 40%, which is still under half.
• Completion rate: 25 of the 32 runs finished the boss — about 78%.
• Average time per section: six numbers, not one — one per section, which is the point of a filter. Section 2's is worked in full in the key at the end of Step 3.

Step 2 — cross-tab questions. The interesting questions join columns:

1. Do the sections with the most jumps also have the most fall deaths? (jumps beside deaths_by_fall, section by section)
2. Do the rows that miss more coins rate lower? (coins_missed beside rating)
3. Which section is slowest per death — the section's TOTAL time_seconds divided by its TOTAL deaths? Add up both columns for a section, then divide. A high ratio means people spent a long time there and rarely died: is that a good section or a boring one? Argue it.
4. Of the runs that died to an enemy at least once, what fraction still finished the boss? (deaths_by_enemy above zero, then completed_boss)

Step 3 — aggregate like the exam. Work out the average time for section 2 the way the reference sheet makes you write it: a loop, a test inside it, and two counters. Two things the sheet does NOT give you: there is no AVERAGE function to call, and no one-line way to filter — you write the loop and the counters yourself, every time. And the sheet's lists start at 1, so column 1 is section and column 8 is time_seconds:

total ← 0
count ← 0
FOR EACH row IN runs
{
    IF (row[1] = 2)
    {
        total ← total + row[8]
        count ← count + 1
    }
}
average ← total / count

Check the loop against your spreadsheet — the four section-2 rows, the two counters they feed and the average they produce are in the key below. Then read the last line carefully, because it is the one line here that behaves differently on paper and in your game: on the exam / is real division even between two integers, so a total over a count comes back with its decimal intact, never as a whole number with the remainder thrown away. C# is the opposite — two ints divide and truncate — which is why your Unity code casts one side to a double.

Check your loop run it in the spreadsheet first

Then compare. If your counters disagree, the row you filtered on is the usual reason — column 1 is section, and column 8 is the time.

• Section 2's four rows: 172, 133, 228, 199 seconds.
• count finishes at 4; total finishes at 732.
• average ← total / count is 183.0 — a decimal, because the exam's / does not truncate.