- Electronics
- C++
- Game Design
GRID Arcade
The GRID (Gaming Retro Interactive Device) was a custom arcade I built in the fall of 2025 to develop my embedded systems skillset.
The Problem
In 2022, I built a small device for a game, A-Maze-ing Race. The original system was composed of a flimsy box that mounted a 32×32 LED matrix display with a single joystick as controls, connected to an Adafruit Metro M0 that ran game logic. The system was occasionally used to demo other projects (like a small simulation of Boids) that lived in separate codebases.
Why it fell short
This was frustrating to work with because:
- The control hardware suffered from noise due to vibration of the enclosure, which could cause loose connections in the wiring
- Physical hardware access meant opening the enclosure each time — adding wear-and-tear and slowing iteration
- Changing codebases introduced context-switching overhead
This translated to the greatest issue: my users found the experience interesting but unserious because of the lack of quality and slow updates.
The solution
Three years later, I set out to create a new, robust version that could be played over a much longer time by others without maintenance. This new version would be built with durability and development in mind, targeting a faster iteration process. Finally, the game needed to be updated to host my other projects which used the matrix.
Approach
Project Management
At the beginning of the project, Notion.so was used to create a project workspace to manage the project. Time was spent early on to draft detailed specifications so design decisions could be made with confidence. In terms of work process, I had experience working in an Agile team, so I went with a Kanban board that broke the tasks into milestones, stories and issues. This let me tackle the build with professionalism and pace as I targeted the end of fall in 2025 as a deadline.
Because of this advance planning, I quickly realized that the build had two parallel problems to solve:
- Better physical enclosure design and wiring around the hardware so that noise and entropy would be kept to a minimum
- Software architecture that enables easy context switching between demos and is not hardware dependent
Hardware
While the hardware was predetermined from the original project, the enclosure had to be upgraded from the worn-out box.
With the help of my mechanical engineer friend Herman, we specified the design of a new laser-cut enclosure, with the custom electronics from the original project inside. We wired the whole project and redesigned the wiring to be more robust and easily accessible. We set out building the enclosure as a cardboard prototype first, then fixed any issues we found, before we settled on the final body.
Software
After the build of the enclosure, I set to work improving the software. To develop the software without being blocked by hardware access, I created an SDL application that emulated the program by running the same C++ codebase at a fixed time-step. To enable easy context-switching for different demos, I built a whole C++ game engine — with the limited resources of the Metro M0 — to run multiple different "Scenes" that rendered different games.
This accelerated my process, and I was able to create new Scenes such as the game of Life and the classic Snake game. On top of this I managed to improve my controls, fix several nagging bugs, create a calibration stage, and implement persistent flash storage for long-term use and maintenance. Finally, this allowed for development to continue while users could keep playing the old code on the new enclosure.
Result
In essence, this project proved effective in several key ways:
- One codebase, two targets (hardware + emulator) — allowed for parallel development and usage
- Extensible architecture — creating a platform to host different games multiplied the power of my demos
- Hardware/software iteration + calibration — ensured a better developer and user experience
Because of our work ensuring designs were sufficient and iterating on the build, the assembly was completed on-time with only minor issues. The result was a satisfying physical enclosure that looked professional and polished.
We learned that a good advance-planning process was critical to the success of the build. The collaboration between me and Herman was instructive, as it taught me to define my specs early and consider buffers for the build process.
The creation of a software emulation was extremely helpful as it unblocked software development from hardware. I learned to use SDL applications running fixed-timing emulation as an effective tool for hardware development.