A 2D endless runner in a flooded Toronto
Dive, jump and slash through the drowned city, then return to a subway-car hub full of characters. Built by The Doom Collective, a team of five, over a full school year.
Overview
- A cybernetic diver completes requests for the survivors of a flooded Toronto, swimming and running through the city and fighting with a hockey stick.
- Between runs, a subway-car hub lets players talk to a cast of NPCs: a mailman who hands out the quest, a horse who is there purely for comic relief, a fan and more.
- Fully playable from the start screen to quest completion, and released on itch.io.
- Built by The Doom Collective, a team of five, over a full school year.
Role & Impact
- Feature designer: I came up with mechanics and built prototypes to show the team.
- After playtests I proposed improvements based on player feedback and telemetry.
- I took part in running the structured playtests and in the playtest report that came out of them.
Problem
- An endless runner lives or dies on responsive movement and fair difficulty, and our game also mixed a story hub with the runner.
- Players were failing runs and getting stuck between sections, and intuition alone couldn't tell us why. We needed evidence.
What I Built
The game loop
A run, a story hub and a way back, designed so a player is never stuck. Click any step to watch it.
See it play
Seven short clips from the build, plus a full run. Pick one from the list; each has sound and its own controls.
Start screen to quest completion
A complete session: talk to the mailman in the hub, take the quest, run the flooded city, and finish it.
Full run
The run
The hub
The hub: story between runs
A flooded-Toronto subway car where most of the game's characters live. Click an image to zoom.
Between runs the player returns to a subway car that doubles as a hub. A Talk prompt hovers over every character, and a PLAY button on the doors sends the player back out.
- The mailman hands out the quest through branching dialogue
- The horse is there purely for comic relief, with its own "adjust language protocol" gag
- Other passengers, such as the fan, fill the car with personality
- Prompts are consistent everywhere, so players learn the hub in seconds
Playtest changes
How the report changed the dialogue.
Playtest buildRecommended‹ ›
Dialogue choices, before and after the playtest report
Testers re-entered conversations and clicked the next-dialogue arrow repeatedly. The recommendation gave the intended path a visual hierarchy, with icons for choices that end the conversation. Drag the bar to compare.
How we measured it
Playtesting was part of the design process, not a final check.
Telemetry
Run duration, failure points and inputs tracked in Excel, so we could see where and why players died and tune jump timing and obstacle spacing.
Hub click heatmap
Unity click data exported to Excel and overlaid on the hub, to check whether NPCs were easy to find.
One session ID
Every playtester got an ID that linked their video recording, their telemetry and their survey answers, so each finding could be traced to evidence.
Playtest Report
Testers played through the first quest in person, then rated the game from 1 to 7 and left short answers. The report combined those ratings with each tester's recording and telemetry to see what players understood, enjoyed and struggled with.
What we found
- Speed was the most confusing mechanic: 7 of 15 testers said they didn't understand it, and several asked for a tutorial.
- Players needed clearer guidance through dialogue. Almost everyone chose to help the mailman, but some re-entered the conversation several times to get there.
- The 'Back to game' button was confusing: three players were seen struggling once the mailman dialogue ended, and clicks piled up on the next-dialogue arrow.
- Diving was the best-rated mechanic for both understanding and enjoyment. Whether completing quests makes the game more fun stayed uncertain (Fisher exact test p = 43%).
What we recommended
- Add more signifiers for the speed system, such as a tutorial pop-up and a trail effect.
- Rename 'Back to game' to 'Play' and place it on the subway doors.
- Give the intended dialogue path a visual hierarchy, with icons for choices that end the conversation.
Feature pipeline
Prototype, show the team, collect feedback, iterate: a repeatable loop other features followed.
Long-term collaboration
Consistent communication kept a team of students shipping for months.
Evidence-led iteration
Helped run a repeatable playtest process, with session IDs linking video, telemetry and survey data, and turned the findings into concrete recommendations the team could act on.
Improvements & Results
- Clearer way back to the game The final build shows a PLAY button on the subway doors, in place of the 'Back to game' button that left three testers stuck.
- Signifiers for speed Speed scored lowest on understanding, so the report recommended a tutorial pop-up and a trail effect to show how speed builds.
- Better dialogue affordances Recommended a vertical hierarchy for the options, with icons for choices that exit the conversation.
- Tuned jumps and obstacles Telemetry showed where and why players died, which guided changes to jump timing and obstacle spacing.
What I learned
Data beats hunches, and players show you exactly where a design is unclear. Fail data and click heatmaps showed which obstacles and hub elements caused trouble, and the playtest report turned that into specific fixes: signifiers for speed, a clearer PLAY button and a guided dialogue path. A full year with the same team also taught me that consistent communication matters as much as the features themselves.