Turning a noisy GPS trace into a "you rode this segment, in this direction, at this time" wass a real problem, so I used an HMM map-matcher — Newson-Krumm / Viterbi, the same family OSRM and Valhalla use. Candidate road edges are the hidden states, the emission probability is a Gaussian on how far each fix sits from an edge, and the transition probability punishes disagreement between along-road distance and straight-line distance. It's direction-aware (forward, reverse, and out-and-back all mint separately) and this was shockingly difficult to implement.
The thing that actually makes it fun is that the racing happens during the ride. When you hit a segment you're chasing, you get a live +/- against a ghost of the current holder. Originally this came in as a static ghost divided evenly by the total time, however, that is not accurate so now we use an actual reconstruction of their splits, so if they went out hot and you're clawing it back on the second half, you see exactly that, in real time. Instead of one all-time board that goes hopeless, crowns live on rolling windows (today / this week / this month / all-time), so there's almost always a bar that's genuinely in reach. That's a direct fix for the "my PR is unreachable on 19 of 20 rides" problem every mature Strava segment eventually has. And we added something called Keeps & Trials which, think Pokemon Gym, where time degrades over time on short circuits to allow you to race them over and over and over.
Map coverage is demand-driven. I was tempted to just map everything all at once, but I didn't want to just blow cash on hosting for the world when it isn't needed. So rather than pre-ingest everything, now when a rider shows up somewhere new, the area gets tiled with H3 hexes (Uber's hex grid, res 5, ~100 sq mi a cell) and only the uncovered hexes trigger a road-graph build from OSM/Overpass. The hex index is the dedup key, so the rule is literally "never ask the API for a place we already have," and the map fills in exactly where people ride and nowhere they don't.
Sensors are BLE GATT against the standard profiles — FTMS for smart trainers, Cycling Power (including pedal balance and the whole Zwift controller matrix: Click, Play, Ride, Sterzo), heart rate, speed/cadence. On the phone that's CoreBluetooth; on the desktop/world side there's a native Rust BLE stack so the same sim can run off a real trainer. Although, I don't own a power meter to validate that in the real world so if anyone wants to do that....
TLDR; I basically wanted to create something that combines my virtual world efforts in Zwift with my real world efforts and both matter. Racing tying it all together. Creating the bike computer was delightful and easy. I am really confused by how hard the virtual world is to create, but then again GTA6 took like 42 years, so maybe I shouldn't be surprised.
Technicals:
Turning a noisy GPS trace into a "you rode this segment, in this direction, at this time" wass a real problem, so I used an HMM map-matcher — Newson-Krumm / Viterbi, the same family OSRM and Valhalla use. Candidate road edges are the hidden states, the emission probability is a Gaussian on how far each fix sits from an edge, and the transition probability punishes disagreement between along-road distance and straight-line distance. It's direction-aware (forward, reverse, and out-and-back all mint separately) and this was shockingly difficult to implement.
The thing that actually makes it fun is that the racing happens during the ride. When you hit a segment you're chasing, you get a live +/- against a ghost of the current holder. Originally this came in as a static ghost divided evenly by the total time, however, that is not accurate so now we use an actual reconstruction of their splits, so if they went out hot and you're clawing it back on the second half, you see exactly that, in real time. Instead of one all-time board that goes hopeless, crowns live on rolling windows (today / this week / this month / all-time), so there's almost always a bar that's genuinely in reach. That's a direct fix for the "my PR is unreachable on 19 of 20 rides" problem every mature Strava segment eventually has. And we added something called Keeps & Trials which, think Pokemon Gym, where time degrades over time on short circuits to allow you to race them over and over and over.
Map coverage is demand-driven. I was tempted to just map everything all at once, but I didn't want to just blow cash on hosting for the world when it isn't needed. So rather than pre-ingest everything, now when a rider shows up somewhere new, the area gets tiled with H3 hexes (Uber's hex grid, res 5, ~100 sq mi a cell) and only the uncovered hexes trigger a road-graph build from OSM/Overpass. The hex index is the dedup key, so the rule is literally "never ask the API for a place we already have," and the map fills in exactly where people ride and nowhere they don't.
Sensors are BLE GATT against the standard profiles — FTMS for smart trainers, Cycling Power (including pedal balance and the whole Zwift controller matrix: Click, Play, Ride, Sterzo), heart rate, speed/cadence. On the phone that's CoreBluetooth; on the desktop/world side there's a native Rust BLE stack so the same sim can run off a real trainer. Although, I don't own a power meter to validate that in the real world so if anyone wants to do that....
TLDR; I basically wanted to create something that combines my virtual world efforts in Zwift with my real world efforts and both matter. Racing tying it all together. Creating the bike computer was delightful and easy. I am really confused by how hard the virtual world is to create, but then again GTA6 took like 42 years, so maybe I shouldn't be surprised.