I suspect I’d get significant value from writing about systems earlier in their development because breaking a system down in words often leads to new insights. Over the past week I’ve been thinking about my recent post on how online skill ranking works in INVERSUS Deluxe. If you haven’t read it or aren’t deeply familiar with skill rating systems, you might want to click that link or the rest of this won’t make much sense.

One of the primary hurdles that I had integrating Glicko-2 (and that most games have from my understanding) was applying the rating periods. INVERSUS forces a rating period to pass with each completed match and then also runs a separate step forcing inactive rating periods to be evaluated for players that have been away from the game for a while. This has two downsides:

• Depending on the frequency you play matches you will evaluate more or less rating periods than others.
• Rating periods never get to evaluate more than one match at a time (which would be preferred by Glicko). That said, I haven’t run through the math to know how much that actually matters.

I now believe that you should be able to get the best of both worlds and let rating periods get a fixed time (e.g. a week) but still give players instant feedback after each match. The idea is to change the interface to process less than one rating period and take input representing the intermediate computations from any prior call. It would then update the intermediate state to be used by a future call and output what the players rating, deviation, and volatility would be as of right now (partially through the rating period). Internal to the system, it would continue to append match results to the intermediate state and reevaluate the current rating period from scratch with the additional supplied information. The resulting logic  would be something like:

1. If the additional time step has advanced to a new rating period, commit the prior rating period’s variance estimate into a new rating, deviation and volatility.
2. Apply any necessary inactive rating periods if the time step is greater than one rating period.
3. Apply the new match results to the tracked intermediate values necessary for computing the current rating period’s variance estimate. Note that we shouldn’t actually need to track the full match history for this rating period, but just need to update the accumulated values.
4. Output the player’s displayable rating and deviation by evaluating the current intermediate values for the partial rating period state. Note that these values are actually logically recomputed across the entire current rating period until step 1 commits them and starts a new rating period on a future call.

I’m pretty sure that would both work and not be too complicated implement. Maybe someday, I’ll go back and try it out, but for now I just want to put the idea out there for others!