BL:AM

After The Spirit of Gravity in February I ended up talking to Jason Hotchkiss and Jo Summers. I knew Jason from a Build Brighton guitar pedal workshop years ago and as a sound artist from Sound Plotting, but Jo knew Jason as the game developer who made 1D Pong. After talking about 1D Pong and another 1D dungeon crawler we started thinking about the most ridiculous 1D game we could imagine in 2023 and settled on 1D, 1 button battle royale.

Normally that’s where the story would end, but for some reason the idea kept rattling around in my head and eventually I ended up putting my thoughts down in a Google Doc and started thinking about how to make it happen.

To be a battle royale the game had to be multiplayer with players on a shared map trying to shoot each other, but a 1D display meant the gameplay couldn’t come from aiming. Judging the distance to shoot by charging and launching a missile solved this problem and provided a fun core gameplay loop which could be implemented with a single button. Hold the button to charge the missile then release the button to fire a distance dependent on the time the button was held.

With the button used for shooting, moving players around had to rely on another key feature of battle royale games: the shrinking map. The game would start with a large map filling the display and would position players randomly as they joined. Periodically the map would shrink and randomize the player positions within the smaller play area. This would create a natural tempo increase in the game as players would move closer together, so players could fire shorter distances and so fire more often. Eventually all the players would be next to each other, so just tapping a button would always result in hitting a player, ensuring the game came to a swift end.

Jason had already suggested the Raspberry Pi Pico as a potential hardware platform, so I built a prototype as a Linux terminal application which outputs frames as lines of ASCII to quickly test the design in a way that might be easy to port. The first prototypes were surprisingly fun. Some tweaking of the map resize period gave good players enough time to range-find long distances while not making weaker players wait too long if they were a long way from the action. As the map got smaller the action got more frantic before ending in a flurry of button mashing as planned.

The slow pace at the start gave players enough time to learn how to play, but could feel frustrating when all the targets were at the other end of the map. A solution came by adding loot boxes, another feature common to battle royale games. Scattering loot boxes across the map meant players would always have something nearby to shoot, helped maps feel more varied and provided a way to add depth via power-ups and another way to move around via teleporters.

Loot boxes also added another interesting gameplay choice: should I try to snipe an opponent immediately or get tooled up first? The initial design always fired missiles at the nearest target, which Jo highlighted as a problem as it meant you couldn’t always pick your target. An easy solution was to alternate the direction of fire. Just tapping the button meant players could quickly launch a missile in the wrong direction before getting back to carefully charging a shot to fire in the right direction again.

After playtesting the software version at The Brighton Indie Gamedev social, I was convinced that the game was fun and started thinking about hardware. I expected it to be a lot of work to get running on the Pico, especially as I’d allowed myself to joyride some relatively new C++ features like lambdas and auto parameter types, but g++ happily took my fancy code and cross compiled it without any complaints. I could also use PuTTY to connect to the Pico as a USB serial device to see the ASCII output, which was incredibly useful while testing the hardware without the LED display and then for debugging problems while getting the display working.

I ended up with a hardware main function (which wired the inputs up to the Pico pins and redirected the output to the USB serial interface), a terminal main function (which used some hacks to get unbuffered keyboard presses) and renderTerminal and renderRgb methods implemented by the game objects. The rest of the code was shared between the two builds, allowing me to quickly develop, test and debug the game using VS Code and gdb, then cross compile and drag a binary to the Pico mounted as a USB drive.

In May I got the chance to play 1D Pong at Jason’s studio which made me realize how important audio is when you only have a 1D display: the sounds of balls bouncing off bats and points being scored did a lot to explain what was going on, so I started thinking about adding sound to 1D battle royale. The Pico doesn’t have a digital to analogue converter, but some experimentation showed that it can generate some gloriously grungy sounds by using pulse width modulation to play samples using one of the digital outputs. After aggressively compressing some of ProjectsU012’s arcade sounds and converting them to 8 bit samples stored in header file arrays, the game came to life. Instead of being a quirky, abstract 1D game it was a battle royale complete with missiles whooshing and exploding and players powering up and teleporting around.

I haven’t made a game in a long time and I’ve never made a hardware game, so this project has been a lot of fun. It’s also something that I couldn’t have done without Jason, Jo and everyone at the Brighton Indie Gamedev socials: thank you to everyone for your help and feedback.

“Battle Lines: Arcade Machine” (BL:AM) was included in the Pop Up Arcade at the Dreamy Place Festival in Crawley in October 2023 where I had lots of fun playing it and talking about the design and development. You can find more gameplay footage here.