To make sure I get plenty of exercise during cold and dreary Berlin winters, I recently picked up a smart bike trainer , a device that turns my bicyle into a Bluetooth-enabled stationary bike. It connects to my iPad, at which point various apps can both access its cadence and speed sensors (how quickly I’m pedaling) and dynamically change the resistance (how hard it is to pedal). It’s like the nerdier version of a Peloton exercise bike.
There’s a small but healthy ecosystem of apps and games built around hardware like this. A personal favorite is Zwift , an MMO-like experience where you go for virtual rides with other real players. I like Zwift and its ilk, but they’re all much more “cycling nerd training tool” than “fun game”.
As a game designer, I’m interested in fixing that!
I help organize alt.ctrl.PARTY , an annual party during the Game Developer’s Conference celebrating games with nontraditional physical controls. We haven’t started planning this year’s lineup yet, but I was thinking it would be awesome to be able to showcase a game there that uses a bicycle as a controller.
In tandem (hah!) with designing and prototyping potential cycling games, I thought it’d be a productive exercise to document my process. The nature of game development means that a lot of game design ideas and prototypes don’t go anywhere. I’m writing these blog posts as I go along, and as there’s no guarantee any of the work I’m doing will result in a fun or interesting game, it’s totally possible this will turn into a public documentation of a failed project.
If that happens, though, I think that’s just as interesting as process documentation for a successful project! A lot of the writeups you see of alt control games tend to be after-the-fact explanations of successful projects; I think there’s value in showing the messy in-the-moment process as well.
Before I dove head-first into the technical minutia of writing code to talk to my Bluetooth hardware, I wanted to brainstorm ideas and start thinking about what I could actually make.
After some time at the coffee shop with my favorite notebook and pen, I came up with a few major design goals for the project.
While I could theoretically release a commercial game for anyone who owns a Bluetooth-compatible smart trainer, the audience of people who own expensive specialist cycling hardware AND want to play a weird experimental indie game is pretty darn small. Anything I make here is going to be an installation game first and foremost, which means designing for what works well in that setting. Specifically:
When designing any sort of game with nontraditional controls, it’s important to understand why those controls are necessary. A game that uses a physical bicycle needs to justify why it’s making the player physically pedal instead of just using a normal controller or keyboard/mouse to control a bicycle avatar.
Specifically, the smart trainer setup I have gives me a few different input/outpt mechanisms:
Given all of that, I came up with three potential ideas:
You’re an intrepid adventurer traversing the depths of a dungeon… on your trusted bicycle!
Much like Crypt of the Necrodancer , starting with a base of a straight-forward dungeon-crawler offers a lot of room to experiment and make interesting design choices.
As an example, the dungeon could be very dark, and your in-game light is powered by your pedalling, so you need to always be moving forward if you want to be able to see. A roguelike with free movement where you’re always moving forward in real-time could be interesting.
You can imagine all sorts of other hazards that play off of the available inputs:
What’s nice about this idea is that it’s a relative blank slate. If I come up with a hardware interaction that seems interesting, it’d be easy to come up with a justification for how to fit it into the game.
Playing into the roguelike tradition also makes sense for an event. Games are finite length and permadeath gives a natural stopping point for a player. Uncovering the game’s hidden areas, optimal strategies, and interesting interactinos between subsystems can provide for interesting conversation across people at an event trying to figure out the game’s secrets.
Also, I could call it “Roguebike” and hate myself for it.
A few years ago, Uber launched a short-lived iOS game called UberDRIVE where you play as an Uber driver. It was a weird The Last Starfighter -esque stunt to entice people to become Uber drivers, but there was something oddly compelling about driving around a Google Maps view of San Francisco.
Imagine a game where you play as a food delivery courier. Riding across the city to make as many deliveries as you can in a short bounded game session creates a race-the-clock mechanic that works perfectly for both a cycling game and for an event game.
You can imagine building out the game’s level so that different routes have different difficulty levels (adjusting the resistance on the bike). Letting players turn to choose their route both offers players tough choices about which route to take and gives us a natural way to use handlebar steering as input.
There are a lot of potential ways to customize the game for a specific event it’s being shown at. Using a maps framework like Google Maps to render the game, and procedurally generating missions based on venue data from a source like Foursquare, the game can be set in whatever city it’s being shown in (I’m inspired here by games like 911 Operator ).
I could even theoretically let spectators log on to a website to place their own deliveries, giving the active player a bonus for completing audience-ordered deliveries.
The theming is compelling as well. I’m always excited for a chance to use real-world data as a seed for procedural content generation, and a game about being an on-demand worker has a lot of potential for social and political commentary (see: the upcoming Neo Cab , which I’m very excited for!)
If I want to make a more narrative-focused experience, the moment when you complete a delivery could involve short choice-based narrative storylets about your interactions with your customers, giving space for world-building.
The first time I went to an in-person spin class, I felt like it was trying to evoke the synaesthetic experience of playing a game like Rez or Thumper . I imagined a hypnotic experience where the loud music, pulsating lights, and the rhythm of your own pedaling all fused together to create a deep flow state.
The small, sweaty studio I visited didn’t quite live up to my expectations, but I would love to make something that matches the image in my head. A gameplay mechanic based around pedaling on the beat to a shifting music track feels like a natural combination of both existing rhythm games and spin classes.
You could even do it in VR. The current generation of cheap standalone HMDs (the Oculus Go, Lenovo Mirage Solo, Vive Focus) don’t require any awkward wires, are powerful enough to run ports of both Rez and Thumper, and are Android-based so piping data from a BTLE device to a Unity game should be possible.
It’s hard to know which of these ideas will work best without getting our hands dirty. My instinct is that what’s most important is simply picking an idea, and the act of playing a working prototype on actual hardware will clarify what works and what doesn’t.
I quickly ruled out the third idea. I’m excited by it, but it leans very heavily on nailing a very specific aesthetic experience. The prototyping process to prove that out wouldn’t lean into my strengths as a designer and engineer. It also fails to meet most of the design goals I established surrounding suitability as an installation piece.
I think either of the other two ideas are totally viable.
Focusing on the roguelike would require less upfront design work, letting me play with the hardware more quickly to see what’s interesting. The sort of “bottom-up” design process it suggests, letting me prototype fun individual interactions and mechanics and work up to a more coherent concept from those small atoms of fun, has worked very well for me with past alt control games.
That said, I think the delivery game idea makes more sense. For one, it lets me use tools that I’m faster at prototyping with (web and native iOS non-game development tools, rather than Unity). More importantly, given the choice between something as conventionally “game-y” as a dungeon crawler and a more unique (and non-violent!) concept, I’ll choose the latter every time. I love making games that directly simulate and explore mundane every real-world activities, and this fits right into that model.
So, I have an idea!
In the next blog post, we’ll shift away from design and talk about low-level tech! I’ll be writing Swift code to connect to my smart trainer via BTLE, and start reading in actual live data.