Unlike many capstone projects with a single measurable target, The SCavenger was ultimately judged by an experiential metric: fun. Early design work focused on what makes an “escape room in a box” engaging. I distilled our approach into three principles, each presenting unique challenges.

  1. The player should feel appropriately challenged. Players bring different levels of puzzle-solving experience, so the system needed adjustable difficulty without changing core gameplay. We implemented an on-demand clue system that lets players request progressively stronger hints when they get stuck.
Example Clue for Puzzle #1: It's Bright in Here!
Example player-requested clue for Puzzle #1
  1. The interface should be intuitive. We evaluated several input schemes (including a joystick) and ultimately chose a four-button model: Power, Next, Back, and Clue. Supporting dialogue, prompts, clue confirmation, and multi-step clue navigation within this constraint required a carefully designed finite state machine to keep behavior predictable and prevent dead ends.
Finite state machine governing clue navigation using a four-button interface
Finite state machine governing clue navigation using a four-button interface
  1. The player should feel emotionally connected to the story. Delivering narrative on a microcontroller with only a 64-character LCD and a buzzer required deliberate pacing and expressive feedback. I wrote a short narrative and implemented delivery using character-by-character text rendering paired with a narrator-associated tonal “voice signature” synchronized with on-screen text.
Demonstration of character-by-character text rendering with narrator-associated audio cues

Implementing this cleanly was more complex than it sounds: the LCD’s low-level command interface, unconventional memory addressing (rows mapped non-sequentially), and text-layout edge cases (word wrapping, line breaks, and responsive button handling during rendering) all had to be managed without breaking pacing or usability.