This thread is basically on how complexity in osu should be handled, and dealt with as a factor of difficulty in maps. Currently, the map rating system bases most things off of physical factors, with star rating being all about time spacing and distance spacing of notes, and PP being a combination of this, the other stats, and map length. To make the system handle the complexity of maps better, we first must find out what is deemed hard in terms of reading, and mental understanding. As is, I have personally thought about it and decided that the things I deem most responsible for making things mentally hard are angles, variations, and readability. The details on this topic are in the document below.

I would really appreciate any feedback on what people personally find difficult in terms of patterns, speed changes, etc. Things that aren't accounted for in the current system.

Additionally, if you have any ideas on how exactly to handle finding and adjusting for these difficulties, I would like to hear those as well so I can add them to the solutions section.

Finally, if anything in the document or thread is hard to read or could be formatted in a way that would make it more pleasant to look at, I'll work on that as well.

Google Doc

This thread is meant for discussion on the issue of complexity and the aforementioned document, and working to better the PP and difficulty systems that are already in the game. Thanks for taking the time to read.

Just hard to think that the current difficulty rating would need fixing as its almost perfect compared to the shit we had before this.

Also what you said about reading and mental understanding varies really much on people. Like i am much better at this game than my brother overall, but because I cant into square jumps there are few maps in this game that I cant beat his score. We cannot get an objective solution on how hard they are.

There are some obvious mistakes the difficulty calculator makes like rating airman harder than rainbowdash likes girls but what ever.


Anyway if you can make this work good for you. Just my 2cents on the (issue) since you advertised on #osu

Sea_Food wrote:

Just hard to think that the current difficulty rating would need fixing as its almost perfect compared to the shit we had before this.

Also what you said about reading and mental understanding varies really much on people. Like i am much better at this game than my brother overall, but because I cant into square jumps there are few maps in this game that I cant beat his score. We cannot get an objective solution on how hard they are.

There are some obvious mistakes the difficulty calculator makes like rating airman harder than rainbowdash likes girls but what ever.


Anyway if you can make this work good for you. Just my 2cents on the (issue) since you advertised on #osu

Given a map with 0 plays that nobody has even so much as looked at, how do you measure something like reading (hint: this is a rhetorical question)?

Given a map with 0 plays that nobody has even so much as looked at, how do you measure something like reading (hint: this is a rhetorical question)?[/quote]
muh shitposting

How is this a shit post? Have you ever in your life tried to program a scoring/difficulty system? You act like a computer works like the human brain...

Note density. an average of >4 notes on the screen being harder to read than average

The point is that it doesn't. This is why we don't have a system in place like this already, and that's why I made a post about it. I talked about it a bit with Tom94, who does the PP calculations and he says he's pretty much thought about everything I wrote about, as they are really obvious. The reason I made the post is to work with the community on what is GENERALLY hard, and what kinds of things should be implemented to find and represent how hard those things are. If we worried about the subjectivity of it, the game would be pointless, because some people are good at jumps, some are good at streams, both are rewarded, if we were worried about it only accounting for what everyone was good or bad at, then neither of those would be. That's why the point is to look at what types of different things are found difficult in general so that we can build systems to account for them. Nothing like that will be perfect first time around, and that shouldn't be the concern. The concern is building a system that can detect these difficulties and represent them in a statistical way, everything else is tuning.

Currently, the problems as I understand them are
A) Detection, while in theory it's easy, Tom said he didn't want to have detection take 20 parameters, and I figure that applies to the calculations and stuff as well.

and B) Implementation, the code needs to be written for detection and the algorithm for scaling things with this new information also need to be figured out. This means we need to work out what that would look like in a way that is transferrable to code, in as few variables as possible so that we don't have things everywhere. If we figure out how to make it work, then it can be at least looked into, as is, there are no realistic implementations.

This all takes a lot of time and data and again, that's why it's being posted here, not already implemented into the game.
I don't work with the code, or any of the people who are affiliated with Osu!, so I can't say anything concrete on the matter, and I don't have any hard information or code, and that means I can't directly write out anything, and neither can anyone in the community, however, together we can build pseudo-code or dummy functions to handle the issues at hand, or at least give ideas on what will be needed and what to do with it. That's why I provided the angularity example. Tom94 works on the pp code basically alone from what he told me, and that means if we want this sort of thing basically anytime, we need to work on it as a community thing, because with him having a life and keeping up in the game, he doesn't have that kind of time. Thus, it's much more effective to work together as a community to get the groundwork of a system like that, and hand it off to the devs to implement and tune.

If you still think that's a bad idea, that's fine, but this is how things have been handled in other games many times, where the community has brought major features to the game through modding (proof of concept) or direct suggestions.


As for note density: I think it should be worked into other systems like a system to detect streams (for variability) so that streams don't look like a huge note density to the game, because in reality, they're very easy to read.

this is the reason why the RC exists though, to make things not unreadable, etc

star rating and PP is a calculated thing, there's no real way to calculate somebody doing 15 backwards jumps in a row that have no flow whatsoever as hard or easy or anything like that, just because of all of the different variables associated with it

the only real way to do that is to get a massive group of people to manually set star ratings for maps or something

Maeg, you can certainly detect things like that, it's just not simple, and that's kind of the point here.

Detection won't be perfect, but it's a place to start.

The systems in place don't let through unreadable stuff or anything of the sort, but they don't account for difficulty in reading and the likes, which is more the problem. There is no reward for playing something very difficult to read and high stars, so you may as well just play easy maps that are high stars or whatever. Not that that needs to be fixed, but it should at least be shown when a map is more difficult than it looks right off the bat.

The issue with checking angularity is that certain patterns are harder for certain people, so you'll never really be able to come up with an evaluation method that's universally reliable. I think it's less important to account for specific patterns than to figure out what makes the pattern difficult and start from there; the distinction between what a player finds hard and what's intrinsically hard has to be accounted for.

Accounting for variation is all that you need. Start by breaking the map into pairs of objects (first and second, second and third, third and fourth, etc.) and look at the differences within those pairs with regards to position, timing, etc. This is basically what we have now in the sense that it's only going to evaluate jump length and speed; the trick is to take it further. Repeat the process, but start with the set of pairs rather than the initial set of map objects (first/second and second/third, second/third and third/fourth, etc.). Evaluate the differences between one pair and the next. The more substantial the differences the more difficult the pattern is. You can deal with things like angularity if you want to, but even sticking with position and timing will allow you to account for things like distance snapping. Then go down another level and repeat the process again (first/second to second/third and second/third to third/fourth). Slowly but surely you'll move from intrapattern variation to interpattern variation as you go deeper and deeper, detecting things like repeated patterns. By the time your set is down to two elements you'll be dealing with overall map variation from start to finish, and that's where the evaluation can stop.

Naturally this is totally off the cuff, and I'm sure the system can be expanded and refined, but I think that's where things should start.

The issue is that a good implementation that takes these things into account would require a combination of genetic algorithms and pattern recognition applied to an extremely large data set. Even after doing all of that it's hard to say how much these factors would even be taken into consideration since this would be a more holistic approach. Things like jumps, streams, and speed can be trivially measured by examining distance and time measurements. As Tom has already explained, there are too many different ways that a map can be "complex."

An alternative approach would require creating an alphabet based on timing and relative distance in an effort to write a dictionary containing complexity elements as a sequence of symbols from our alphabet. As long as each complexity element can only be represented by a small set (preferably of size 1) of these sequences we can then simplify this to a regular expression problem. Have fun trying to create such an alphabet and dictionary.

Either of these 2 implementations would take an immense amount of work to implement and would take a lot of time to properly test. I'm talking somewhere along the lines of at least a year with no guarantees that it will even work as desired in the end. There is an entire subforum devoted to feature suggestions and a large number of features in there that people really want could be implemented in the same amount of time. There's just no reason as a developer to worry too much about implementing detection for complexity.

@Narrill: This would be the intuitive approach but it has terrible time complexity if I'm understanding what you are suggesting correctly.

chainpullz wrote:

@Narrill: This would be the intuitive approach but it has terrible time complexity if I'm understanding what you are suggesting correctly.

The thing is it only needs to be done once. And it doesn't even need to be that grand and complex, it can be a simple implementation that doesn't account for every single thing like he's suggesting, because even a simple extra system would be better than what we have now, which is nothing.

You could say the same thing about encryption. You only need to factor a really large number once. Given billions of dollars and several years time you can crack a single encryption. It's totally doable. Is it practical? No.

There are 2^(n-1) ways to partition a set of n objects (thinking cutting a string). Thus any complexity check involving this sort of division is at best O(2^n). As soon as we hit 40 objects we are already approaching roughly a day to check for complexity. Even with immense optimization, running this with 1000 objects is still pretty impractical.

Edit: If we ignore globally repeated patterns and only focus on adjacent repeated patterns it is a more feasible time complexity but not as accurate of a measure.

chainpullz wrote:

You could say the same thing about encryption. You only need to factor a really large number once. Given billions of dollars and several years time you can crack a single encryption. It's totally doable. Is it practical? No.

There are 2^(n-1) ways to partition a set of n objects (thinking cutting a string). Thus any complexity check involving this sort of division is at best O(2^n). As soon as we hit 40 objects we are already approaching roughly a day to check for complexity. Even with immense optimization, running this with 1000 objects is still pretty impractical.

And like I said, it doesn't need to be on quite that scale, because we don't need a perfect system that accounts for every single object and variation in existence, only the relevant ones that are close together, and even that is AT MOST. Just a simple system would be better than what we have now.

Assuming we're only checking position and timing, we're looking at roughly a million comparisons for a map with 1000 objects (note that this isn't 1000 combo), and we're talking numerical comparisons. It's certainly expensive, but it's not like we have to do every pass. Suppose we cut the element count in half for each iteration.

1 mil comparisons isn't expensive if the comparisons run in constant time (for some hopefully small constant). It's the actual iteration process that is a concern because there are a lot of ways we can go about partitioning and then a lot of different ways we can go about comparing partitions (if we only check same size adjacent parts we cut down on time significantly but we aren't as thorough). It seems like we probably only care about comparing same size parts so that alone cuts down on time dramatically but even so unless we establish something like only checking adjacent parts it's going to take too long (which would still take a long time but would likely be practical).

I don't think it's terribly necessary to compare non-adjacent parts. And I'm not really sure what you mean by size. The partitions would always have identical object counts.

I'll explain a bit more clearly. We're comparing objects from left to right. The first object is compared to the second, the second to the third, etc., until we reach the next to last and last objects. Then each pair becomes an object and the comparisons are run again in the same way. Non-adjacent objects are never compared, and I don't think they'd need to be.

consider abcdabcefabcdabcef

Your method of only checking adjacent parts will find abcdabcef as a repeated pattern but it won't really pick up on the abc repetitions the way that is desired.

An example of this pattern might be something like triangle center(single) triangle (offset center double) triangle center triangle (offset center double).

Obviously the most important part is the repeated triangle followed by a jump to the center.

The point being that our greedy approach will skip over a lot of patterns we wish to pick up in the first place.

Can you demonstrate that claim in a way that makes me more inclined to believe it?