Yes, on the “bike display” side. The goal with implementing a drafting effect is to make it so the bike trainer provides less resistance than it would if you were not drafting. Back in the NetAthlon days, there were only two things you sent to the trainer that would affect resistance:
- percent grade
- rider weight
For many trainers we supported, rider weight was something you sent the trainer once during initialization, so really the only thing available was percent grade. So the only way to implement drafting was to send the trainer a percent grade that was less than the actual percent grade of the terrain the rider was on.
As a side note, this discussion is bringing back memories of some design decisions we made with NetAthlon and how it differs from Zwift. I think that overall there isn’t much of a comparison between the two: Zwift is clearly so, so much better! I really like their decision to base your in-game speed on your power output, even for bike trainers that are able to accept percent grade change requests. We decided instead to go with speed values we received from the interactive bike trainers because we felt that it was important for the speed values you saw in NetAthlon actually matched what your trainer or bike computer displayed. Now that I’ve ridden Zwift a few times, I realize their way is better. We had a problem in NetAthlon when folks were riding together using trainers of different brands. A good example is a Velodyne going against a Computrainer. I have a Velodyne, which has a massive flywheel. A Computrainer has a tiny one. If I was riding against a Computrainer and we both started up a hill, my flywheel’s momentum would allow me to carry some speed into the hill. The resistance on the Computrainer would kick in much quicker, so I’d leave the other rider behind. The opposite happened when we started downhill; it would take me a little while to get the flywheel up to speed while the Computrainer rider would shoot past me.
One thing that I like better (maybe the only thing) is that early on we were not satisfied with how our prototype environments (we called them “courses”) portrayed small variations in terrain grade. That is, when you were on a 0% slope (flat terrain), it really didn’t look much different that 1% or -1%. So we decided early on that we would build our courses so that the terrain was 2 times normal. That is, if a top of a hill was really 50m, we would make it 100m. In the game code, we would then figure out the slope of the terrain the bike was on and divide that by 2 before sending the grade to the bike trainer. We felt like this made it easier to look at the scene and be able to anticipate grade changes more easily. Earlier today, I rode the flat London loop on Zwift. Although this route is pretty flat, there are a few grade changes with the max being about 4%. It was really hard to see when the terrain started to go up or down. I find that I’m constantly looking at the percent grade value displayed in the map.