forum

My Own Mania Rating System Ver 1.1 [Sep 19, 2016]

posted
Total Posts
21
Topic Starter
CloudHolic
In O!M, some(or many?) patterns are not matched with its star-rating difficulty.

It's quite annoying, escpecially if it's harder than difficulty.

So, I made my own rating system for mania.

Glossary
1. Density
The number of notes in each 1s sections.

2. Jack
3 or more notes which is in same line with gap <= 107ms. (Same with 16 beat in 140 bpm)
But if there're no notes except jack, the gap of each note should be <= 94ms. (Same with 16 beat in 160 bpm)


Download
You need .NET Framework 4.0+ to run it. (Same with the requirement of Osu!)
https://drive.google.com/open?id=0B--_s ... DRWbzJMcVU


How to use it?
You should write the osu! file path, or click 'Open' button to find it.

Let's take some examples.

TeamGrimoire+amaneko - croiX (Star rating: 5.51)


typeMARS - Triumph & Regret (Star rating: 5.45)

The first 3 line shows the basic information of this file: Title, Artist, Mapper, Difficulty, BPM, HP, OD, and Keys(Lines).
The next line shows its density, and Jack ratio.
- Average density is calculated except the least 25% of the song.
- Jack ratio means the ratio of jack notes to total notes.
And the last line shows the rating. In my program, croiX is 5.78, while Triumph & Regret is 4.6.

I think it's quite fair... How about you?


Notes
1. It works only for Mania beatmap. No STD Converts are allowed.
2. It works only 4~8k. I can't separate lines in 9k maps. Sorry. Fixed. Now it can accept any keymodes.
3. If the output is 'Unknown x-coordinate detected.' or so, just PM me with the link of osu! file.
It's beacuse osu stores each notes as a coordinate, even though it's a mania-only map! I don't know why.
So there may be a new coordinate that I didn't find.
Also fixed.


For the guys who wonder its exact algorithm, here's source code.
https://github.com/CloudHolic/CloudRating


UPDATE!
1. Changed the download links, and images.
2. Change some algorithms. I bet there'll be no negative ratings.
3. Now it supports '+1' Key style. If the special style option is ON in 6 or 8k, the allowed gap of a jack would be 84ms (Same with 16 beat in 180 bpm)
If the first line's notes are less than 6% of the total notes in 8k, then discard the first line and treat this map as 7k. Of course, it checks the jacks of the first line in any case.

Mr.T - Attack in The Minor Key (Star rating: 4.65, but it's quite hard)


xi - Akasha (Star rating: 6.23)


Special thanks to
frolica for helping, and checking the whole algorithm.
Full Tablet for showing the exact method to convert the coordinate to line.
Full Tablet
For determining the mania column based on it's x-coordinate (0 is first column, 1 is the 2nd, etc...):

Min( keycount - 1, Floor( x * keycount / 512 ) )
So, for example, 4K, the ranges are:
[0, 128[ = 1st column.
[128, 256[ = 2nd column.
[256, 384[ = 3rd column.
[384, 512] = 4rd column.
dewero
The fact that your CustomExceptions folder looks almost exactly the same as mine threw me for a huge loop: https://github.com/NotMichaelChen/ctb_calc/blob/master/CustomExceptions/InvalidBeatmapException.cs

I'll take an actual look at this later though
Topic Starter
CloudHolic

Full Tablet wrote:

For determining the mania column based on it's x-coordinate (0 is first column, 1 is the 2nd, etc...):

Min( keycount - 1, Floor( x * keycount / 512 ) )
So, for example, 4K, the ranges are:
[0, 128[ = 1st column.
[128, 256[ = 2nd column.
[256, 384[ = 3rd column.
[384, 512] = 4rd column.
Oh, thanks! There exists an exact convert equation!

...and UPDATED!
Full Tablet

CloudHolic wrote:

Full Tablet wrote:

For determining the mania column based on it's x-coordinate (0 is first column, 1 is the 2nd, etc...):

Min( keycount - 1, Floor( x * keycount / 512 ) )
So, for example, 4K, the ranges are:
[0, 128[ = 1st column.
[128, 256[ = 2nd column.
[256, 384[ = 3rd column.
[384, 512] = 4rd column.
Oh, thanks! There exists an exact convert equation!

...and UPDATED!
Take into account that in 6K and 8K maps, players can choose whether the 1st column is on the left or in the right in their key binding settings.
Also, the 1st column can be assigned 2 keys to be played, so maybe you should weight jacks less on that column. Something similar also happens with the center column in 7K (where people can learn to alternate the Space key to jack faster on that column).
Both are playing the same 6K map

Normal Style (Left Special Style has the same layout)


Right Special Style
abraker
Ayaya
snoverpk_old
looking at density is not a very good way to accurate difficulty

i mean come on croix is 5.8 on your calculator
Jinjin
Guys keep in mind that this is just a really rough draft, I've checked through some maps myself and yes I think it can be improved a lot further.
Problem with trying to make an accurate star rating system is that you have to take into account so many factors (stamina, LN, jacks, specific pattern difficulty, SV changes (which is a bit arbitrary), etc.).

Trying to quantify a difficulty of a map as a number is a flawed system in general, and that's why star rating has always been a problem.

However, hopefully we'll see this improve over time and give a more accurate representation of mania map difficulty.
Yuudachi-kun
Japanese transformation shift 1* harder than Shadow1800's OP ok
dewero

Jinjin wrote:

Guys keep in mind that this is just a really rough draft, I've checked through some maps myself and yes I think it can be improved a lot further.
Problem with trying to make an accurate star rating system is that you have to take into account so many factors (stamina, LN, jacks, specific pattern difficulty, SV changes (which is a bit arbitrary), etc.).
For some reason people enjoy heavily criticizing new difficulty calculators. Same thing happened with my taiko calculator.
Ayaya

dewero wrote:

Jinjin wrote:

Guys keep in mind that this is just a really rough draft, I've checked through some maps myself and yes I think it can be improved a lot further.
Problem with trying to make an accurate star rating system is that you have to take into account so many factors (stamina, LN, jacks, specific pattern difficulty, SV changes (which is a bit arbitrary), etc.).
For some reason people enjoy heavily criticizing new difficulty calculators. Same thing happened with my taiko calculator.
Or we are trying to point out certain maps that are getting rated wrong so that maybe he can fix them, you need to take criticism to become successful.
dewero

Ayaya wrote:

Or we are trying to point out certain maps that are getting rated wrong so that maybe he can fix them, you need to take criticism to become successful.
Oh I wasn't trying to say that pointing out maps that break the calculator is a bad thing, but they tend not to come with justifications/reasons why the maps shouldn't be rated a certain way. It helps a lot when trying to determine how to fix the calculator
abraker

dewero wrote:

Jinjin wrote:

Guys keep in mind that this is just a really rough draft, I've checked through some maps myself and yes I think it can be improved a lot further.
Problem with trying to make an accurate star rating system is that you have to take into account so many factors (stamina, LN, jacks, specific pattern difficulty, SV changes (which is a bit arbitrary), etc.).
For some reason people enjoy heavily criticizing new difficulty calculators. Same thing happened with my taiko calculator.
Naturally, I will expect the same thing when I come up with my own difficulty calculation, and same happened with osu!skills. It has been proved to be so hard to make a difficulty calculator, that it would be unbelievable if someone made one with barely any flaws. Perhaps I over reacted with my statements, sorry and don't get discouraged, CloudHolic. You are doing your best, and now I wait for Ver. 2.0.
Topic Starter
CloudHolic
Sorry for late replying, guys.

Since this Wed. ~ Sun.(yesterday) was an official national holiday, I was at my parents' home. So I can't use my computer during this period.

Anyway, let's take a look at your opinions now.

Full Tablet wrote:

Take into account that in 6K and 8K maps, players can choose whether the 1st column is on the left or in the right in their key binding settings.
Also, the 1st column can be assigned 2 keys to be played, so maybe you should weight jacks less on that column. Something similar also happens with the center column in 7K (where people can learn to alternate the Space key to jack faster on that column).
Both are playing the same 6K map

Normal Style (Left Special Style has the same layout)


Right Special Style
For +1k style, the allowed gaps in jack will be decrease, but I can't find the appropriate value :(
And most of 8k patterns are 7+1k style, while most of 6k patterns are 6k itself, not 5+1k style. So I'll apply a special rule for 8k.
If the first line's frequency is too low, then I'll discard the first line and regard it as a 7k map. Of course, jack ratio will be checked in any case.



snoverpk wrote:

looking at density is not a very good way to accurate difficulty

i mean come on croix is 5.8 on your calculator
I think density is the only basic standard in Mania, althought there're lots of traps.
Or any other idea to be based on?
abraker

CloudHolic wrote:

I think density is the only basic standard in Mania, althought there're lots of traps.
Or any other idea to be based on?
Start out by taking the extremes. Finding a not so dense hard map and finding a dense easy map would be your best bet. Take a look at 3* inverted maps and 4* high bpm dumpstreams maps, those tend to be underweighted by jack based calculation systems for the most part. Broken stream maps are hard to read and are hard despite not having as high of a density as an equivalent jack map, which tend to be overweighed by jack based calculation systems.

I am still figuring this out myself, but if you figure out how to measure the chaos of the patterns, then you will be much closer to a solution.
Topic Starter
CloudHolic

Ayaya wrote:


My rating system is based on density, but not only the maximum density of the pattern.
Except the corrections, the rating value is started from the maximum density, but it's deducted by the difference of the maximum density and the average density.
So, Daikyi's map is, and has to be underrated, since it's average density is lower than other 5* maps.
But if you still think it's too underrated, I can change the coefficients.


abraker wrote:





abraker wrote:

CloudHolic wrote:

I think density is the only basic standard in Mania, althought there're lots of traps.
Or any other idea to be based on?
Start out by taking the extremes. Finding a not so dense hard map and finding a dense easy map would be your best bet. Take a look at 3* inverted maps and 4* high bpm dumpstreams maps, those tend to be underweighted by jack based calculation systems for the most part. Broken stream maps are hard to read and are hard despite not having as high of a density as an equivalent jack map, which tend to be overweighed by jack based calculation systems.

I am still figuring this out myself, but if you figure out how to measure the chaos of the patterns, then you will be much closer to a solution.
For the negative rating value, I think the 'deduct function' I mentioned above returns > 10.
It happens because the average density is too low from its max density. Well, idk it can be possible. T_T
Maybe I should change this correction...

Also keep in mind this rating system is not only for 4k maps.
I wonder that reading and finding these patterns in all keys can be finished in polynomial time. :(
abraker

CloudHolic wrote:

So, Daikyi's map is, and has to be underrated, since it's average density is lower than other 5* maps.
But if you still think it's too underrated, I can change the coefficients.
Density is not the only thing that can make a map hard.

Here is a map your algorithm thinks is a 4.25*, but should be around 5*.

Low density example but very hard to read (at least to me): https://osu.ppy.sh/ss/6129661
This is easier, but column 1 and 2 are still somewhat a hard hit without good finger independence: https://osu.ppy.sh/ss/6129675
Topic Starter
CloudHolic

abraker wrote:

CloudHolic wrote:

So, Daikyi's map is, and has to be underrated, since it's average density is lower than other 5* maps.
But if you still think it's too underrated, I can change the coefficients.
Density is not the only thing that can make a map hard.

Here is a map your algorithm thinks is a 4.25*, but should be around 5*.

Low density example but very hard to read (at least to me): https://osu.ppy.sh/ss/6129661
This is easier, but column 1 and 2 are still somewhat a hard hit without good finger independence: https://osu.ppy.sh/ss/6129675
I know that density is not the only one to calculate the difficulty, but I mean the 'standard' of rating system.
For LN, my rating system already has some corrections, since it's natural that an LN can't be treated as a simple note.
Other corrections that it already does: Jack, spam, key
Kempie

CloudHolic wrote:

2. Jack
3 or more notes which is in same line with gap <= 107ms. (Same with 16 beat in 140 bpm)
But if there're no notes except jack, the gap of each note should be <= 94ms. (Same with 16 beat in 160 bpm)
Consider using fuzzy logic, so you apply fuzzy rules like "many fast consecutive notes are really hard" to objective measurements, and get an objective rating in return that scales exactly how you'd expect it to scale. Even better: genetic fuzzy systems. Write a ton of fuzzy rules, scrape player scores, then run a genetic algorithm to find more optimal values for your FLV's. Further improve your rating system by adding/changing rules, more player scores from even more songs, more evolving with the genetic algorithm.

See https://en.wikipedia.org/wiki/Genetic_fuzzy_systems

There's libraries that do the tricky parts like defuzzification for you. Not sure about general purpose implementations of a genetic algorithm, but I wouldn't be surprised.
Topic Starter
CloudHolic

Kempie wrote:

CloudHolic wrote:

2. Jack
3 or more notes which is in same line with gap <= 107ms. (Same with 16 beat in 140 bpm)
But if there're no notes except jack, the gap of each note should be <= 94ms. (Same with 16 beat in 160 bpm)
Consider using fuzzy logic, so you apply fuzzy rules like "many fast consecutive notes are really hard" to objective measurements, and get an objective rating in return that scales exactly how you'd expect it to scale. Even better: genetic fuzzy systems. Write a ton of fuzzy rules, scrape player scores, then run a genetic algorithm to find more optimal values for your FLV's. Further improve your rating system by adding/changing rules, more player scores from even more songs, more evolving with the genetic algorithm.

See https://en.wikipedia.org/wiki/Genetic_fuzzy_systems

There's libraries that do the tricky parts like defuzzification for you. Not sure about general purpose implementations of a genetic algorithm, but I wouldn't be surprised.
I didn't think about it, but it's quite a good idea.
Unfortunately, I don't know about it well. So it takes a time to learn the fuzzy theory.
Please sign in to reply.

New reply