With the arrival of the pandemic, almost all LARP except that which was conducted via video chat went on hiatus, including a game we'd been planning for a couple of years.
However things kicked off again for us on the weekend of 3-5 September 2021 with an 'anthology event' that consisted of several short games. After a chat with one of the game organisers I agreed to set up some stuff to round their Cyberpunk themed game out.
We play on exclusively outdoor sites, almost always with no access to mains power or permanent Internet service so everything needs to be self-sufficient for the duration of the game. Also with only a couple of hours of setup time available it needed to go out quick and dirty right beforehand.
I put together several elements that got included in the game, spread across three different locations on the site.
Cyberdecks
It's not uncommon for game organisers to use mobile phones in games nowadays, but for us this is a major departure and it was expected some players might be unwilling to use their own phone.
I spent a little while making 3D printed vaguely tactical looking cases with carrying straps for them. This meant all the players had identical kit and I could manage the apps/configuration with it all tested prior to play.
Video calling from an "A.I." NPC
We had one of the game writers, in make-up in a crew building, set up with a backdrop behind them and a mobile phone. One of the Nexus 9 tablets had an LTE cellular interface (uncommon in tablets) and at suitable points they were called using Google Duo. This has the advantage of being very simple in interface and needing no separate account or verification.
This was a nice and simple way to make the video calling happen.
Co-operative "Netrunning" mini-games and tasks
With three 'Netrunners' in the game I was asked to give them 'something to do' that would keep them occupied and make them work together. In the past we've used standalone electronic games and puzzles but I wanted to try something different.
Each mini-game/task was a captive Wi-Fi portal provided by an ESP8266 microcontroller and by configuring each tablet so that it connected to a specific Wi-Fi hotspot the players each got to try all of the tasks.
As the players wandered into range of the Wi-Fi, the tablet would pop up a prompt to "Sign in to network" like you would with a captive portal in a public space and take you straight to the games. Failing that there was a shortcut on the desktop for it.
This could have been done on a Raspberry Pi or other SBC but I'm a fan of doing things on ESP8266/ESP32 as they boot almost instantly and couldn't care less if you power them off unceremoniously.
The tasks were very simple.
- The first 'Netrunner' had to enable the 'uplink' by playing a version of 'Simon says' repeating a sequence of button pushes back.
- The second 'Netrunner' had to stop the I.C.E. countermeasures deployed against the first by playing 'Whack-a-mole', clicking any button that changed colour. This accelerated, the longer the first player played 'Simon says'. If this player 'failed' the first player got thrown out of the system.
- The third 'Netrunner' had a set of data to delete and control of the 'power node' that provided power to lighting and the CCTV security system etc. There was no 'game' here but different tasks/options in each location.
The portals had a 'tabbed' style interface and the last tab had very basic out-of-character instructions for what they needed to do.
These portals were created using the open source library ESPUI, which makes it dead easy to make interactive applications that run on an ESP8266 or ESP32. All the logic happens on the microcontroller, not in the browser so it does increase latency but does mean it's closely coupled to changes on whatever physical prop you're controlling with it.
To enable communication between the separate ESP8266s I used my still in development mesh network library.
All these games and tasks are highly trivial as their part is for there to be something for the players to use as a foil in their play, not to be the focus of play itself.
Uplink antennas
I like physical objects that provide feedback in LARP, which is another reason I tend to build standalone props with ESP8266s that 'do one job' rather than a single set of multi-function stuff running on a server somewhere.
These 'uplink antennas' were just an ESP8266, small PCB with some red & green LEDs attached and some NiMH batteries stuffed on a pole up high in each location.
As the 'Simon says' mini-game was played the red & green LEDs would alternate, spending more time on green as the player did better. Once complete it stayed solid green.
I also housed the 'Whack-A-Mole' game ESP8266 in an identical device, with the LEDs going red while the I.C.E. was deployed and green when it stopped.
These two things were to give feedback to the non-Netrunner players on the progress of the hack. They could look up and see how things were going.
These two things were to give feedback to the non-Netrunner players on the progress of the hack. They could look up and see how things were going.
Power distribution nodes
Inside is an 8-way relay board so the 'Netrunner' connected to this could control power to individual outlets and each one also has a telltale LED showing if it is powered.
Originally built for our game postponed in 2020 they are also capable of ambient sound effects, but I never found the time to get this coded for this game.
Boring as this sounds, controlling power actually had 'tactical' value. In two locations there were spotlights pointing 'outwards' that meant the players could not easily see the NPCs in the location and in combat there was a definite advantage to those behind the spotlights.
There were also other tasks that could be done here. In the first location it was destroying the data on the shipment the players were stealing and in the final moments of the game, the player connected to the 'power node' was in charge of the destiny of the 'A.I.' NPC that they had been interacting with throughout the game.
Lighting
The first were spotlights made from domestic MR16 LED spotlight bulbs. These spotlights were used to floodlight a 'crashed convoy' the player group would assault to steal equipment from in the setup encounter.
These spotlights used ceramic bulb holders in custom fittings made from plastic waste pipe and 3D printed parts. As the LED bulbs are very efficient, heat is not an issue and they were amazingly bright.
Without lighting, the inside of buildings at this site are kind of unusable at night. We have hung torches in the past but this lit the place up like a house and was just what we needed when one of the buildings had to represent a research lab in the game.
All this ran off 12v lead-acid batteries beautifully. MR16 fittings are designed for it (some are 12v AC only but most can accept AC and DC) and the backlight strips were also designed for 12v DC.
Wiring it all together I used reels of domestic two core lamp flex as it's a cheap way to buy long lengths of decent stranded cable and a big bag of screw terminal 2.1/5.5 barrel jacks fitted on-site once the cable was cut to length.
Security cameras
While it would be easy to roleplay the existence of the blackmail footage and that's what's usually done, we thought it would be nice for there to be actual footage.
Most domestic CCTV equipment runs off 12v DC or PoE so is easy to power off the same setup as the lights and I had a few decent outdoor cameras sitting around at home. Screwed to a couple of bits of wood and cable tied up in suitable locations they got a good view of the location concerned.
To capture the footage I did an installation of the open source package Motion Eye on a Raspberry Pi 3B+ fitted into the same enclosure used to distribute power to the lighting. I have a number of decent 12v to USB power supplies and we were using large lead-acid batteries so again it was trivial to power it for a few hours.
Something that's easy to forget when you're 'off grid' is that the Pi, like a lot of SBCs, doesn't have a hardware real time clock and lack of a sensible time reference causes general irritation to software. To fix this I plugged in a cheap USB GPS dongle and used this how-to to get it working.
To give player access to the footage on the Raspberry Pi I used a separate Wi-Fi AP (I happen to have them) but using hostpad to provide Wi-Fi directly from the Pi would have also worked.
To view the footage in Motion Eye, there is an Android app which once configured gives you one-click access to the camera feeds. A web shortcut on the desktop would have worked but this is slightly more seamless. In the app it's easy to look at various recorded segments and delete or download them. The download was used to exfiltrate the footage for later blackmail purposes in the game.
What went well
- The lighting was very effective, perhaps more effective than expected
- All the mini-games and tasks worked
- The CCTV footage was downloaded
- We had multiple interactions with the 'A.I.' NPC
What didn't go so well
- It took a long time to set up, even with quite modest expectations for the amount of lighting we used. Cutting and running the lighting cabling took the bulk of the time.
- A Raspberry Pi 3B+ just isn't fast enough to run Motion Eye (or more specifically the 'motion' daemon) without lots of slowdown and artefacts on the stored video. It did produce footage that could be shown but it was a bit rubbish
- The Wi-Fi reached further than expected so by the third location, the 'Netrunner' players were looking for the systems to hack well before the player group were within sight of the encounter. This was OK but meant the activity got a bit detached from what the other players were doing. Their working at the limit of connectivity also made the interactivity a bit patchy until they moved closer
- The uplink antennas weren't very conspicuous so I don't think anybody really saw or paid attention to them
- The 'cyberdeck' with LTE coverage had trouble accessing the mini-games when connected to LTE so I had to get the player to swap between that and Wi-Fi manually before and after the mini-games. This is something I failed to check before the game due to time pressure
- Cellular coverage at the site was patchy (we knew this) and the video calls were unreliable, but they did work after a couple of attempts
- It took the players a couple of goes to become comfortable with driving the mini-games and on a short game like this, it was over by the time they'd got into the swing of it
The "what didn't go so well" list looks long but all these were small irritations that can be learned from and overall my attempt to add things to the game was successful.
My props weren't the only ones in the game, there were also Cyborg costumes with EL-Wire, Mohicans, Mirrorshades, loud Thrash Metal, a Defence Drone, a cloned 'blank' body in the laboratory, control panels and so on that everybody on crew contributed. I reckon it turned in a pretty solid Cyberpunk experience in just a couple of hours.
1 comment:
So glad that so many aspects worked so well! Given an urban site with mains power the possibilities would be far greater and even more Cyberpunk! Enjoyed reading this!
Post a Comment