Escape room · physical computing
From first prototype to playtest
The question was simple: could the room know when you solved something? Not just a buzzer, but lights, audio, and props that stayed in sync through a real run.
The work crossed shop constraints, microcontroller wiring, and a small control layer we could change between playtests. I learned where to cut scope so the night stayed reliable.
This page stays open as the build changes. The aim is steady: players get clear feedback, operators can recover when something slips, and surprises feel fair.
- Role
- Interaction design, prototyping, software integration
- Focus
- Physical computing, game flow, UI for operators
- Client
- Academic / team capstone
- Timeline
- Multi-month build with iterative playtests
If you step away to try a build, come back afterward. Most of the lessons showed up in the messy middle.
Problem framing
What “good” meant for a mixed crowd
Rooms fall apart when feedback is vague. People should sense progress even when they are wrong. I tied each puzzle state to a clear sensory cue and avoided dead ends that read like bugs.
I wrote short scenarios for first-timers, enthusiasts, and a host who needs a clean reset when something fails. That set priorities for hints, logs, and recovery.
1. Audit the fantasy
List story beats and match each to a physical or digital beat. Cut what does not serve the arc.
2. Paper flows
Sketch layout and paths before hardware. Cheapest iteration is still on paper.
3. Risk register
Track power loss, noisy sensors, late groups. Give the host a fallback they can run in under a minute.
Systems and integration
Pieces that had to feel like one product
Integration meant spelling out contracts: what each sensor promises, how often state syncs, and what happens when a message drops. Small contracts made late-night debugging bearable.
Operator tooling mattered as much as the player UI. A plain dashboard to override state, replay audio, and log timestamps cut stress when runs went sideways.
Visual and spatial language
Materials that read in low light
Color and contrast carried meaning. The palette stayed warm next to physical props. Digital readouts stayed minimal so they did not fight the set.
Type and icons were picked for distance. If a label only works when you lean in, it is too quiet for a timed run.
Playtesting and iteration
Watching real groups instead of guessing
After each run I wrote a short note: what confused people, where time vanished, and what landed. The best fixes were small: reordering audio, tightening copy, one extra light pulse on success.
The hard part was saying no to new ideas until the core loop felt fair.
What changed afterward
Habits that lasted past this room
I grew skeptical of “wow” moments that need perfect timing. I care more about systems that fail quietly and give the host a path out.
Writing state rules earlier would have saved weeks. Later we were tracing rules that should have been explicit on day one.
What did I learn?
- Prototype failure before you polish the happy path.
- Treat the host as a primary user.
- Keep the story and the wiring diagram aligned; drift between them becomes 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.