Back in May I was part of a team running a short LARP in our High Frontier universe.
The game plot called for the existence of a prototype communication device through which 'second contact' with an advanced extra-terrestrial species was being attempted.
In practical terms the intention was there would be a short exchange of messages between the players and these extra-terrestrials while very human chaos raged around them.
We like to do things with 'practical effects' at High Frontier and avoid whispered messages from GMs and the led me to somewhat overcomplicate the prop involved. A lot of this was because we intended to have an multi-user in-game messaging system at our previous event and I flamed out trying to deliver it in time, resulting in a big disappointment.
So this game I very much wanted to make that happen even if the actual amount of messaging would be trivial.
Every player was provided with a personal printed RFID card and inserting the card into a reader in the external unit logged them in.
The physical prop was made in two large chunks: a 'terminal' and the actual 'communicator' itself. Making these physically imposing yet still portable props was deliberate as the players would be faced with carrying them while under fire or abandoning them.
The 'terminal' is an old laptop motherboard and screen carefully fitted into a medium sized flight case with 3D printed and painted fascia. The flight case was interestingly laid out with a padded compartment on one side and I retained that for storage of a compact keyboard, mouse, cables and the power supply enabling it all to be packed down for moving.
Building this took a fair amount of iteration and improvisation. The original laptop battery pack was beyond use so I built one out of new 18650 cells with double the original capacity to ensure it would last the entire game.
Making an aged laptop bearably usable is an increasing struggle and the Raspberry Pi desktop for x86 is my go-to for this. By removing the Office software before updating you can still squeeze it onto 8GB SSDs and so long as you don't want to use Chrome with super-bloated sites performance is as zippy as it can be.
All it needed to do was run PuTTY as like my previous work on off-grid multi-user messaging this was a 'microcontroller first' design, implemented on ESP32-S2.
I took my previous, frankly unmanageable, project for messaging and created a new back end for it this time based around the port of sqlite available for ESP32. My goals were far more modest than the original project in UI terms but the back end still has most of the features to now resurrect it in what I hope is an actually manageable fashion.
Inside the communicator itself is a custom PCB I made a small batch for as long term I want to develop and use this messaging system for future games. It uses the ubiquitous MRC522 RFID reader and has a GPS attached for getting an accurate time signal, which is necessary for the system to work. There's also a uSD socket for storage (although it
could use LittleFS), a sounder and some indicator LEDs.
By the time I was actually coding things for the game I realised I'd made some omissions on the PCBs but broadly they worked.
While the players interacted using a retroterm UI on the physical terminal, GMs could connect over WiFi and use a hacked together web interface to view previous messages and send new ones.
I did start by writing a fully featured web interface but the framework I used meant the ESP32 began to run out of memory once there was a non-trivial number of things in the database. Moving things into PSRAM helped, but not enough realistically.
The sqlite cache also caused me grief as it would rapidly eat all the heap memory of the ESP32, despite nominally being able to manage that itself. Tweaking compile time constants helped but in the end I found I had to aggressively clear the cache using the sqlite API after every interaction. By this point I was very close to the game, stressed about the deadline again and as messy as this solution was it worked well.
Using GPS for time, even indoors, worked well in testing but was another cause of stress on the day even though we're nominally an outdoor LARP system.
A cold GPS start, metal roof on the building used and need for it to work quickly ended up with us having to leave the communicator outside the building on a long USB lead for it to work at all.
I will not wholly rely on GPS for time again and look to fit a dedicated RTC that is set then updated by the GPS only if necessary. Even outdoors the time signal seemed unreliable but it was impossible for me to troubleshoot at the game. This meant weird slow performance and trouble logging on that I simply hadn't seen in testing.
In the end though, messages were exchanged and this massively overcomplicated setup delivered even though it gave me and the rest of the game team huge amounts of stress.
What I need to do now is work on it in the in-between times so that the back end approaches plug and play for other applications and my 'microcontroller first' plan actually means it can be used across a range of lightweight devices.
There was a whole PC doing almost nothing in this setup that could have done the messaging instead but my plan is this 'backwards' approach would allow cheap ESP32-based props to interact with the system.
You can buy something that could in principle be turned into a pocket touchscreen communicator for <£10 and I plan to pick up a couple. It's just the tip of the iceberg of what you can do with little ESP32 based gadgets. Previously I was thinking to use M5Stack/M5Paper products as well.
The messaging back end I've christened backslang and is on GitHub but I would say it is very much an unfinished mess not fit for anybody else to use. Maybe I'll find time to fix this before our next event. I'd love other people to dive in to the repo and fix my naïve mistakes but it seems unlikely anybody will have the inclination and time.
