cycling4freaks.com

Hi all,

as I have mentioned a few times, I'm thinking to do a major redesign of the race calculation. To get it started and to get you involved, I first collected a list (pretty much unsorted) of all the issues we have with the race calculation currently. Then I have yet another list with ideas how to improve that, and an idea on how to approach that whole redesign.

Current Situation, unsorted list of general issues (numbered, so it's easier to reference it):

1. bad code quality
   1. one big method spread over multiple files
   2. inconsistent and confusing naming of variables
   3. use of variables with different types in different contexts
   4. complex calculations without explanation
2. high impact of downhill skill on % where it doesn't matter at all. In reality, no downhill skills are needed for *1%
3. downhill riding
   1. road layout doesn't influence tempo in downhill (narrow and winding roads in reality strongly affect speed)
   2. downhill attacks too hard as all roads are considered wide and straight
   3. very steep downhill with rain has unrealistic tempo / attack behaviour
4. climbing
   1. tempo a lot less selective than attacks
   2. attacks very effective, but easier for weaker guys to follow
5. many followers makes attacker slower, esp compared to other attacking groups
6. calculation is based on some internal speed and multiple artificial factors, but not transparently
7. gaps are not calculated based on pure speed, but also with some artificial factors
8. every rider rides the same sector simultaneously
9. no positioning of racers within their groups
10. too low energy consumption while not riding in a fast group
11. too high energy consumption for attacks (basically attacking is not much more than riding fast + surprise element)
12. one-legged climbers / sprinters (flat skill too important or too low)
13. no Windkante / bordure due to missing positioning
14. all roads are the same (all straight and wide)
15. no impact of altitude, only weather, i.e. riding on 4000m should be a lot tougher than on sea level
16. pave behaviour
    1. tough pave not very selective compared to real life
    2. soft pave sometimes too selective, e.g. 3% with *, where climbers are dropped
    3. hilly pave is way too soft, gaps too small
    4. downhill pave very buggy
    5. gaps on pave TTT are huge
17. various sprint issues (see other forum threads)
    1. dependency on actions of others (when without a train)
    2. ass covering (follow others and help an own guy getting a bonus and pushing stronger guys away)
    3. trick sprint (release one part of the train)

Solution Ideas and Approach
Step 0 (community helping with research and finetuning)

1. tools for supporting development for interested users
   1. base model for speed calculation (showing speed, energy consumption, etc.)
   2. speed calculated based on skills, energy, form, road surface, draft, road width, curvyness
   3. transparent calculation based on actual speed rather than some virtual values with bonus / malus
   4. simulating simple race situations
2. races continue with old race engine

Step 1 (first test races)

1. test races (maybe special races with retired or youth riders) in parallel possible for new race calculation
2. new base model for speed calculation using all the parameters (skill, energy, form, surface, incline, etc)
3. more realistic energy consumption
4. basic race calculation implemented (tempo, attacks, following, dropping, merging / splitting groups etc.)
5. final sprint probably still unchanged
6. no realistic positioning yet (i.e. everybody shares the same position within a group)

Step 2 (finalization)

1. different sector lengths, surfaces (gravel), bonifications on all sector types
2. extending race editor to support new features
3. real positioning in groups
4. new features related to positioning (bordure, real gaps between groups, realistic following)
5. final sprint based on real positioning

I wanna keep the first post up-to-date, so I'll have a short one here now:

• don't expect any quick solutions, maybe the redesign will take a year or two, or maybe not
• feel free to comment, if I missed anything or something's awfully wrong
• if you wanna support the development a little bit, let me know, and I'll make the development tools (not much yet) visible

It would be nice if you find some time for this, but I do not expect it to be easy. Buh was a tinkerer, and he tinkered for good reasons. I believe it is possible to do it better, but it easily ends up in a system that is not fun to play. Unlike front-end design, number crunching is something I could help with, even if I do not want to spend much more time with the game.

To some concrete points:
(1) It is clear that it must be a complete redesign, not tinkering with the existing code.
(2) For sprint, it is a nice feature that downhill matters and the dynamic changes between races. Maybe we can get something similar with straight finishes vs. narrower and curving finishes.
(3) Downhill only works with positioning. In reality, it is more splits than attacks. If somebody doesn't invest in the position, he risks ending up in the second group, even with high downhill skills. The risk is that it becomes too easy and is used much more often in-game than in reality.
(12), and everything between (4) and (11): The difference between a classics rider and a climber is that the climber can put in the power on the climb for longer. To get this in-game, we would need a second energy pool that is short-term. The classic can dig deep into this reservoir to attack or ride a short climb, and can regenerate quickly. Climbers need a long climb with a steady tempo to drain the short-term energy of the classics to get rid of them. They are still weaker in flat (less weight than explosive riders), but not as helpless as they are now. As attacks and intermediate sprints go heavily into the short-term energy, it is not as punitive to move early on. As this would change the mechanics completely, it is certainly the hardest part.
(17) Another complete rewrite. Maybe again, launchers need to be better to keep tempo for a long time, while pure sprinters can do very high tempo for 100 m. Ideally, the system would track speed as well as position (must be shown in the sprint screen in some form). Some draft for the riders in the neighboring row would help as well to make it easier to beat trains. Maybe allow a setting, sprint if the guy in front stops, to make trick-sprinting harder.

For testing, we should create a different race series. Youth teams were suggested, retired riders are nice as well, but hard for new teams. Women's teams are possible as well. Just make it interesting for more teams to join testing without influencing the base game.

Those are my first thoughts. I will certainly have better suggestions later, after I read more suggestions and maybe more details about Alk's ideas.

I like the idea of using special race types for testing / improving the new race engine, I'll add it in the first post. But that's already something that only can start in the second phase

Radunion wrote: ↑

Sun Mar 01, 2026 5:08 pm

(12), and everything between (4) and (11): The difference between a classics rider and a climber is that the climber can put in the power on the climb for longer. To get this in-game, we would need a second energy pool that is short-term. The classic can dig deep into this reservoir to attack or ride a short climb, and can regenerate quickly. Climbers need a long climb with a steady tempo to drain the short-term energy of the classics to get rid of them. They are still weaker in flat (less weight than explosive riders), but not as helpless as they are now. As attacks and intermediate sprints go heavily into the short-term energy, it is not as punitive to move early on. As this would change the mechanics completely, it is certainly the hardest part.
(17) Another complete rewrite. Maybe again, launchers need to be better to keep tempo for a long time, while pure sprinters can do very high tempo for 100 m. Ideally, the system would track speed as well as position (must be shown in the sprint screen in some form). Some draft for the riders in the neighboring row would help as well to make it easier to beat trains. Maybe allow a setting, sprint if the guy in front stops, to make trick-sprinting harder.

I think the idea with a second energy pool is very good, it would allow to implement more stuff like you suggested.

A lot of this sounds like making the game even more complex. Although it might get more realistic, I don't know how playable it still will be. So before making the game more complex, I would like to have better known current bugs fixed first in my opinion, f.e. downhill pavé, climbs over 15%, etc. Meaning changes that don't add new mechanics to the game, but improve the existing mechanics.

There might be a point to point answer the next days, depending on time and motivation. Hope this helped too

team fl wrote: ↑

Sun Mar 01, 2026 7:57 pm

A lot of this sounds like making the game even more complex. Although it might get more realistic, I don't know how playable it still will be. So before making the game more complex, I would like to have better known current bugs fixed first in my opinion, f.e. downhill pavé, climbs over 15%, etc. Meaning changes that don't add new mechanics to the game, but improve the existing mechanics.

Actually the main idea is first to make the calculations transparent, within the code and as a side effect, also to the players. Only that really allows to fix all those bugs in a good way. Further new features can only be added once that first step is done, but no need to worry too much about that right now.

What I am curious about is: where do you want to get the information about the road layout? I mean for some climbs in the Alps I know it from watching TV, but this Information will not automatically pop up from the gpx file but needs to be specified in the designer maybe as a separate column. What I want to say is: even if we can simulate different road layouts at a specific point in the future, will it be realistic to being able to use that new simulation?

flockmastoR wrote: ↑

Sun Mar 01, 2026 9:19 pm

What I am curious about is: where do you want to get the information about the road layout? I mean for some climbs in the Alps I know it from watching TV, but this Information will not automatically pop up from the gpx file but needs to be specified in the designer maybe as a separate column. What I want to say is: even if we can simulate different road layouts at a specific point in the future, will it be realistic to being able to use that new simulation?

Good point, but my idea would be to use it only for the most important sectors, e.g. at the Belgian classics like this weekend. In general, it can also be roughly calculated, if the road is rather straight or not by measuring the distance between start- and endpoints

Alkworld wrote: ↑

Sun Mar 01, 2026 10:15 pm

flockmastoR wrote: ↑

Sun Mar 01, 2026 9:19 pm

What I am curious about is: where do you want to get the information about the road layout? I mean for some climbs in the Alps I know it from watching TV, but this Information will not automatically pop up from the gpx file but needs to be specified in the designer maybe as a separate column. What I want to say is: even if we can simulate different road layouts at a specific point in the future, will it be realistic to being able to use that new simulation?

Good point, but my idea would be to use it only for the most important sectors, e.g. at the Belgian classics like this weekend. In general, it can also be roughly calculated, if the road is rather straight or not by measuring the distance between start- and endpoints

Does that mean we won't ride kilometer per kilometer but simulate all meters in live ?

Pokemon Club wrote: ↑

Sun Mar 01, 2026 10:53 pm

Alkworld wrote: ↑

Sun Mar 01, 2026 10:15 pm

Good point, but my idea would be to use it only for the most important sectors, e.g. at the Belgian classics like this weekend. In general, it can also be roughly calculated, if the road is rather straight or not by measuring the distance between start- and endpoints

Does that mean we won't ride kilometer per kilometer but simulate all meters in live ?

No, we'll still ride km by km (or better: sector by sector), but the most important sectors can have (slightly) different lengths. E.g. the Muur in Geraardsbergen (https://climbfinder.com/de/anstiege/mau ... ardsbergen) could be two sectors: first 700m not that steep, last 500m steeper. In the game, we'd then ride two sectors, but it would only be 1.2km in total.

Alkworld wrote: ↑

Mon Mar 02, 2026 9:07 am

Pokemon Club wrote: ↑

Sun Mar 01, 2026 10:53 pm

Alkworld wrote: ↑

Sun Mar 01, 2026 10:15 pm

Good point, but my idea would be to use it only for the most important sectors, e.g. at the Belgian classics like this weekend. In general, it can also be roughly calculated, if the road is rather straight or not by measuring the distance between start- and endpoints

Does that mean we won't ride kilometer per kilometer but simulate all meters in live ?

No, we'll still ride km by km (or better: sector by sector), but the most important sectors can have (slightly) different lengths. E.g. the Muur in Geraardsbergen (https://climbfinder.com/de/anstiege/mau ... ardsbergen) could be two sectors: first 700m not that steep, last 500m steeper. In the game, we'd then ride two sectors, but it would only be 1.2km in total.

Does this also mean, that we could ride more than 1km on sectors with a lot of flat, straight, unchanging streets? So e.g. 3km as one sector?

Chemnitz Pro Cycling Team wrote: ↑ Does this also mean, that we could ride more than 1km on sectors with a lot of flat, straight, unchanging streets? So e.g. 3km as one sector?

Probably not, attackers would gain too much time against a rolling group.

Radunion wrote: ↑

Mon Mar 02, 2026 10:44 am

Chemnitz Pro Cycling Team wrote: ↑ Does this also mean, that we could ride more than 1km on sectors with a lot of flat, straight, unchanging streets? So e.g. 3km as one sector?

Probably not, attackers would gain too much time against a rolling group.

From a technical perspective, it would be possible, but if it makes sense from gameplay perspective is a different topic.

Alkworld wrote: ↑

Mon Mar 02, 2026 10:50 am

Radunion wrote: ↑

Mon Mar 02, 2026 10:44 am

Chemnitz Pro Cycling Team wrote: ↑ Does this also mean, that we could ride more than 1km on sectors with a lot of flat, straight, unchanging streets? So e.g. 3km as one sector?

Probably not, attackers would gain too much time against a rolling group.

From a technical perspective, it would be possible, but if it makes sense from gameplay perspective is a different topic.

If min-tact depends on actual speed (but still 2x faster than real life) that would be intuitive from gameplay perspective. For example, let's say Pogi on an alpine climb goes uphill 30km/h downhill 90km/h (numbers chosen for simplicity). That means uphill km takes 2min in real life, downhill km takes 40 seconds in real life. In-game, the uphill could be 1min and the downhill 20 seconds. To be fine-tuned of course, but you get the principle.

But that's just one small detail... So on the general discussion:

Alkworld wrote: ↑

Sun Mar 01, 2026 3:33 pm

1. test races (maybe special races with retired or youth riders) in parallel possible for new race calculation

For Testing, perhaps another idea: In oder to have many participants, we could perhaps offer one (additional) edition on days whenever there is only a Cat.1 One Day Fantasy Race. E.g. have 1 out of 5 editions use the new 'Race Calculation' whilst 4 out of 5 editions use the old 'Race Calculation'. The Time can even be selected such that it is convenient for Alk. But count the race as normal race, normal prize money, etc. That might invite more people to help testing than having a side show somewhere.

Gipfelstuermer wrote: ↑

Mon Mar 02, 2026 12:11 pm

Alkworld wrote: ↑

Mon Mar 02, 2026 10:50 am

Radunion wrote: ↑

Mon Mar 02, 2026 10:44 am

Chemnitz Pro Cycling Team wrote: ↑ Does this also mean, that we could ride more than 1km on sectors with a lot of flat, straight, unchanging streets? So e.g. 3km as one sector?

Probably not, attackers would gain too much time against a rolling group.

From a technical perspective, it would be possible, but if it makes sense from gameplay perspective is a different topic.

If min-tact depends on actual speed (but still 2x faster than real life) that would be intuitive from gameplay perspective. For example, let's say Pogi on an alpine climb goes uphill 30km/h downhill 90km/h (numbers chosen for simplicity). That means uphill km takes 2min in real life, downhill km takes 40 seconds in real life. In-game, the uphill could be 1min and the downhill 20 seconds. To be fine-tuned of course, but you get the principle.

Thought about this for quite a while too, it would bring a more realistic dynamic into the simulation, but it also would make planning of the stage more challenging. For example when I need to be off during a specific time on a stage race, calculating what km span this will result in would be way harder. But maybe that is just a minor issue.

Technically it would mean to add more km change scripts, not sure if thats bad or doesn't matter

flockmastoR wrote: ↑

Mon Mar 02, 2026 12:30 pm

Technically it would mean to add more km change scripts, not sure if thats bad or doesn't matter

Technically it's a no-go from server perspective, as every race calculation triggers the red light during the race. No need to increase that further. From the sector length, I'd keep it as simple as possible and only use that feature where it really makes the race more realistic, e.g. on the Hellinge in Belgium. In most races, it wouldn't matter much.