BB's Feast: Cadence Arcade

Concept and Character — I was excited by the idea of using trainer input as the primary affordance for the game, and started thinking of game-types that would best use power, cadence, and speed. My vision for Cadence Arcade games was to be reminiscent of old 8-bit console games, so I pretty quickly landed on an endless runner for the first title to really represent the spirit of what I was going for. I had toyed around with other animals (pig, monkey, squirrel) for the main character, but after thinking a bit more about what type of animal would be ideal for scarfing up food, I decided my old dog BB would be the perfect avatar: she was very silly looking so would be fun, she was more food motivated than any dog I had ever known, and who doesn't like dogs?

Sound and Music — I had a blast going through the many different open-source sound libraries to find just the right sounds for the moment. It was really important that all audio was right for the mood of the game, providing the user with both meaningful feedback, but also a hint of fun and levity that would further separate this game from the more "serious" offerings out there for cyclists.

Cadence for Elevation, Power for Speed — The fundamental innovation separating BB's Feast from all trainer software. Power readings from trainers are slow and fluctuate significantly—using them for vertical position created unplayable choppiness. Cadence provides instant feedback that naturally maps to "rising" in cycling. This separation allows independent tuning: responsive elevation for obstacle avoidance, realistic speed physics for workout feel.

Velocity-Based Physics With Momentum — BB doesn't teleport to target heights—she accelerates toward them with vertical momentum that persists between frames. Asymmetric acceleration (faster rising, slower falling) creates intuitive "floaty descent" feel. Adaptive smoothing detects intentional cadence spikes (fast response) vs. steady pedaling (noise filtering). Result: responsive when needed, stable when not.

Patterns Over Randomness — Designed named formations (Log Field, Rock Garden, Choice Pattern) that players recognize and master rather than random generation. Same well-tuned patterns scale across four difficulty levels by adjusting speed, not adding chaos. Creates skill progression and strategic decision-making.

The original concept envisioned power controlling both speed and elevation. BB would have five power states: stubborn sitting below 50W, sluggish at low power, happy running at moderate power, floating at high power, and rainbow invincibility at peak effort. This personality-driven design—BB refusing to move unless properly motivated—wasn't arbitrary. It created engagement through character behavior rather than abstract game rules.

Early prototypes established the core architecture using Flutter's rendering system, keyboard controls for testing without hardware, and basic sprite animation showing BB's different movement states. Everything worked smoothly... in debug mode with keyboard input.

Building a Trainer Game Without a Trainer — One of the biggest challenges in the early days of development was the fact that I didn't actually own a bike trainer. I had sold mine prior to the move and didn't really have space in our flat to easily set one up. This forced me to be creative with how I approached development and testing. I fortunately had a generous friend who would let me come over and test on his bike a few times a week, but I needed to be creative to ensure development was moving forward between test sessions.

I accomplished this via two methods for spoofing trainer behavior in the app environment. One of the first things I did as I was developing the app was to create a browser and keyboard debug mode that allowed me to see the game in motion without a trainer. This was key to seeing the character, food, background, and general feel of the game at different power and speed zones. I was able to use arrow keys and numbers to get BB into the appropriate zones to see how she moved, when she went from walking to running to flying, and ensure the parallax motion looked right.

The second tool that helped me really get things off the ground was nRF Connect, which allowed me to create virtual trainers that the game could attempt to pair with. This was absolutely key for working through connection bugs prior to testing on the bike, allowing me to focus on testing gameplay instead of banging my head against connectivity issues.

Testing with an actual smart trainer revealed the fundamental flaw. Power-based elevation felt terrible—not because of game design, but because of how trainers work. Bluetooth power updates arrive roughly once per second with natural fluctuations. Power readings would jump: 246W → 268W → 281W → 290W → 285W, producing five distinct jarring vertical movements per second. BB looked like she was riding an elevator, not flying gracefully.

The first attempted fix was power input smoothing using exponential moving average. This helped horizontal speed feel natural but didn't solve elevation choppiness. Even smoothed power still changed frame-to-frame, and directly mapping those changes to position amplified them visually.

The second attempt added elevation position smoothing on top of power smoothing—double-smoothing. This reduced choppiness but created lag that made precise obstacle avoidance frustrating. You'd spike power to dodge a snake, then watch BB slowly drift upward a fraction of a second later.

The Breakthrough — The insight came from questioning the fundamental assumption: why use power for elevation at all?

Cadence (pedaling speed in RPM) provides direct 1:1 feedback from crank rotation. More importantly, cadence naturally maps to altitude in cycling—higher cadence feels "lighter," matching real-world experience. When you spike RPM to dodge an obstacle, the game can detect that instant intent and respond immediately. During steady pedaling, small sensor fluctuations get filtered out.

This led to a complete physics rewrite separating horizontal and vertical systems:

Horizontal movement — Trainers already handle speed nicely, so we simplified things to just use that direct data to control forward movement. Air resistance creates natural equilibrium speeds—100W settles around 22 km/h, 200W around 38 km/h. This matches real cycling feel without artificial limits.

Vertical movement — Cadence determines target elevation across three zones (Ground 0-69 RPM, Flying 70-99 RPM, Rainbow 100+ RPM), but BB doesn't jump directly to that height. Instead, she accelerates toward it with actual vertical momentum that persists between frames. Rising is snappier than falling, creating that "floaty descent" feel. The system uses adaptive smoothing—fast response when you intentionally spike cadence, stable filtering during steady pedaling to prevent wobble.

The result: responsive when you want it, stable when you don't.

Designing Patterns, Not Randomness — Early food and obstacle generation used random placement. This created three problems: overlaps where obstacles blocked food, uneven distribution with clumps followed by empty stretches, and no learnable patterns for skill development.

The solution was designing specific formations with clear purposes:

Log Field — 50% density ground obstacles requiring moderate weaving.

Rock Garden — Rhythmic spacing matching natural pedaling cadence.

Choice Pattern — Elevated food chain above ground obstacle field—surge high for premium points (high effort, high reward) or navigate ground conservatively (lower score, less demanding).

Food chains award completion bonuses. Elevated chains mix ground and floating items vertically, creating natural intervals: collect ground bones at steady pace → surge to high cadence to grab steaks → drop back down and repeat.

Progressive difficulty emerged from using the same well-tuned patterns at increasing speeds and with premium items appearing after players travel significant distance. One good pattern automatically becomes four difficulty variations without adding randomness.

Universal Trainer Compatibility — Smart trainers don't all speak the same Bluetooth language. Some broadcast FTMS (the official standard), others use the older Cycling Power Service, and some expose both simultaneously. My development trainer—an Elite Suito—only used Cycling Power Service, forcing immediate support for both protocols or the game wouldn't work on my own hardware.

FTMS provides comprehensive metrics in a single data packet. Cycling Power Service requires parsing optional crank revolution data—cumulative revolution count plus timestamp—then calculating RPM from the difference between consecutive readings.

The implementation detects available protocols automatically and falls back gracefully. It also handles cadence decay detection: when players stop pedaling, trainers stop sending data updates. Without decay logic, cadence would freeze at the last value indefinitely. The solution: if no updates for half a second, cadence drops to zero and BB descends smoothly.

Polish and Feel — Real trainers' flywheels decelerate quickly when power drops—physically accurate for the trainer, but it doesn't match outdoor cycling where body mass provides momentum. The solution separates what affects scoring from what affects visuals. Distance accumulation for points uses actual trainer speed, but screen scrolling uses smoothed visual velocity. This creates realistic "coasting" feel while maintaining workout accuracy.

The HUD evolved from text-heavy labels to a clean segmented power bar with color-coded zones and minimal text. Activity history tracks cumulative statistics and individual sessions, with FIT file export bridging arcade gaming and serious training platforms like Strava.

Beta testing targets diverse hardware (multiple trainer brands and firmware versions) and user types (serious cyclists, casual exercisers, children, non-cyclists). Structured feedback surveys explore session duration preferences, difficulty appropriateness, physics feel, and feature priorities.

Comprehensive technical documentation serves as a template for the remaining four Cadence Arcade games. Every solved problem—physics engine structure, Bluetooth integration, pattern generation frameworks, scoring systems—becomes reusable infrastructure.

Use AI Like a Team — I used Claude and Claude Code throughout to work through this project. I encountered a lot of issues that helped me to refine my process and came to a workflow that worked really nicely to utilize the strengths of each to good effect. Specifically, I leaned heavily on Claude as my conceptual partner to work through any fundamental ideas around gameplay, interaction design, marketing, etc. since its Projects structure allowed it to have deep knowledge of my goals and the history for the project. This was quite different from Claude Code, which had a ton of knowledge of the code base, but very little project knowledge. In the end, I found a good rhythm of working out ideas in Claude, having Claude help develop prompts to feed to Claude Code to implement our ideas. This helped me maintain incredibly fast momentum, with less (though not zero) bad assumptions about what I was trying to accomplish.

Hardware diversity matters early — Protocol incompatibilities with certain trainer models emerged late in development. Earlier testing across the full hardware matrix would have surfaced edge cases sooner.

Player validation trumps metrics — Make the experience great and success will follow. Kids enthusiastically demanding trainer time confirmed the concept better than any analytics dashboard could. Make it fun first; fitness follows naturally.

Document for future-you — Comprehensive guides for physics tuning, Bluetooth integration, and pattern design are paying dividends as I build the remaining Cadence Arcade games. Every solved problem becomes reusable infrastructure.