Inspiration
We were inspired by the core promise of brain-computer interfaces: turning neural activity into fast, intentional communication. Instead of building a passive demo, we wanted to build something competitive and measurable. The hackathon prompt emphasized maximizing bitrate, so we designed a game that pushes both sides of the system at once: the decoder has to be accurate, and the player has to respond quickly under pressure.
Whack-a-mole felt like the right interaction pattern because it is intuitive, fast, and naturally maps to repeated discrete selections. It also gives immediate feedback, which is critical for BCI systems. We wanted the final experience to feel like an actual game, not just a lab tool with a score.
## What it does
BCI Whack-a-Mole is a timed game that measures how effectively a player can communicate through a BCI-style controller-decoding pipeline.
During gameplay:
- The system shows one blue target at a time on a controller UI.
- The player responds by moving the correct joystick direction or pressing the correct button/trigger.
- The game continuously tracks correct selections $S_c$, incorrect selections $S_i$, elapsed time $t$, and live bitrate.
- Mole and hammer visuals turn the selection task into a whack-a-mole game, with animated feedback on each hit.
- At the end of the timed round, the game reports the final bitrate in bits per second.
We use the achieved bitrate formulation:
$$ B = \frac{\log_2(N - 1)\cdot \max(S_c - S_i, 0)}{t} $$
where:
- $N$ is the number of possible selections
- $S_c$ is the number of correct selections
- $S_i$ is the number of incorrect selections
- $t$ is elapsed time in seconds
In our hard-mode game, all 16 controller classes are enabled, so:
$$ N = 16 $$
and the information per valid selection is:
$$ \log_2(15) \approx 3.91 \text{ bits} $$
## How we built it
We built the project as a full stack BCI game loop:
- A Python backend serves the training/testing web app and exposes APIs for session control, live decoder state, event logging, and QC artifact generation.
- A browser-based frontend renders the game UI, controller visualization, countdown, live bitrate HUD, and post-game summary.
- We used the controller channels as the behavioral ground truth:
- left stick: channels 64-65
- right stick: channels 66-67
- buttons/triggers: channels 68-75
- We converted the task from a fixed trial UI into a timed game mode with unlimited dynamically generated targets until the session clock expires.
- We added live state mirroring so the controller graphic continuously reflects the current decoded input.
- We tracked $S_c$, $S_i$, and $t$ live and updated the bitrate display every 0.5 seconds.
- We layered game feedback on top of the controller UI with blue targets, countdowns, mole overlays, and a hammer strike animation on correct hits.
- At the end of each run, we stop recording, save the event log, and generate QC outputs from the recorded data.
## Challenges we ran into
One challenge was turning a training-session interface into an actual game without breaking the underlying recording and evaluation pipeline. The original flow was phase-based and timer-driven, but the game needed to feel immediate and reactive.
Another challenge was defining the metric correctly. Bitrate is not just "how fast can someone press buttons." We had to make sure the live display reflected the actual achieved bitrate formula, including:
- the correct alphabet size $N$
- the penalty from incorrect selections
- elapsed time since gameplay actually started
We also ran into several UI challenges:
- keeping the blue target visible while also showing live controller state
- placing decorative mole art without covering the actual target
- making the hammer hit animation readable but not distracting
- surfacing bitrate prominently enough to matter, without pulling focus away from the game itself
Finally, there was a systems challenge in making the experience feel responsive while still preserving logging, timing accuracy, and end-of-session QC.
## Accomplishments that we're proud of
We are proud that we turned a neuroscience/decoder evaluation task into something that feels like a real game.
Specific accomplishments:
- A timed whack-a-mole style BCI game loop instead of a static trial demo
- Live achieved bitrate display based on $S_c$, $S_i$, $t$, and $N$
- Continuous controller-state visualization across joysticks, buttons, and triggers
- Immediate target progression on correct hits for a fast-paced experience
- End-of-session reporting with highly visible final bitrate
- Integrated recording and QC so the game is still useful as an experimental tool, not just a visual prototype
We are especially proud that the project keeps the scientific metric central while still being playful and intuitive.
## What we learned
We learned that maximizing bitrate is a joint optimization problem between human interaction design and decoder performance.
A few concrete lessons:
- Feedback latency matters a lot. Even small delays between a correct action and the next cue noticeably hurt flow.
- Visual clarity matters as much as model accuracy. If targets are hard to parse, effective bitrate drops even with a good decoder.
- Penalizing incorrect selections changes design incentives. A high-speed interface is only valuable if the player can remain accurate.
- The right game mechanic can make technical evaluation easier. Whack-a-mole made it much easier to reason about discrete selections, timing, and scoring.
More broadly, we learned that BCI systems should not just be measured in isolation. The task design, UI, and feedback structure strongly affect the final communication rate.
## What's next for BCI Whack a Mole
Next steps for the project include:
- replacing controller ground-truth input with fully decoded neural predictions during gameplay
- comparing multiple decoder architectures and evaluating their achieved bitrate in the same game
- adding adaptive difficulty based on player speed and error rate
- experimenting with larger selection alphabets to push bitrate higher
- adding richer analytics, including confusion matrices and per-class accuracy
- exploring cooperative and competitive multiplayer BCI game modes
- refining the game art and feedback so it feels even more polished and replayable
Longer term, we want to use BCI Whack-a-Mole as both a benchmark and a design pattern: a way to make BCI evaluation fast, quantitative, and engaging at the same time.
Log in or sign up for Devpost to join the conversation.