Overview
A simple experiment, what would it take to get a raspberry pi that was easy to deploy on the road? I was looking to make a portable device / game that had more capabilities than a microcontroller could have. I was hoping if I tried a full Raspberry Pi, I would unlock a lot more things, such as:
- audio playback / speaker support
- gpio support
- RFID scanner
- addressable leds
- more device storage
- could last on a battery
- to be able to utilize and try python environment and the expansive libraries I gain from that
Long-term, if this works, it could serve as a nice central server for future devices to connect to.
The event this device was made for was fallout themed, leading to this mixed apocalyptic tech aesthetic. I recommend watching the video for reference of how it actually works.
Tech Capabilities and Feature Set
Hardware + Interface
The device used a PN532 NFC receiver with a ring of WS2812B Lights. There was also a 4x8 segment display and a hardline power switch directly to the power source.
The brain of this is a Raspberry Pi 2B, which has a lot more power efficiency compared to the later Raspberry Pi versions. Also harder to acquire (especially nowadays).
Software
Data Driven Hookup
An easy way to map a programmed key on an NFC card/chip to its relevant data, using a json mapped with all the proper data. The mushrooms with unique behavior were also still data driven, but we also had support for narrative items and assorted items that made it easy to add content in very late into the process.
Pygame
The device was running an instance of pygame with no display output, which allowed us to have an easy architecture to build off of. There was also support for fully disabling the GUI side of the library. The entire game loop was multithreaded to ensure the NFC scanner would not interfere with the led animations.
Hardline Power
Due to the hardline power switch, a large portion of tuning was improving Raspberry Pi startup time when running Raspberry Pi OS.
I needed to make my program a Linux daemon that runs on startup, and from there worked to figure out what libraries I could disable to improve startup times.
LEDs
Sadly, Pygame and the Adafruit framework had incompatibilities with FastLED. The decision was made that for this project I would not use FastLED, and found that without all the structures from FastLED, I was able to create some good structures that were performant enough to do complex animations with seamless blending between states.
The animations were on their own thread, and were made to be a seamless blend in all cases. I didn't want a single jarring change of leds between states. I found a nice universal system that gave it the flexibility to not require tons of boilerplate per state as well.
Repo
The repository needs to be cleaned before it can be made public. Stay tuned or reach out.
Game Design
Game Loop
The goal would be for the people to look around for these little mushrooms around campsite, and scan them in once they found them. There were also scripted events/narrative moments that were tied into all this. The mushrooms all had scripted lines that were "encoded" until you were able to scan enough mushrooms to "decipher the signal".
In practice, we think made the loop not as approachable and it didn't give enough motivation early on to keep hunting for these.
Audio
The audio design in many places was inspired by Zelda, especially for how the discovery builds up and releases at the end with a sort of "shatter" sound effect.
Development
This whole new ecosystem of working with a raspberry pi over a microcontroller has a lot of benefits, but in hindsight I think I undersold to myself the learning curve and upfront costs of setting up a new system like this.
Python was useful, but felt unsecure in many ways I have gained comfort with having control over as a game engineer using C++.
SSH Development
Due to the environment circumstances of using GPIO heavily, testing off device was impractical. I found SSH and doing development in the remote SSH on VS code was an incredibly smooth pipeline. I made sure to keep the project updates on GitHub to avoid any data-loss issues when I was testing linux/system optimizations.
Boot Time Optimizations
One of the limitations of the system was that it needed to be battery powered and portable enough to bring around the environment. This made the boot time a genuine system for concern. I started doing breakdowns of all the performance times for the various daemons that linux was running on startup. I found that internet usage was one of the highest ones, around 12 seconds in fact of boot time was allocated to this.
This took a large amount of the dev time for this project, but I sort of liked this form of optimization. There was a useful function in Linux that broke down the boot times for various services that occurred at boot.
LED Animations
Like a lot of my latest projects, premium LED animations is where I put a large majority of time as I believe that is what creates immersion with these devices.