Snapper
Snapper is a mechanical arcade machine based on Paku Paku by ABA Games (GitHub link) aka Kenta Cho. I first saw Paku Paku when it was posted to Hacker News as "1D Pac-Man" in January 2024. Paku Paku was so simple and fun to play that I immediately thought it would be a candidate for a future mechanical conversion. At that time though I was still working on Appybird so Paku Paku was on the back burner.
Appybird launched at EMF Camp 2024 and knowing that I need a two year window to build a game I was immediately thinking about what I might do for EMF Camp 2026. People came up with quite a lot of suggestions, but Paku Paku was always the one that I really liked. A few weeks after EMF Camp 2024 I already knew that I would try and do a Paku Paku conversion for 2026.
Building my mechanical arcade machines is a long project involving many practical, technical, and creative skills. Every step becomes its own project so hang-on for some details of this endeavour.
Getting Started
It took a while to actually start developing Snapper. Part of the delay was that I had other stuff going on, including a lot of updates to Lunar Lander. But, the main delay was trying to imagine the mechanical architecture which would make Paku Paku work.
On the web version of Paku Paku the characters can go off the end of the track and reappear on the other side. This seemed really difficult to achieve mechanically. Over several weeks I thought of many approaches that might work but they were all complicated. At one time my favourite approach involved having two identical models of each player, each one originating from a different end of the track. All the options were similarly messy.
Eventually I realised that a lot of the problems were solved if you make the track circular. But that would need some modification to the game play. The "tunnel" which the player uses to change ends of the track and escape the ghost would have to double-up as the place where the ghost goes to regenerate when it was caught. Would that make sense to the player? Could all situations be handled without the characters having to go past each other? I worked though this type of question in my head, building a mental model of how the game would work in a circular configuration and eventually decided it was worth a try.
Another question was how would the player view the circle? If the player viewed the circle from the edge then it would have a look similar to Paku Paku. I still think that might be a fun alternative, but eventually I decided that a top-down view of the circle would be easier to appreciate. With the change of design I wanted to apply a new name. My version is called Snapper after the BBC Micro game I played as a child.
With the bones of the game decided I started working on how to make the mechanism fit in 3D space. I wanted to make sure I could fit the characters, electronics, and drive mechanisms together without mechanical interference. I reused the basic mechanism from Appybird - each character runs on a large circular bearing with a friction drive from a stepper motor. To fit everything together the bearings are different sizes and on different planes creating a workable, but hard to visualise, 3D structure.
First 3D sketch of snapper showing the relationship of the main elements to help check 3D fit
Making the Mechanics
I started the build by experimenting with how to animate the characters. My original idea was that each character would have a small, separate, moving display showing an animation. It seemed like a fun joke to have the video game characters on displays but to have the displays moving. Ultimately though, I decided that wasn't going to be very visually interesting and instead went with 3D printed mechanical characters driven by servo motors. The final animated characters are super cute and fun but there were many redesigns, including having to upgrade the servos to a larger size while keeping the character footprints identical.
The next step was to make the characters move as a system. This is one step where your commitment to projects like this is really tested. Individual characters are nice little projects that you can work on independently. Building the game system requires committing to a large design, ordering or making many parts, and assembling them, along with electronics and software, into one system. You hope that you made good decisions and that the complete package comes together without major problems. It's taxing!
In Appybird I put a lot of design effort into avoiding having to make electrical connections to the rotating elements. However, in Snapper I knew that I would inevitably need power and data to go to the characters and would therefore need some kind of slip-ring. That was both exciting and terrifying as I had no experience of using slip-rings and had no idea whether they would be robust and reliable in use. I guessed the dimensions I might need and ordered a pair of slip-rings from AliExpress. The slip-rings have proved very reliable so far. Let's hope that continues. My guess on the dimensions I needed proved to be workable, but it was a close call.
Computing
On previous projects I used Arduino Nanos (ATMEGA 168 CPUs) extensively as I knew them well and didn't want to learn a new platform. However, their capabilities are now dated and I knew I could do better for Snapper. I had done a couple of other projects using Pi Picos and really appreciated their openness and flexibility (particularly the PIO). For Snapper I went with RP2350s throughout for real-time control functions.
Each character has a dedicated RP2350 integrated into its support arm to control the lighting, servos and monitor sensors. Of course we all know Moore's Law but it is still mind-boggling that I can now have roughly the power of the Mac SE/30 that I used at university in a cheap, tiny, microcontroller that is spinning around in a wheel. In the final hardware the RP2350s are mounted on custom PCBs. Designing these PCBs was a crash-course in the different types of tiny connectors out in the market.
A third RP2350 provides overall control of the system and implements the game logic. This RP2350 has quite complicated software to run the stepper motors which move the characters on the tracks. It also controls the dots on the track which are LED on another custom PCB.
Position Sensing and Collision Detection
Because the characters are moved with a friction drive I knew that I couldn't rely just on stepper step counts to find their position. I needed some way of tracking absolute position. The solution I went with was to have two hall effect sensors on opposite sides of the track which detect magnets in the characters. The software has quite a complicated process to fix the absolute position every time the character goes past a sensor and to use the step count since the last fix to estimate the position when it isn't next to a hall effect sensor.
This works pretty well, but despite my best efforts there are still sometimes small slips in the fiction drive which puts the position out of sync. It's rarely annoying and I guess is part of the character of the game.
Because I expected that the position sensing was going to have some errors I decided that it was important to have a separate, and robust, mechanism to detect collisions. There is nothing more annoying than the game killing your player when you don't think that there was a collision.
Making the collision detection work well was one of the difficult parts. I ended up with microswitches which detect the actual collision. Additionally, to allow the game to start deceleration in anticipation of a collision, there is also a self-centering potentiometer and cam-arrangement which gives advanced warning when the characters get close. Fitting all this into the physical space available in my overall design was difficult and required a lot of experimentation with different 3D arrangements. As always the final outcome is deceptively simple if you don't know all the rejected alternatives!
Completing the Game
The game is playable with just the microcontrollers and a serial terminal to send the command to start a level. But of course the full effect requires sound, displays and scoring to be added. I used a PC running a Python program to provide all these high-level functions.
One area which I hadn't really planned was how to display the score and other information to the player. I had wondered about using something retro like split-flap or flip-dot displays, but that seemed like a big project in its own right and it had taken almost a year to get the game mechanism together and I wanted to wrap it up.
The empty space in the middle of the track just screamed for something to occupy it, so I went with the biggest circular LCD I could find. The challenge then was how to mount the display and get power and data up through the middle of the slip-rings. With some creativity (and more 3D juggling) I managed to squeeze, with about 1mm spare, everything I needed into the space provided by the slip-rings I bought. The only problem was that the 3D printed hub assembly was flexible and the screen tended to bounce which spoiled the look. I did think about remaking the hub in metal, but as an experiment I tried adding stainless steel reinforcement rods to a 3D print. That actually worked well and became the final design.
To have a consistent look for the machine I designed graphics that are used on both the LCD and the marquee. Graphic design isn't my best skill and I did use AI to help with that (see below). Using AI did improve the design beyond what I could have done unaided, but it does still feel kind-of dirty even though I personally had a major part in the process.
The sounds of Snapper are mostly a combination of samples from Paku Paku and other samples from the original BBC Micro Snapper. I like this nod towards two of its influences.
Making an Arcade Machine
By the end of summer 2025 I had a game mechanism which worked well and play-tested well with friends and acquaintances. I also enjoyed it despite playing it many times in development. It has the "one more go" feeling which is always part of a great game.
All that was left was "just" to design and build the cabinet and integrate all the final hardware and software. Somehow this always takes almost as long as building the game in the first place. The basic process I use is to model the cabinet in 3D software and then use this to fix the parts. It should be easy, but in practice you spend a lot of time working out fine details like how best to arrange joints between panels and how to provide easy access, ideally from the front, to as much of the machine as possible for repairs and maintenance.
One learning point from Lunar Lander and Appybird was that it really helps if things go wrong in a field to have a conventional display somewhere in the cabinet so you can do basic checks on the CLI and logging to see what is happening. If your only display is a circular LCD then it makes life very difficult. Appybird has a small conventional LCD hidden under the control panel which has already proved useful during the build. It also logs every button press and software event so you can reconstruct the sequence of what was happening if something goes wrong.
It took about 7 months to bring together all the parts of the cabinet. That included having the sides CNC cut by a local company and the marquee and control panel printed on vinyl. I designed the cabinet to have something of the feeling of a classic arcade machine. That includes having the mechanism at a slight angle like the CRT might have had in a classic cabinet. It was the right choice, but OMG having to deal with angles other than right angles really complicates the build.
Conclusion
It took almost two years to make Snapper. At times it felt pretty intense and it can be an effort to keep making decisions and keep fixing problems. But I also took breaks and did other things at various stages. The result is really nice and pays back the effort. It has an obvious family resemblance to Lunar Lander and Appybird, but it also has its own personality and quirkiness. I think it will be much liked.
As I write this we are a few days before the unveiling of Snapper at EMF Camp 2026. My drive during the project was to have something new and cool to show there. That might sound like an odd motivation for so much work, but EMF Camp is a brilliant event run completely by volunteers and this is my way of contributing. I am pleased to be able to do something which is, mostly, fun and hopefully will be one fragment of an amazing weekend for all the participants.
Use of AI and other Tools
Concepts for the Snapper logo and marquee graphics were created with the help of AI. The final versions were made by hand in Inkscape. The AI was helpful but wasn't able to correctly incorporate all the features I wanted.
The code to find the best route to home the player and the ghost at the start of the game was largely generated using AI (it sounds trivial, but doing it well is surprisingly complicated). AI mostly got it right, and saved me a job to work out the algorithm myself, but it did fail to correctly handle one corner case which I had to fix by hand.
AI was used to document the internal serial interface between the PC and the RP2350 game logic after I started to forget what all the commands did! It was mostly accurate and better than no documentation.
AI was used as a "rubber duck" to help debug a memory corruption problem in the game logic on an RP2350. The AI made a lot of wrong comments, but the conversation did help me uncover the cause.
3D modelling was done in Autodesk Fusion.
Software was developed in a customised Arduino IDE and Visual Studio Code.
3D printing was done in PLA on a Bambu Labs X1.
Large panels for the cabinet were CNC cut by a local supplier. Other panels were cut by hand mostly using an Evolution track saw.
Acknowledgements
Many thanks to ABA Games for releasing Paku Paku. Your output is prodigious and amazingly creative.