An IRL bike racer’s experience in his first winter of cycling eSports races. (Part 2)
Part 2: Figure out what is actually going on.
Let’s be honest, cycling eSports is a cycling inspired video game. It is NOT (at least so far) a cycling simulator. This means that while you do ride a bike to play the game, the bike is just a controller for something quite different from racing a bike. First and foremost, you can’t crash and you can’t cross wheels with others. This lack of basic physical realism means you can just go mashing around full gas without being concerned for others’ or your own safety. The cascade of affects on the racing goes deep — to the point that cycling eSport racing is really only recognizable as a bike race because the avatars are on bikes! 🔥🔥
But wait, this isn’t a bad thing, it just means this is an entirely different bike racing discipline that has similar physiological demands to road racing and time trialing (read it’s good training). Given this, I wanted to go on a bit of deep dive to figure out what is really going on and what makes these games tick.
Sticky Draft
My first major realization is that the games have a draft power “window” — sometimes referred to as “sticky draft”. In real life, drafting is pure physics and actually quite complicated. The algorithms cycling eSports platforms use aren’t open, so it’s not clear exactly how they work, but it seems they go something like:
- if you are going a similar speed to another rider
- and you are within a given distance behind that rider
- you will stay at their speed down to some lower power threshold
- you will have to ride some upper threshold harder than them to pass.
An unfortunate side affect of point 4, is that if you are going slightly faster than a person, the platform will attempt to put you into their draft by slowing you down slightly. Very helpful if your goal is to not overshoot — very annoying if you don’t want to draft them at all! I wasn’t there, but I understand that this was a huge issue in the early days of Zwift racing where races would overtake group rides with lots of sticky draft side affects.
Knowing how to play this draft window is fundamental to playing these games efficiently. I’ll let you google for more info, but this is the case on the two platforms I used this winter — Zwift and RGT — with some minor differences between the two. Note that this aspect of the games is a moving target as the platforms attempt to tune their “physics” to be more enjoyable to play.
In my experience, Zwift has a pretty weak draft affect compared to real life. This makes it a good training platform — I don’t like training on group rides because it’s usually too easy while sitting in. Zwift have made the draft benefit in the group small enough that people on the back still have to work. RGT on the other hand, is more like real life, but when you “get it wrong” and go too hard to just surf the wheels, you can pass up through the group very easily. In larger groups, this causes a washing machine affect that gets really chaotic. Riders shoot to the front let off, fall off the back, rinse and repeat.
The final comment I’ll leave about the “sticky draft” is what some people call the “auto brake”. This is where, when you are going slightly faster than someone but not hard enough for the game platform to let you pass, you get “auto braked”. This would be fine if it were just down to the speed the other rider is going and the other rider isn’t actively accelerating, but all too often the result is the sense that you’ve just been shot out the back of the bunch. The problem was pronounced in early winter 2020 and was improved on RGT and recent updates to avatar interaction on Zwift has introduced what seems similar to “auto braking”.
Dual Recording
In high-level races, you are required to use a smart trainer that is designed to read out within 2% of actual power applied as your primary power source. With most racers also recording power with a power meter, there is the inevitability of mismatch and confusion. There is a solution — the game platforms actually accept both data streams, either as a signal and validation or as two signals that are combined in some way. But this is not currently the situation. Both Zwift and RGT use a single power source and racers routinely create “dual recording” reports after a race. There are multiple platforms that are capable of creating such reports. At the end of the day, they create a curve of maximum power to duration (what is commonly called a critical power curve) for both power sources.
Wanting to understand the ins and outs of smart trainer derived power data vs power meter derived power data, I started playing with data to create my own take on such a dual recording report. One thing led to the other and I had a simple R Shiny app that could do the job. At the time of writing, it is deployed here: https://dblodgett.shinyapps.io/dualR/. In the process of writing the app, I learned a lot and became quite a bit more jaded about this whole business. For example, neither Zwift or RGT pass along information about the serial number or manufacturer of the power data source in the “.fit” file they emit. Another example, Garmin and Wahoo use drastically different metadata to document what equipment they are collecting data from. As a person who works on and understands the power of community standards, this seems like a problem we could solve that would greatly improve the transparency and legitimacy of cycling eSports.
Course Design
Bike races are dictated by the racers that take part and the roads they race on. A tight corner or especially steep hill has a drastically different effect on a race than an open corner or shallow slope hill. On Zwift, you don’t so much design the course you want to ride as you select the pre-defined route you want to ride or race on but the effect is the same. This, coupled with the fact that cornering doesn’t affect a group on Zwift in a real-to-life way (basically not at all), means that Zwift is really more about selecting the climb duration and spacing you want with “crits” generally having many short climbs and road courses having spaced-out short or long climbs if any.
With RGT Magic Roads, you have the opportunity to create your own road geometry — either matching real world conditions or creating a custom course to suit your needs. This became a deep fascination for me. My day job is in hydro and geo informatics so I was already equipped to work on the “.gpx” files involved and as a long time road racer, I had some idea of how certain course details would affect a race.
In The RAGE QUIT section of this post I discuss the difficult cornering dynamics in RGT with a large group of riders. Some experimentation led me to the conclusion that, if RGT’s algorithm wouldn’t send an avatar on a “race line” then I would create a race line in a Magic Road .gpx file. The result is a shiny app called gpxr currently hosted here: https://dblodgett.shinyapps.io/gpxr/. Similar to dualR described above, gpxr resulted from a series of investigations and learning experiences both into the cycling and R development aspects of the projects.
The ability to create your own race course is pretty neat! The RGT community (over on rgtdb.com) is thriving and features all kinds of fun and silly things.
That’s probably enough for this post. Note that this is part 2 of this series. Part 1 was something of an introduction and summary of my initial impressions of cycling eSports. Part 3 will talk about my experience of finding my strengths (and winning!) and a look forward to how I’ll approach training specifically for cycling eSports into the future.
