SPOILERUse 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.
SPOILERUse 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.