OPR/DPR/CCWM Conversion Factor From NBN to Starstruck

Hey so even though vexdb.io is down, I was curious as to how I could compare my robot’s OPR to NBN values, so I want to know what would be an appropriate conversion factor to do so? I know they’re wholly different games, but I still feel there has to be some sort of trend among the OPRs of both seasons’ world-class robots.

This is what I’m talking about:
Starstruck OPR x (conversion factor) = NBN-equivalent OPR

I don’t think you can really compare it well, since NBN was maxable while SS is back and forth. In NBN the matches in worlds round robins had some of the highest scores of the season, while in SS there is no reason why the top level matches should have scores any higher than lower level matches. Hanging raises the score, but that’s it. Your OPR will depend a lot on how bad your opponent is as well as how good you are.

Isn’t it how good you are relative to your opponent?

These are two wildly different games with different strategies for comparison. SP differentials in this game will probably be relatively small compared to NBN. You can control to have one more point/star/cube at the end of the match to be dumped on the other guy. Winning by massive amounts will probably be tougher this year. Getting yourself to win at the last few seconds and swing it just enough I think will be more popular strategy. You may even see inactivity periods in the middle where you hoard your set waiting to dump/rapidly fire them in the last set of seconds.

Starstruck’s method of winning is being one point better than the opponent with a smaller set of scoring objects that are always in play.

Nothing But Net has a large number of scoring objects and the goal was to remove them from contention by scoring them. So once scored, it stays scored. That is different from Starstruck scoring.

So wins this year may be more indicative than points, but combination of robots in a match is again very important. Scouting to see specific abilities will probably be more important (hanging, shooting a cube to the far end, auton score, massive dump ability, wall bot, etc). These do not show themselves as easily in the score sheet. Last year if you had two slip gear punchers scoring the same set of match loads, you were not as good as a complimentary set of robots that could clear the field and then do the match loads.

DPR may be more interesting to look at. I am not sure though. There are not any mid-match scoring data points like quarters in a football game or innings in a baseball game (sorry international folks for the blatantly US reference - maybe how batsmen perform in cricket when in limited overs? scores at points in time in rugby matches?). You can see in points of the game where the score tide changes. Is it a constant rate or is it a tidal wave that you can’t come back from. Hanging at the end is a jump in points.

Boy, I wish there was a site where I could download massive data sets of matches to evaluate them. :confused:

The best way to compare would probably be to compare OPR Rank within an event (maybe proportional rank / percentage of teams at event worse than them).

But OPR is already a terrible way to compare robots between different events; it’s even worse for comparing between different GAMES, with different scoring methods and point floors / ceilings. Don’t let numbers fool you into thinking they tell you any more than they actually do.

Percentiles or Z-Scores
Percentiles: one of the values of a variable that divides the distribution of the variable into 100 groups having equal frequencies.
Z-Score: a measure that quantifies the distance a data point is from the mean of a data set.

The percentile or z-score can be calculated for each season’s OPR rank and can be compared.

This exactly.

OPR, DPR and CCWM values aren’t technically comparable across events because it’s all relative to other teams, so unless there’s a control across them all then no comparison can technically be made. This is also the case across divisions (e.g. comparing divisions at worlds, etc.)

Trying to then take these values and map them between seasons introduces a whole lot more error, to the point where I don’t know what use any of the values you calculate would have?