Project Zero (Discovery Project)
I wanted to learn hardware, so I did I took this project that's been in the back of my mind for a while and make it a crash course into electronics.
Project Zero is a 3×3 grid of light-up buttons that plays four games. Thus far, this page covers Phase 1: getting a fully working prototype onto a breadboard, and the pile of small disasters I learned from along the way.
Project Zero
Tic-Tac-Toe Demonstration
Memory Demonstration
Reaction Demonstration
Jam Demonstration
The Idea
Nine buttons. Nine RGB LEDs. One speaker. Four games:
Tic-Tac-Toe: two players, blue vs red, the winning line flashes
Memory: a sequence lights up, you play it back, it gets longer and faster until you slip up
Reaction: targets pop up for 30 seconds; green scores, purple deducts, red ends it instantly
Jam Session: every button is a note in a pentatonic scale, so even mashing sounds vaguely musical
The one rule I had in mind: orientation shouldn't matter. Pick the device up any way round and it functions normally.
Components
I made a point of wiring every component alone before adding it to the grid. One LED, one button, one buzzer. Prove that I understand the single case, then scale to nine. It felt slow. It was actually the fastest thing I did, because when nine of something misbehaved, I already knew one of them cold.
The microcontroller: ESP32I'd used an Arduino Uno before, so the comfortable move was to use it again. I went with the ESP32 instead: more GPIO pins and it's closer to what real embedded projects run on. It turned out different in ways the tutorials gloss over. It runs on 3.3V instead of 5V, and several pins have boot-time jobs that make them misbehave if you use them casually. That difference bit me more than once, but every time it did, I learned something the Arduino would have hidden from me.
The LEDs: common cathode RGB.RGB was non-negotiable. RGB LEDs come in two configurations: common anode (all three colors share a +) and common cathode (all three share a ground). I chose common cathode because it matches how I ended up driving the grid. Each LED's shared pin becomes the thing I switch on and off, and having that be a ground line made the multiplexing logic line up cleanly.
The buttons : tactile switches + diodes.Nine buttons wired the obvious way would eat nine pins I didn't have. So they're wired as a matrix, which raised a problem I didn't expect: the ghosting effect. A diode on each button is a one-way valve for current. Without them, pressing three buttons that share rows and columns creates an unwanted paths, and the board reads a fourth "ghost" button nobody touched.
The passive buzzer. That's the whole reason Jam Session exists and the reason every game can have its own little jingle.
The unglamorous but essential: 220Ω resistors to keep the LEDs from drawing too much current, a breadboard, and a small mountain of jumble jumper wires.
Multiplexing
Nine RGB LEDs need three color channels each, that's 27 wires for the lights alone, before introducing buttons. ESP32 doesn't have 27 spare pins, and even if it did, my sanity doesn’t.
The fix is multiplexing, and this is where my current class, ECE 2020, stopped being abstract. We'd covered controlling many outputs with far fewer control lines, and here was the exact same idea sitting on my desk in wires. Instead of lighting all nine LEDs at once, I light one at a time and cycle through them fast enough that your eye sees a solid image.
That collapsed 27 pins into 12. Seeing a lecture concept turn into a working grid of lights was easily the most satisfying.
Where it got humbling
I'm keeping this section honest because the debugging WAS the learning. A clean "and then it worked" story would be a lie.
The colors were all wrong. Asking for red gave me cyan; asking for blue gave me yellow. Turned out I'd inverted the logic on the wrong half of the circuit, a copy-paste of a fix that was right for one part and wrong for another. Lesson: understand the fix, don't just paste it.
One LED was mysteriously dim. I swapped the LED. Still dim. Swapped it again. Still dim. I went through the LED, the resistor, and the breadboard socket before finding the actual problem. I’d never told the code which pin that LED was on. The symptom sat in the hardware; the bug sat in the software. Lesson: when something survives a component swap, check the code first.
Why the buttons are in single file, not a grid.Look at the prototype and you'll notice the nine buttons sit in a single row, nowhere near their LEDs. Looks wrong for something called a "3×3 grid." I had to pivot though. A tactile button has to straddle the breadboard's center gap to work. So all nine buttons have to line up along that one gap. They can't sit in a 3×3 shape and they can't sit next to their LEDs. It doesn't matter functionally, but it's a limitation I had to work around.
Button reads nothing. Wired up a button, pressed it, and got nothing. Or it read as pressed forever. A tactile switch has four legs in two pairs. Wire across the wrong pair and the button is either always-on or does nothing. The pair you actually want is diagonal. Once I figured that out, the rule was dead
That whole stretch reinforced the biggest lesson of Phase 1: the symptom rarely points at the cause. A dim LED turned out to be a missing line of code. Silent buttons turned out to be a misunderstanding of how breadboard rows connect. Learning to distrust the obvious explanation was worth more than any single fix.
Software
Once the hardware was done and dusted, software needed to work with the same wiring.
Tic-Tac-Toe and Jam Session share zero game logic but run on the exact same plumbing. So good architecture is really important.
The menu solves the orientation rule too: hold the center button, and the four corners light up in each game's color. So it works no matter which way you're holding it.
Skills:Multiplexing: driving many outputs from few pins by cycling fast (thanks, ECE 2020)
Matrix wiring + diodes: nine buttons over six pins, no ghosting
LED behavior & current limiting: why blue needs more than red, why duty cycle changes brightness
Microcontroller GPIO Datasheet: boot pins, input-only pins, 3.3V logic
Future Work
As a good, true academic, I’ll throw everything in the future work section.
Phase 1 is a working prototype. From here:
Phase 2 — Enclosure & keycaps: 3D-print translucent keycaps so the light glows through — keyboard-style, but bigger
Phase 3 — PCB: design a printed circuit board, which also finally lets the buttons sit in a true 3×3 under their LEDs
Phase 4 — Battery power: cut the USB cord and voila, it’s commercially ready.
Takeaway
The games are fun. But the real lesson underneath them, that scaling a project is just a lot of small correct steps stacked patiently, is the part I'll actually carry into whatever I build next.