Dear players,
We know many of you have been asking for a detailed explanation of how Race-day Condition works in PCM26, as well as the reasoning and vision behind the system. We also want to apologize for not sharing these explanations sooner.
The development team has taken the time to clarify the choices behind the new system, how it differs from previous versions, and what we are considering for its future.
Before explaining some of the choices behind this system, it is important to outline the vision we have for it.
The purpose of the Race-day Condition (RDC) system is quite simple: it aims to serve two objectives:
To represent a realistic, but also somewhat romantic, aspect of sport: the human body is not a machine. Even though modern cycling can sometimes make us forget this due to the dominance of certain riders, nothing is ever guaranteed in advance. To win a race against more than 150 competitors, it helps to be having a good day.
To add some spice to the gameplay: having a positive or negative RDC can force you to rethink your strategy. Sometimes it affects your leader, sometimes your domestiques. Not everything is decided beforehand, and this aspect is also important in creating a wider variety of situations.
Our vision for RDC is not to create a flat system, but rather one that preserves a degree of uncertainty.
As a reminder, the previous Race-day Condition system was based on two components:
A predictive component that combined various parameters providing positive and negative modifiers. The sum of these modifiers determined the predicted RDC.
A random component calculated around that predicted value.
The system showed promise in its early years, but over time we gradually reduced the influence of randomness. The possibility of receiving a negative RDC despite having a positive prediction was often poorly received by players.
Over time, RDC almost stopped being RDC at all. The system had become highly predictable and no longer aligned with the vision described above.
The new system returns to an approach that is more closely aligned with this vision and is built around two components:
A primary component that distributes Race-day Condition values. It is based on the connection with the Special Attributes (Stage races focus, Classics focus).
A small secondary component that can occasionally modify Race-day Condition.
The primary component is based on a new system created specifically for this purpose, which we call a “pool of values”. It contains values ranging from -3 to +3.
Rather than using a traditional random system that draws values based on fixed probabilities, the pool system is better suited to our vision for Race-day Condition.
At the start of each race (whether it is a classic or a Grand Tour), a pool of Race-day Condition values is created for each rider.
These pools are built from a common base that depends on the number of stages, to which values based on the relevant Special Attribute are added (Stage races focus or Classics focus, depending on the type of race). When a Race-day Condition value is drawn, it is removed from the rider’s pool and can therefore no longer be drawn again during the race.
Adjusting the specific values provided by the Special Attribute gives us greater control over the draw and, for example, allows us to make a rider with a low “Stage races focus” value (D or E) more unpredictable in a Grand Tour.
The secondary component can add between -2 and +2 to the value previously drawn through various factors: motivation, reconnaissance training camps, fatigue, and Fitness Peak.
One question that comes up regularly is: why remove certain features over the years?
It is perfectly understandable to want to keep existing features while continuing to add new ones. However, the situation is more complex than it may appear.
Removing or evolving certain features is sometimes necessary.
There are two main reasons for this:
The first is development-related. With a team that remains roughly the same size, maintaining a game that continues to grow every year is already a considerable challenge. A feature is not just something that exists on the surface: it must be developed, tested, balanced, maintained, and remain compatible with all the other systems.
The second concerns the overall consistency of the game. Gameplay systems are built around a vision that is naturally influenced by player expectations, but that must also remain consistent as a whole. Maintaining this consistency is already challenging when many systems coexist; it becomes even more difficult if every idea is added without considering its consequences for the overall experience.
It can also happen that features or behaviors disappear unintentionally:
Almost all feedback focuses on what bothers you. The things that are enjoyable are often mentioned less or eventually forgotten, and that is normal: once something works well, we do not necessarily keep repeating it. There have already been cases where we removed something from the game and only realized afterwards, through feedback from a large part of the community, that it was actually a good element. Sometimes something perceived as cool can also be an element that was poorly designed from the beginning or that we are uncomfortable with (a flawed design, which can happen more often than you might think in an iterative series), and that makes things more difficult to deal with.
An oversight… yes, that can happen. Even with a great deal of attention, the size of the project and the large number of small features mean that we can always miss something.
When it comes to Race-day Condition, the decision was deliberate and intentional.
Because the new Special Attributes are closely tied to this system, it was decided from the outset that it could not be disabled. Without it, the Special Attributes would lose much of their value and, more importantly, stage races would no longer generate alternative Race-day Condition values from day to day, which would significantly reduce the realism of the system. While our goal remains to make as many aspects of the game configurable as possible, we simply cannot make everything optional.
Another important consideration is that every feature requires design, development, balancing, and testing time. Whenever a system is created or reworked, many interesting ideas naturally emerge. Ideally, we would all like to include everything, but that is not always realistic.
In this specific case, adding multiple options to customize or adjust Race-day Condition would have further increased the complexity of the system's design, settings, and balancing.
We understand that this is an important point for some of you, and we are therefore considering adding an option related to Race-day Condition in a future update, allowing us to find a compromise between the intended vision and the request to customize the experience.
In the short term, meaning for a future update, we therefore have two elements:
The return of an option allowing players to customize the experience.
A small adjustment to the values in the pools to generate slightly more positive values overall.
In the longer term, we would like to further develop the system:
Work on feedback and information to improve understanding of the system and its connection with the Special Attributes.
Allow players to have some influence over the system, somewhat along the lines of the “Willpower” skill in Pro Cyclist, so that they can play around with values that are otherwise imposed on them.
Finally, weather is also something we would like to integrate, but in a different way from the previous system, which we no longer considered sufficiently satisfying.
These three points are ideas we are considering, but they are not promises at this stage.
Thanks for reading us,
TikTok X (Twitter) Facebook BlueSky Instagram Discord