Bottom-paged, so reposting this again.Shoegazer wrote:
Guess I'll post some formulas and some examples here - original post on my thoughts here. Ideas in this post take precedence - since I didn't really work with figures in the post before. The post is there just to give reasoning as to why the scoring system is not really ideal. Extremely long post ahead.
Ciel's post is also another post worth reading, and talks about the general ideas of visual mods and LNs as well.
Link to spreadsheet for reference of what the formulas I'm bringing up, and a more visual view: https://docs.google.com/spreadsheets/d/ ... sp=sharing
Feel free to make a copy of it if you want to fiddle around with it, too.
AccuracySPOILERUse the score v2 (Accuracy) sheet for reference. The formula I'm suggesting is Accuracy^(1 + Accuracy * 4). The 3 columns on the right are meant to be a comparison - the formula on the right is Accuracy^5.
The main reservations I've had is that the exponential magnitude is too steep and that lower accuracy scores might be punished far too severely. The steps to remedy this, is to use a lower exponent, and to gradually lower the exponent as the accuracy gets lower and lower.
So why essentially Accuracy^5, since at very high accuracies the exponent adds up to 5?
This is meant to replicate benchmarks in score v1 (this is also why there is a 1mil score equivalent for reference). This isn't necessarily a 1 to 1 comparison, only 98% scores are about the same - the rest are slightly lower. I've checked around with multiple people and they seem pretty content with the numbers came out for the combo scoring aspect. I don't think there should be that much of a drastic change for things like this for scorev2 - I'd say the only reservation that I had with scorev1 is that there's too little differentiation between a 99% and 100%, but there's too much differentiation with a 98% and 99%. This mitigates that.
So why Accuracy^(1 + Accuracy * 4), then? Or particularly, why the (1 + Accuracy * 4)?
The general idea is that the higher the exponential, the steeper the curve. By lowering the exponential with a lower accuracy, it makes lower accuracy scores noticeably less of a dead-weight. You can technically do something like Accuracy^(Accuracy * 5) for what it's worth, it initially slipped my mind when I did this. The main problem with this however, is that the differentiation in exponent between accuracy might be too insignificant. I'm not sure how you can mitigate this, but there's most likely a way to do it. However, this isn't top priority, this is more of a plus, more than anything else.
The reason why I initially suggested (6 - Accuracy) at first was because I'm retarded and I didn't know how exponentials work at first, so please ignore what I said in that area.
So what are the drawbacks of this?
The main drawback that I can think of is that I'm using scorev1 figures to calculate accuracy. While this doesn't seem like that bad of an idea on paper, I'm not sure how the new LN mechanics will affect accuracy, especially for LN-heavy charts. This is something that needs experimenting, but I think the easy solution for this would be to ask feedback from the general community as to how much lenience does a LN release have. Many people have said that it's considerably harder to release LNs, which makes sense, but considering that it goes hand in hand with accuracy - it's very much something that needs to be under scrutiny. If you want players to be more stringent with their LN releases, you can lighten up the exponential a tiny bit. If you want the accuracy exponent to stay as it is, make LN releases more lenient.
Minor drawbacks include the fact that there's also the fact that the situational exponent might be too insignificant (which is mentioned earlier), and that I only looked at accuracies all the way down to 93.20%, which is generally about what the worst players in tournament semi-finals/finals would be getting on average in the first place. I assume that it wouldn't be very harsh with accuracy lower anyway, but you can always modify the situational exponent if that's not the case. The base exponential (which is 5 at 100%) is most likely fine.
ComboSPOILERUse the score v2 (Combo) sheet for reference. The formula I'm suggesting is HitValue * min(logx(combo), logx(combo cap)). The 3 columns on the left are meant to be a comparison - the formula on the right is HitValue * logx (combo).
This is a lot longer to explain (and probably a lot more complicated), but I'll try to explain it to the best of my ability. The reason why a non-FC hurts so much is because of the fact that the combo score as combo is higher is quadratic (thanks Ciel for the clarification). The most intuitive way of solving this would be to use a logarithmic scaling down for combo. I know there's probably going to create a decent amount of difficulties programming-wise (particularly trying to find the perfect score so you can scale scores down appropriately), as the combo mechanic is designed to produce exact figures - but do read on.
Interestingly enough, it doesn't matter what logarithm you use to scale down the combo, the end result will be the same. I plugged in a log of 4, 10, 500 and decimals, they all work - except for the ones that don't work normally (e.g. 1, 0, negative numbers). I don't really recall the reason for this exactly, though. If someone knows, let me know because I'm actually pretty curious about this and I'm kinda overwhelmed by all of this information to really find out by myself.
The scenario I've tried to emulate is a hypothetical situation when there are 2000 notes in a chart. I made 3 scenarios: wa person with 1,000 max combo (1 miss), 500 max combo (3 misses), 250 max combo (7 misses). These are hypothetical situations that emulate the most extreme cases in terms of miss location. Under these scenarios, given that you've hit full 300gs aside from misses, you would lose 10.47%, 20.91% and 31.30% of your potential combo score - about 21K, 42K and 62K respectively. Given, this is not entirely correct, since my calculations assume that the combos are exactly the same, but this is incorrect in reality since the miss also counts as a note and as a result it reduces the combo by 1. (e.g. 1000-999, rather than 1000-1000) This is however, insignificant, considering that the difference is >0.06%.
There's a couple of problems with this, the main problem being the magnitude of penalty. The fact that a person could lose (up to) 20K over a single miss is most likely overkill, considering that 20K can potentially be a game breaker, and almost certainly will be a game breaker if you're in very early stages. It still encourages a no room for error attitude, which just hasn't been adopted in osu!mania just yet.
Since you can't change the logarithm for this, you have to implement something else - a combo cap (which is done through something like min(logx(combo), logx(combo cap))). This means that at a certain point, the log(combo) component cannot go any higher, as log(combo cap) will be lower than log(combo), and the lower value will be taken. I used a combo cap of 400, which reduces the maximum losses to 3.42%, 10.26%, 21.70% (the format is 1 miss, 3 misses and 7 misses). Very noticeable drop for the 1 miss, and is arguably about right. Multiple misses are penalised quite appropriately as well, though it might arguably be too lenient, as this only highlights the extreme cases. You can increase the maximum penalty by increasing the combo cap - for example a combo cap of 500 increases the penalties to 4.16%, 12.47%, 23.97%. This is something that requires experimenting, and is probably one of the more important parts of the scoring formula to tinker around with.
You can also use a relative combo cap (and is probably better), rather than an absolute - I used 20% in my case, but 25% is probably fine as well. The relative combo cap can be truncated or rounded up, but the difference will be borderline negligible.
What are the drawbacks?
The figures used to show total losses are based on extreme cases - as a result, my suggestion for the combo cap might be a bit off. I don't know how the combo cap of 400 will be executed in practicality, but I don't expect the variance in performance to be that significant. Regardless of this, even if the variance does make the results look a bit unfavourable intersubjectively, this can be changed. This is something that requires community inquiry, more than anything else (perhaps it would be better to show combo score as if it's a 1mil equivalent?). You have to experiment around to see how the combo cap should be, but that's about it.
Location of misses still matter a decent amount, probably far more than what the community wants. This doesn't negate the problem entirely, but it does to some extent. Basically, the lower the combo cap, the less the location of misses matter, unless you're missing a lot in a concentrated area.
Another problem might be the fact that 300gs might not be weighted very heavily, since only the combo component of scorev2 looks at 300gs. The only two solutions that come to mind would to either increase the proportion of combo to emphasise more on 300gs, or to embed 300gs into accuracy (since as they are, they are weighted the same as normal 300s). The latter requires a lot more tinkering and probably creates more of a community uproar, so I think the former would be a better approach. Again, another thing that requires community response.
Lastly, there's the rounding problem, which I'm not sure how to do because I don't do programming aside from Python wankery. I assume that an extremely small logarithm should solve the problem - since it would eliminate the problem of rounding.
That should be all. Again, I'm not going to talk about visual mods and LNs, since Ciel (and many others) are more well-versed in those than I am. Hope this is a more tangible way of reshaping the scorev2 system - because I think it has massive potential to be a good scoring system that players widely agree on. If there's any questions/clarifications on what I mean or what each part of the spreadsheet does, I can respond to them.
For anyone who scrolled all the way down to read this, the main takeaways are that LN releases might be a touch too strict so it would be good for players to experiment and find out whether or not it's too stringent and to focus more on the formulas rather than blaming it on the name of the component (e.g. combo) and give constructive feedback as to how the scorev2 system can be improved.
@Bubbler
Thanks for the information! The latter snippet makes a good amount of sense to me.Bubbler wrote:
Accuracy ^ (0.5 + 4.5 * Accuracy)
This happens when the minimum power falls below 0.596 = 5 / (e^2+1).
Maybe not too much of concern since playing any map with 20% accuracy will most likely result in a failThis is because log(a)x = log(a)b * log(b)x, in other words, picking a different base is equivalent to scaling all values by a constant. And when the maximum total value must be scaled into some constant (in this case, 200k), constant scaling obviously has no effect.Shoegazer wrote:
Interestingly enough, it doesn't matter what logarithm you use to scale down the combo, the end result will be the same. I plugged in a log of 4, 10, 500 and decimals, they all work - except for the ones that don't work normally (e.g. 1, 0, negative numbers). I don't really recall the reason for this exactly, though. If someone knows, let me know because I'm actually pretty curious about this and I'm kinda overwhelmed by all of this information to really find out by myself.