Escape room · physical computing
From first prototype to playtest
The question I started with was simple. Could the room actually tell when a team solved something? Not a single buzzer, but lights, audio, and props that stayed in sync through a full run.
The build pulled me across shop work, microcontroller wiring, and a small control layer I could change between playtests. Most of what I learned came from deciding where to cut scope so a run night stayed reliable.
I keep this page open as the build changes. The goal stays the same. Players get clear feedback, an operator can recover when something slips, and the surprises feel fair.
- Role
- Interaction design, prototyping, software integration
- Focus
- Physical computing, game flow, operator UI
- Team
- Student capstone group at Purdue
- Timeline
- Multi-month build with weekly playtests
If you step away to try a build of your own, come back after. Most of what I learned here showed up halfway through the project, not at the start.
Problem framing
What "good" meant for a mixed crowd
Rooms fall apart when the feedback is vague. I wanted players to feel progress even when they were wrong, so I tied every puzzle state to a clear sensory cue and cut the dead ends that read like bugs.
I wrote short scenarios for three people. A first-timer, an enthusiast who has done ten rooms, and a host who needs a clean reset when something fails. Those three set my priorities for hints, logs, and recovery.
1. Audit the fantasy
I listed the story beats and matched each one to a physical or digital moment. Anything that did not serve the arc got cut.
2. Paper flows
I sketched the layout and the paths before touching hardware. The cheapest iteration is still on paper.
3. Risk register
I tracked power loss, noisy sensors, and late groups, then gave the host a fallback they could run in under a minute.
Systems and integration
Pieces that had to feel like one product
Integration came down to writing contracts. What each sensor promises, how often state syncs, and what happens when a message drops. Small, explicit contracts are the only reason late-night debugging stayed bearable.
Operator tooling mattered as much as anything the players saw. I built a plain dashboard to override state, replay audio, and log timestamps, and it cut the stress every time a run went sideways.
Visual and spatial language
Materials that read in low light
Color and contrast had to carry meaning. I kept the palette warm next to the physical props and pulled the digital readouts back so they never fought the set.
I picked type and icons for distance. If a label only works when you lean in, it is too quiet for a timed run, so I sized everything for a glance across the room.
Playtesting and iteration
Watching real groups instead of guessing
After every run I wrote a short note. What confused people, where the time vanished, and what actually landed. The best fixes were small. Reordering an audio cue, tightening a line of copy, one extra light pulse on a success.
The hard part was saying no to new ideas until the core loop felt fair. I held that line more than once.
What changed afterward
Habits that lasted past this room
I came out skeptical of "wow" moments that only work with perfect timing. I care more now about systems that fail quietly and hand the host a clear path out.
Writing the state rules earlier would have saved me weeks. Late in the build I was tracing behavior that should have been written down on day one.
What did I learn?
- Prototype the failure before you polish the happy path.
- Treat the host as a primary user, not an afterthought.
- Keep the story and the wiring diagram aligned. Drift between them turns into invisible bugs.
Feedback from playtesters and teammates
The moments that felt magical were the ones where the room acknowledged what we tried, even when we were wrong.
When the dashboard was clear, resetting between groups stopped being stressful.
- Build
- Laolu James with the capstone team