My role
I implemented all game code for the team’s Windows puzzle release. My teammates created the visual assets, which I integrated into the game.
Microphone input and candle behaviour
Keep The Light On
I set two microphone thresholds to tell speaking from blowing, then used them to change the candle, wind and light radius. I programmed the movement, enemy behaviour and puzzle state for the Windows build. My teammates made the art.
- Role
- Sole Programmer
- Context
- Team project
- Status
- Released Windows build
My contribution
- Classified microphone samples with configurable speaking and blowing thresholds, then used those results to drive candle, wind and light-radius reactions.
- Connected movement, sprint and stamina to enemy patrol, chase and hiding behaviour.
- Implemented puzzle sequences and ScriptableObject-backed scene state, then integrated teammate-created visuals into the Windows build.
Design decisions
- Microphone input as interaction
- Speaking and blowing thresholds connect microphone input to candle, wind, and light-radius behaviour.
- Shared puzzle state
- ScriptableObjects carry puzzle and scene state across the compact game flow.
What was hard
- Connecting microphone input to readable gameplay reactions.
- Used speaking and blowing thresholds to drive candle, wind, and light-radius changes.
Outcome and evidence
The team published a downloadable Windows puzzle game with microphone-driven interaction and the connected enemy and puzzle systems.
- The source keeps microphone thresholds and scene/puzzle configuration in ScriptableObjects. The Windows build is publicly downloadable.
Team credits
- Other team members created the visual assets integrated into the released build.
What I learned
The microphone classification and the reactions consuming it needed distinct responsibilities. Configurable thresholds gave me a place to tune input without duplicating the puzzle rules.