The points inflation and weighting by events problems are already solved elsewhere. I’m sure there are other similar systems, but the FIS ranking system, for example, works for events with large number of starters, uses best 3 ranks from top 5 event finishers to establish event base points, is asymptotic to zero (it’s a lower-is-better system, and racers gravitate towards zero without ever reaching it), and has a built-in points penalty system to cater for race type/duration (used in Nordic events). Racer points are based on best 5 events in last 12 months, which automatically makes your points degrade if you don’t participate in events to a certain regularity.
Forgot - individual points for an event are based on the race base points (3 best ranked in top 5), race penalty, and the ratio of an individual’s time over the winner’s. So no matter the race length or your placement, you always have an incentive to be as fast as possible, regardless of your position in the race. In other words: finishing within 1% of the winner’s time pays the same, regardless of the number of other racers between you and the winner.
The wheel exists, it does not need to be invented.
Robert, let me make sure I understand this. Correct me if I’m wrong, but what you’re saying is that there is already a working system in another sport that is not particularly sensitive to the number of participants in a race (except maybe races with very few participants) and not sensitive at all to race distance or difficulty because of the 1% thing? A system, even, that promotes a reasonable (as opposed to unreasonable) amount of race activity and that also promotes making your best effort in every race?
Wow.
Let’s do some thinking here. To implement such a system you would need to collect a whole lot of data of course and then do many calculations on it. So let’s go through the entire list of types of datapoints needed for a model implementation to work. For all participants in every ‘official’ race Zwift would have to collect:
- PLACING
- FINISH TIME
Looking right now at the Zwift Companion app, to my surprise I get the impression that Zwift does in fact already collect every point in this list. There is more to the model but they seem to be just constants. Zwift even seems to store the above datapoints long term, because I notice that I can go back in time and see my placings and finish times in races way back. I can also look at my competitors’ placings and finish times in those races.
So then, this big project, if we imagine for a second that Zwift would set out to implement a FIS style categorization, would require quite a bit of work on their behalf. Let’s see now. We play that we are chief product owners here for a minute, so let’s rough sketch this project from start to finish.
First, they would need to add at least one, probably two new fields to every subscriber profile. Two new columns in some database table. One for the rank score. And then, for convenience, another one for race category. This could take several minutes to add.
Then you need a server side application to calculate the stuff going on in the model for every race and then update the subscriber profiles with any resulting changes. You also need to feed the race reports. This is way worse. It might take a skilled developer a whole day to code all of this, but let’s be generous and give them a full week.
Then you need to visualize this somehow to the subscribers. Some changes are needed to the interface. This would be a completely different team’s responsibility, although one that would normally work in parallel with the model application team. But it’s gonna take quite a bit of time nevertheless. Let’s give the frontend team a week of their own too, and let’s make it a week where nobody else does any job on the project.
The model is going to affect race generation too or there would be no point to it. Instead of the current free choice, subscribers will now be forced into a specific category (making ZP redundant). This could take a whole day too but let’s plan for the standard week again.
We’re up to 3 weeks already! And as we all know any project always takes longer than expected, even when you try to account for that fact. But let’s cut them some preliminary slack and make it a full month.
Then, or actually before you start any of the above tasks, you need to have a couple of data analysts look at suitable numbers of categories, project optimal category sizes, look into the seasonality issue, some validity reality checks on historical data, report all of this back to some manager etc etc. That could take a full month.
Even before the analysts come into play, and in fact during the entire project, management needs some time to sit and discuss everything in virtual meetings (it’s still corona days after all). Should we really do this? It seems so scary! Will subscriber numbers take a hit? Risk / consequence analysis plz! Etc. Ok, let’s do it! How do we plan this? Let’s do it so and so. How is the model application team progressing? Any blockers? Blah blah. And so on. Let’s give them another 30 days to spread out over the project, during which nobody else can work on this because they are waiting for meeting appointments and manager decisions.
So that’s 3 months. That means we can look forward to a launch on September 13. Yaaay!
It’s mainly a matter of which year. Will it be 2018 or 2019? Or even 2020?
I seem to have a bit of a cold right now. Very inconvenient. Or I could have cheated today, that was the plan, honestly. But I promise to be a good boy and continue cheating properly like the others as soon as I feel better and get the opportunity. Because I still can, since Zwift and even ZP will allow it.