Drift championship title calculator

The points tables come straight from the 2026 rulebook. Qualifying gives 12, 10, 8, 6 and so on down to 0.1 points. From the battles the winner gets 100, second 88, third 76, fourth 64, the Top 8 48, the Top 16 32 and a first-round exit 16 points.

On equal points the drivers are compared step by step: first event wins, then second places and so on down to 32nd. If that still doesn’t decide it, the result of the season’s last event counts. The calculation uses the same logic when it needs to know whether a tie would give someone the title. On paper it’s a simple table, but every scenario runs through it, so it has to be written exactly as in the rulebook, not “roughly like that”.

A qualifying position doesn’t only give points. It also sets the pairs: first rides against 32nd, second against 31st and so on. If the order is wrong, every scenario after it is wrong too.

The rulebook sorts in nine steps: best run, the sum of both runs, the best run’s line, angle and style, then the weaker run’s line, angle and style, and finally the lower car number. The calculation does this itself from the raw run scores after every new run, so the order is right during qualifying already.

Before comparing, every name is normalised: accented letters become plain letters and punctuation is removed. If a driver isn’t found in the list, they’re added automatically and their season points so far are taken from the same service. That way nobody starts from zero when they actually already have points.

There was a trap here too. The results service adds an event’s points to the season total only after the event ends. If a driver found later had their points taken during the event and again after it, the same event would have counted twice. Now the ongoing event is left out of the season points until it’s over.

What didn’t work: the simulation state still held the battle bracket from an earlier calculation. That driver was in the Top 32 there, and the calculation gave them the points for it even though they weren’t at the real event. A small bug, but exactly the kind that can decide a title wrongly.

How it works now: only drivers actually entered in the event score points. The pairs are rebuilt every time from the current qualifying, not taken from old state. Old state can no longer leak into a new calculation.

There were 25 entrants and 32 slots in the bracket. So in the first round some drivers go through without an opponent. An empty slot counts as a walkover only in the first round, where that can really happen. In later rounds an empty slot means the opponent’s battle is still running. The system must never count that as a walkover, or someone would get a win they haven’t earned yet.

Second surprise: the results service doesn’t always place walkovers by the usual scheme (first against 32nd, second against 31st). So the calculation doesn’t guess the pairs, it takes the actual pairing from the results service’s bracket.

For each contender and each possible final result, the system works out how far the other four can get for that situation to still hold. That becomes a plain sentence, for example “becomes champion with 3rd place IF rival A doesn’t get past 2nd AND rival B goes out earlier”.

The list gets shorter as the event goes on. Once a rival is in the Top 8, every scenario that needed them out earlier disappears straight away. Viewers only ever see the options that are still genuinely open.

The other 20 drivers can’t become champion, but they take places and points from the contenders. A separate block shows what happens if one of them wins the super final or takes a podium: which contenders gain and which lose. This was often the most interesting part, because an outsider’s win could decide the title more than the contenders’ own battles.

All viewers get updates as a live stream from one shared state file. The results service is asked for data only once per time window, however many people are watching: the state file holds the time of the last request and every viewer sees it.

How often it asks depends on the stage of the event. Once a minute before the start and after the end. Every 5 seconds during qualifying, as often as the results service’s own broadcast graphics. Every 15 seconds during battles, because a pair runs for several minutes.

What didn’t work: the development server handles one request at a time. An open live stream held it up and everything else had to wait. Now the server sends the current state straight away and closes the connection, and the browser reconnects on its own. To the viewer it still looks like a live stream.

It happens: judges correct scores and in the meantime the screen shows the wrong standings. The organiser can pause automatic updates with one click and correct the standings by hand. While updates are paused, no new request overwrites the manual correction. Only checked results reach the screens.

The organiser’s changes don’t go out to everyone at once either. A manual fix or a chosen battle winner first stays on the organiser’s own screen in test mode, where they can see what it does to the standings and scenarios. Only the “Send to everyone” button pushes that state to every viewer’s screen. So spectators never see a half-finished or mis-clicked state.