Take all the changes and average it?Mithost wrote:
The problem with having a high max number for BPM is that while other elements like approach rate and overall difficulty often reach the higher parts of it's spectrum, BPM will only reach 2/3rds of the way for some of the hardest ranked songs in the game (without mods). BPM should go to 220 or 250, and any BPM that goes over that through mods or whatever get stars.
Next thing for bpm... What do we do about BPM changes?
forum
Adopting a "Star Perceptual Map"
posted
Total Posts
108
Topic Starter
That could work.RBRat3 wrote:
Take all the changes and average it?Mithost wrote:
The problem with having a high max number for BPM is that while other elements like approach rate and overall difficulty often reach the higher parts of it's spectrum, BPM will only reach 2/3rds of the way for some of the hardest ranked songs in the game (without mods). BPM should go to 220 or 250, and any BPM that goes over that through mods or whatever get stars.
Next thing for bpm... What do we do about BPM changes?
Should other elements that hit their max (AR 10 for example) get an above max notification? I think BPM being the only one to have it would be kinda weird.
Topic Starter
Well the thing about averaging it is that it doesn't account for length...
like 300bpm changes to 80bpm but the 80bpm section only lasts 30 seconds which makes the average (190) useless and inaccurate without factoring its length of use.
I suck at math but there is a way to factor it
like 300bpm changes to 80bpm but the 80bpm section only lasts 30 seconds which makes the average (190) useless and inaccurate without factoring its length of use.
I suck at math but there is a way to factor it
that wouldn't really work if you look at songs like ICARUS which get up to 251bpm for less than one second and are otherwise around 140bpm. Same thing for songs like New Castle Legions by Dirty Androids, whose bpm goes up throughout the whole song (starts at 120, finishes at 180bpm with 150 and 170 sections in the middle)
Plus imo bpm isn't always a good indicator of a map's difficulty. If you take Skrillex - Bangarang, LC's diff, it's 128bpm and yet not for the faint of heart. And that's an Insane. It makes even less sense on easier difficulties.
Plus imo bpm isn't always a good indicator of a map's difficulty. If you take Skrillex - Bangarang, LC's diff, it's 128bpm and yet not for the faint of heart. And that's an Insane. It makes even less sense on easier difficulties.
I tried to make an equation to do it but honestly for now if you make a minimum length requirement (in bars) for timing sections with BPM changes, you can weed out the small BPM jumps and get an average from that.
Also, BPM isn't the only factor going into the diamond/pentagon.
Also, BPM isn't the only factor going into the diamond/pentagon.
Honestly we should just stick to the 4 facotrs from difficulty settings. BPM is already displayed anyways, and BPM difficulty is pretty opinionated.
For instance 220 BPM in taiko is nothing for me.
For instance 220 BPM in taiko is nothing for me.
Agreed, some people find some BPMs harder than anothers. For example, I find playing 220~240 BPM streamy maps easier than 165 BPM@accuracy, while it is usually the opposite since lots of players can't stream that fast, but are better at lower BPMs.
I still think we should add "Jumps" and "Streams" as additional factors by using Tom's calculator.
BPM shouldn't be used... it's a set parameter of the map like OD, DR, CS, and AR. It has a specific value and it's already displayed in a clear way for people that want to know it. What you want is a measure of EBPM (Effective BPM)... because things like significance of BPM changes (ie how important is the range of BPM displayed) and what baseline the map is mapped to (ie 1/2 beats vs 1/4 beats) are the things that are currently hidden, but can be calculated.
As for how to measure EBPM, well, it's essentially the baseline object density of a map. Objects/second is one measure of that. Also interesting are the peak burst rates (ie the streamy bits) and the lengths of bursts (because the occasional triple isn't a stream). Movement rate is the same... a baseline average velocity (the "air speed" of the map... a measure of the size of the beat spacing), the peak burst rates (how extreme jumps are) and the lengths of those bursts (how long the jump sequences are). These are the things I would be focusing on, and recall that Tom was working on, and had a pretty good grasp of what was needed to extract meaningful numbers (which is why I've never felt the need to play with things personally further). They're also the exact things that you want on a star graph... things like set parameters should just be listed. Derived stats from the mapping are the only things that need be on a star map, and Tom seemed to have a good handle on those, so I'd go with his stuff (although I haven't seriously looked at his stuff, just read the post a while back, I remember it to be fairly solid, and people seem to like the numbers he's producing). If peak burst rates and lengths are combined that gives four stats: an EBPM measure, streaminess, average velocity, and jumpiness.
This leaves room for say some sort of measure of chaos... ie the jerkiness of the map, jerk technically being changes in acceleration, but in this case it could probably be derived somehow from the amount and size of changes in adjacent intervals between objects.
Average queue length would be another possible derived stat that could be used. However, that depends on if AR remains not a preference, and it's also going to be correlated to both AR and the measures of object density (both the average and the burstiness), in a way that might be easily enough judged (assuming that the object density is available on the star graph and the AR is listed elsewhere). So it could probably be left out to keep the map simple (it also has the problem of interpretation... both ends are hard in their own way).
That leaves five stats: two for streams, two for jumps, and one to represent rhythm/flow chaos. Which seems a good mix to me for giving a feeling about what the map itself might be like (as opposed to just the parameters it will be played under).
As for how to measure EBPM, well, it's essentially the baseline object density of a map. Objects/second is one measure of that. Also interesting are the peak burst rates (ie the streamy bits) and the lengths of bursts (because the occasional triple isn't a stream). Movement rate is the same... a baseline average velocity (the "air speed" of the map... a measure of the size of the beat spacing), the peak burst rates (how extreme jumps are) and the lengths of those bursts (how long the jump sequences are). These are the things I would be focusing on, and recall that Tom was working on, and had a pretty good grasp of what was needed to extract meaningful numbers (which is why I've never felt the need to play with things personally further). They're also the exact things that you want on a star graph... things like set parameters should just be listed. Derived stats from the mapping are the only things that need be on a star map, and Tom seemed to have a good handle on those, so I'd go with his stuff (although I haven't seriously looked at his stuff, just read the post a while back, I remember it to be fairly solid, and people seem to like the numbers he's producing). If peak burst rates and lengths are combined that gives four stats: an EBPM measure, streaminess, average velocity, and jumpiness.
This leaves room for say some sort of measure of chaos... ie the jerkiness of the map, jerk technically being changes in acceleration, but in this case it could probably be derived somehow from the amount and size of changes in adjacent intervals between objects.
Average queue length would be another possible derived stat that could be used. However, that depends on if AR remains not a preference, and it's also going to be correlated to both AR and the measures of object density (both the average and the burstiness), in a way that might be easily enough judged (assuming that the object density is available on the star graph and the AR is listed elsewhere). So it could probably be left out to keep the map simple (it also has the problem of interpretation... both ends are hard in their own way).
That leaves five stats: two for streams, two for jumps, and one to represent rhythm/flow chaos. Which seems a good mix to me for giving a feeling about what the map itself might be like (as opposed to just the parameters it will be played under).
I thought the polygons were made to measure the intensity (thus the difficulty) of the map. I agree with bwross, but BPM should not be ruled out as it still affects difficulty greatly.
The thing is that BPM doesn't directly affect difficulty at all. What matters is how it's used... a 320BPM map can easily be mapped like it was only 160BPM (or vice-versa). So Just knowing 320 or 160 can be deceptive. That's why the focus should be on the objects in the map, not the music. Which is why you want stats based on the density of objects... which is very much like the BPM (same units), but is actually things the player has to do.
Now, the BPM itself is still useful to know. People like to judge themselves against the BPM level of stream they can do well. But for that you want to know the exact value of BPM, not just an impression of how large it is... and that's something that's currently displayed (and should remain). However, the listing of a song at a BPM you have difficulty streaming at doesn't mean that it has any real streams that you have to go up against (or whether the streams in the map are divided into chunks of a size you can manage, or are put together into a single long death stream where you're going to eventually slide off). To know that, it comes back to the objects and how they're packed in the map. Right now that can be done to an extent by using the number of objects and the length (which can give objects/second)... but deeper analysis of the map and it's bursts could be far more accurate.
Now, the BPM itself is still useful to know. People like to judge themselves against the BPM level of stream they can do well. But for that you want to know the exact value of BPM, not just an impression of how large it is... and that's something that's currently displayed (and should remain). However, the listing of a song at a BPM you have difficulty streaming at doesn't mean that it has any real streams that you have to go up against (or whether the streams in the map are divided into chunks of a size you can manage, or are put together into a single long death stream where you're going to eventually slide off). To know that, it comes back to the objects and how they're packed in the map. Right now that can be done to an extent by using the number of objects and the length (which can give objects/second)... but deeper analysis of the map and it's bursts could be far more accurate.
I don't mind if speed is added in a different form, but it seemed like some people in the thread were saying the speed of the map (notes and all) have no sway on difficulty. I think more people would be able to play the big black if it was 120 BPM xD. Note Density sounds good, but we still need a way of calculating it then.
I wholly support the idea of showing/visualizing more stats per map, but I can't say I like the "diamond" way. Simple - it takes up too much space, and map selection interface already feels cramped enough. I'd be fine with plain old horizontal bars - for OD, DR, CS, and AR, with colors ranging from dark green (easy) to crimson(insane). Pros: intuitive, expandable (stream intensity, spin rate and other things would be REALLY nice to see :3). Cons: plain, still might take up lots of space depending on implementation.
If they were to add this I would like the stats represented to be things that actually reflected the actual difficulty of the map. Things like average distance snap, approach rate, OD, circle size, stream length/ number of streams, and the stream density of a song. A large amount of factors can be lumped together in major categories like Accuracy, Technical, and Endurance ratings. Each map could also be given an intensity rating.
I just don't think just showing all the basic stats is any indication of a beatmap's actual difficulty, and we all know star rating can be poor at determining that. So a solution would be to detect things that do make a beatmap more difficult and represent those things as data values that we can actually ascertain valuable information from. The base stats are only a partial indication of difficulty.
Edit: A future idea would be a dynamic difficulty graph in which it takes your success rate for playing x difficulty at x average BPM, and it would then compare the stats of the difficulty to the proficiency of the player and then determine how difficult that map will be based off the number differences.
That would be very difficult to implement.
I just don't think just showing all the basic stats is any indication of a beatmap's actual difficulty, and we all know star rating can be poor at determining that. So a solution would be to detect things that do make a beatmap more difficult and represent those things as data values that we can actually ascertain valuable information from. The base stats are only a partial indication of difficulty.
Edit: A future idea would be a dynamic difficulty graph in which it takes your success rate for playing x difficulty at x average BPM, and it would then compare the stats of the difficulty to the proficiency of the player and then determine how difficult that map will be based off the number differences.
That would be very difficult to implement.
so then maybe select maybe 4-5 categories. and those categories could be calculated using things that would effect the overall difficulty? like, as you said, average distance snap, approach rate, OD, circle size, stream length/ number of streams, and the stream density of a songTheVileOne wrote:
If they were to add this I would like the stats represented to be things that actually reflected the actual difficulty of the map. Things like average distance snap, approach rate, OD, circle size, stream length/ number of streams, and the stream density of a song. A large amount of factors can be lumped together in major categories like Accuracy, Technical, and Endurance ratings. Each map could also be given an intensity rating.
Topic Starter
The way I wanted it is an addon button that shows a page for it, from a default point you wont even see it on the song select until clicked upon...Timekiller wrote:
I wholly support the idea of showing/visualizing more stats per map, but I can't say I like the "diamond" way. Simple - it takes up too much space, and map selection interface already feels cramped enough. I'd be fine with plain old horizontal bars - for OD, DR, CS, and AR, with colors ranging from dark green (easy) to crimson(insane). Pros: intuitive, expandable (stream intensity, spin rate and other things would be REALLY nice to see :3). Cons: plain, still might take up lots of space depending on implementation.
So I really don't see what space your referring to unless its that tiny 16x16px icon
I'm referring to the large space that the diamond inside a circle takes up, regardless of whether it's shown by default :3 where diamond shows 4 stats, you can place 6-7 bar graphs plus some additional info like pass rate, actual bpm spread per song time and whatever else.RBRat3 wrote:
The way I wanted it is an addon button that shows a page for it, from a default point you wont even see it on the song select until clicked upon...
So I really don't see what space your referring to unless its that tiny 16x16px icon
The "diamond" can show more stats if you want it to... you just add more arms to the star. Don't focus so much on the graphic mockup... the number of stats and what they are are up for discussion.
Topic Starter
Well it is a bar graph at its heart but adding more arms/legs doesn't take up anymore room. Theoretically its limitless but whether or not its discernible is another question XD...Timekiller wrote:
I'm referring to the large space that the diamond inside a circle takes up, regardless of whether it's shown by default :3 where diamond shows 4 stats, you can place 6-7 bar graphs plus some additional info like pass rate, actual bpm spread per song time and whatever else.
The whole point of using one is being able to associate shapes with a maps difficulty attributes and bar graphs cant do this, well they can but its going to take a little more thought to get the association than you would with a shape and bar graphs tend to make you look at each individual bar rather than looking at it as a whole while a perceptual map allows you to do both.
As stated by bwross the mock up is well a mock up... The main issue is coming up with value sets that actually mean something to you and relate accurately to the map.
All that aside a graph is a graph is a graph... I don't see any reason not to slap a button on that page that will display these value sets in any applicable graphing format you wish after all it is just numbers with eyecandy
Well we just need to compile 4-5 different stats that house all the things you would want to know before you go into a map. Cursor speed/jumps should be one, hit density should be another, and approach rate/overall difficulty should be in there too.
I always seem to forget that most things can be made configurableRBRat3 wrote:
All that aside a graph is a graph is a graph... I don't see any reason not to slap a button on that page that will display these value sets in any applicable graphing format you wish after all it is just numbers with eyecandy
If choosing between diamond/bars/something else would be an option, I support. Here, have my precious star 
Topic Starter
As for speed and density what about averaging the amount of notes in 1 second slots or per deci-minute (1/10th of a minute / 6 sec)...?
AKA average notes per second or average notes per deciminute....
This would factor bpm changes although it would be averaged but it greatly influences the outcome being in 1 sec slots this way, If bpm changes shouldn't be averaged then average the notes per second in the bpm time sections keeping them separate....
AKA average notes per second or average notes per deciminute....
This would factor bpm changes although it would be averaged but it greatly influences the outcome being in 1 sec slots this way, If bpm changes shouldn't be averaged then average the notes per second in the bpm time sections keeping them separate....
You've got my support for this. This would make it easier for players of all skill levels (I know I still get taken by surprise by AR9-10 maps) in being able to tell exactly why a map is difficult before playing it without having to look at it through editor beforehand. Have you thought up of a comprehensive list of potential factors to be included in your graph?
I know there is talk already about BPM but I don't see why it should be included if the BPM of the song is already shown on the top-left of the song selection screen. If anything, if your Star Perceptual graph isn't a feasible feature in terms of how to fit it on or make a new tab for it, I can see the text stats of it being posted under where the current BPM and Objects text is displayed.
I would like to see these particular stats listed though overall so support+!
I know there is talk already about BPM but I don't see why it should be included if the BPM of the song is already shown on the top-left of the song selection screen. If anything, if your Star Perceptual graph isn't a feasible feature in terms of how to fit it on or make a new tab for it, I can see the text stats of it being posted under where the current BPM and Objects text is displayed.
I would like to see these particular stats listed though overall so support+!
Yea, awesome idea. Spending my last vote for this.
I spended my one and only vote too...
it is a nice Idea.
why not make this configurable, choose you arms, your shape, or that you want bars...
it is a nice Idea.
why not make this configurable, choose you arms, your shape, or that you want bars...
You forgot something: Some old maps do have Circle Size below 3 and above 7 being set. This is one of Ranked example with Circle Size 0, and this is another Ranked example with Circle Size 8.
I haven't see anyone setting the map with Circle Size above 8 (maximum is 10) though, but it's possible to force-set it.
I haven't see anyone setting the map with Circle Size above 8 (maximum is 10) though, but it's possible to force-set it.
I think this is a great idea, however just out of curiosity, which one of these screen shots will be the final design because if it's going to partially cover up your own score, like the first picture, I'd be better off without it. I think the one under alternate looks best. It's a nice size and it looks like it is almost proportional to the scoreboard underneath and I like the fact that the black BG is as transparent as the scoreboard. This will really make it blend well. So.... In my opinion... Support!!
Topic Starter
None of them are a final design they're just concept... Im sure peppy would do his own take on the look.Kuro wrote:
I think this is a great idea, however just out of curiosity, which one of these screen shots will be the final design because if it's going to partially cover up your own score, like the first picture, I'd be better off without it. I think the one under alternate looks best. It's a nice size and it looks like it is almost proportional to the scoreboard underneath and I like the fact that the black BG is as transparent as the scoreboard. This will really make it blend well. So.... In my opinion... Support!!
Topic Starter
Because you failed to read high points, This can do both at the same time and it only takes the space of a 16px square.theowest wrote:
why is this even popular. it hardly displays all the necessary information you need.
I want my difficulty rating to be displayed as numbers, not visually like this. This takes up a lot of space.
t/92485
That is how we should display difficulty.
Support. It should scale with for example HR and DT so when you add those mods the graph changes. No need for the difficulty changes the mod makes to be seen the entire time. If you add DT the graph for AR and Over all diff should just go up by it's respective values. It should also have numbers on it.
The hardest approved maps could have an average og 15-20 in over all diff value, while normal insanes could be 10-15 etc.
The hardest approved maps could have an average og 15-20 in over all diff value, while normal insanes could be 10-15 etc.
hmm
maybe up here
maybe up here
too small up there I Like the scoreboard option, coz I dont need it anyway...
it should be small.My1 wrote:
too small up there I Like the scoreboard option, coz I dont need it anyway...
Instead of the Difficulty Setting, why not use something like
Drain ( 0 - 10 ) - HP Drain Rate
Precision ( 0 - 10 ) Mix of OD and CS (since higher CS means higher aiming precision and higher OD means higher clicking Precision)
Stream ( 0 - 10 ) - How Fast and Long are the Streams? How many are present?
Jumps ( 0 - 10 ) - How Long are the Jumps? How many Jumps?
Speed ( 0 -10 ) - Depending on Average Notes Distance and Approach Rate
could be a way to upgrade the Difficulty rating system too.
Drain ( 0 - 10 ) - HP Drain Rate
Precision ( 0 - 10 ) Mix of OD and CS (since higher CS means higher aiming precision and higher OD means higher clicking Precision)
Stream ( 0 - 10 ) - How Fast and Long are the Streams? How many are present?
Jumps ( 0 - 10 ) - How Long are the Jumps? How many Jumps?
Speed ( 0 -10 ) - Depending on Average Notes Distance and Approach Rate
could be a way to upgrade the Difficulty rating system too.