Project Status & Roadmap

Development and testing

The rating system needs to be evaluated across real matches and may require adjustments as we learn more about its behaviour. Our goal is to refine a consistent, reliable model rather than repeatedly replace the rating engine. We are working towards what we believe provides the fairest assessment of player performance.

We are aware of existing bugs and are improving data collection, server integration and the accuracy of recorded statistics.

What we are working on

• Reliable match collection: improving how statistics are received and processed.
• Rating validation: reviewing match calculations and evaluating whether the model produces consistent and meaningful results.
• Elo-based TDM shuffle: investigating whether Q2Stats ratings can help servers create more balanced teams in the future. This is exploratory work, not an available server feature.
• Player identities: improving nickname and profile handling.
• Match demos: making MVD2 demos available directly from match pages where supported.
• More servers: we hope to connect more servers to Q2Stats as the updated integration becomes available.

Rating development log

Our rating system has evolved through match analysis, community feedback and local testing. This log distinguishes published models from experiments and proposals. Dates identify confirmed milestones; an exact activation time is not available for every change.

By September 18, 2026 · Original Elo / Central Elo v1

Confirmed in use. Ratings started at 1500. Team games used a K-factor of 16; 1v1 used 32. In team games, the result and both teams’ average ratings determined a base change, followed by an individual performance adjustment.

Performance combined kills minus deaths (40%), K/D (25%), net damage (25%) and discipline (10%). Team winners received between 0 and +16; losing players could receive between −16 and +7, depending on performance. Duel used the match result without this performance adjustment.

Strengths: clear emphasis on the team result and team strength, with recognition for strong performances in defeat. Limitations: overlapping performance measures and no individual rating uncertainty.

September 18 marked verified central database calculation, rather than necessarily the first introduction of the formula. On September 24, profile and merged-nickname handling was improved without changing the underlying model.

October 11 · Team Elo v2 / FPR

Published. The performance calculation was revised to give greater recognition to each player’s contribution to the team. Team-average ratings and the result still determined the base change. Historical Team ratings were recalculated; 1v1 remained unchanged.

The revised components were kills minus deaths (15%), K/D (15%), net damage (15%), share of team damage (25%) and share of team frags (25%). A planned 5% Quad/Mega component was inactive where reliable pickup data was unavailable, with the remaining weights normalised.

Strengths: better recognition of players producing a large share of their team’s output. Limitations: contribution shares depend on team composition, some measures overlap, and the model still had no rating uncertainty.

October 20–24 · Performance-adjustment proposals

Proposals and simulations. We explored adjusting the performance reward according to the strongest opponent’s rating, with a multiplier limited to 0.8–1.2, while retaining the base team-result reward. Further Team Elo alternatives were compared on October 24.

The aim was to reduce rewards for dominating weaker opposition. A limitation was that one strong opponent cannot represent an entire team. These comparisons are not recorded here as confirmed live models.

October 25 · Local Glicko experiments

Local testing. We evaluated a modified Glicko-1 model inspired by QLStats, using rating deviation (RD) to represent uncertainty about a player’s rating.

• Starting rating: an early local configuration was changed from 900 to 1500. The later model retained 900 as its rating floor.
• Starting RD: reduced from 350 to 100 to limit early volatility, at the cost of slower adjustment for players far from the starting level.
• TDM win minimum: tested a minimum gain of +2 to prevent zero or negative changes after a team win. This can contribute to rating inflation.
• Team contribution: tested damage relative to the team average, then replaced it with the player’s share of total team damage.
• RAPM: tested a combination of 75% Glicko and 25% Regularized Adjusted Plus-Minus to account for line-ups and results. This added complexity and data requirements and was not selected for production.
• Inactivity: disabled time-based RD increases. Keeping players with fewer than 20 matches outside the leaderboard was discussed but deferred.

October 25 · Glicko-1 with team damage share

Production model. The selected configuration used a starting rating of 1500, starting RD of 100 and minimum RD of 30. Team and 1v1 ratings were separate, with no time-based RD increase. RAPM was not included.

Team performance combined 5 × (kills − deaths) + 0.07 × damage dealt − 0.04 × damage received, plus a contribution bonus of 50 × the player’s share of team damage. These are performance points, not direct rating points. Performance comparisons against opponents feed into Glicko alongside ratings and RD. TDM team wins have a minimum gain of +2.

Strengths: individual uncertainty, recognition of damage production and team contribution, and support for productive offensive play even when a player receives substantial damage. Limitations: the player’s own line-up strength is not explicitly modelled as in the earlier team-average approach; support roles are difficult to measure; low RD can produce small changes; and the win minimum can contribute to inflation.

This was a shift from starting with the team result to placing greater emphasis on individual performance against opponents. Subsequent database migration fixes were installation changes, not additional rating models.

October 29–30 · More responsive 1v1 Glicko

Accepted October 29; documented October 30. The duel calculation changed its Glicko constant from q = ln(10) / 400 to q = 3.5 × ln(10) / 400. The Team model, starting rating and starting RD were unchanged.

The aim was greater responsiveness for established duel players with low RD. The factor operates inside Glicko and affects RD development as well as rating changes: it does not simply multiply every match change by 3.5. The exact live activation time is not conclusively established in the available records.

October 31 · Exploring Elo-based TDM shuffle

Under investigation. We are exploring how Q2Stats ratings could support a future team-shuffle feature for TDM. One possible integration would let an OpenTDM server submit player identities to a Q2Stats balance API, receive a suggested team allocation and apply it on the server.

The goal is more evenly matched teams. Identity matching, players without an established rating and server-side integration still need evaluation. This is a future development possibility, not a released feature or a change to the current rating formula.

Known issues

Missing or delayed matches

With the client-based collection method, statistics can remain buffered in the client until a new match starts, delaying their submission to Q2Stats.

Previously, matches were also withheld from submission if complete player statistics were unavailable—for example, when a player disconnected before the match ended. The updated OpenTDM integration addresses these issues by reporting statistics directly from the server.

Missing statistics after a disconnect

A player disconnecting before the end of a match can still result in incomplete or missing player statistics with the current collection method. The updated OpenTDM version will resolve this by retaining their match statistics after they disconnect.

Demo availability

MVD2 demos depend on server support and may become available later than the match statistics.

What comes next

An updated version of OpenTDM, being developed and tested with Claire, will allow server owners to submit match statistics directly to Q2Stats.

As testing progresses, we plan to expand this integration to more servers and publish setup instructions for server owners who want to participate. Direct server reporting will make collection more reliable and reduce dependence on spectator bots and the Q2Stats server uploader.

Help us improve Q2Stats

When reporting a problem, please include the match link or ID, server, map and approximate time.

Discuss development, report bugs and share suggestions on our Q2Stats Discord ↗.