-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cap maximum spinner RPM based on OD #24932
Conversation
68561e0
to
859155d
Compare
Doesn't seem to be working 🤔 osu.2023-09-26.at.08.45.08.mp4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As commented. Maybe we need some kind of test coverage?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a good start.
I've tested this in gameplay and think the range here is a good starting point to get more feedback from the community. |
@bdach added you in here just to get your take on this and make sure I haven't missed anything major. In terms of balance, the numbers are intentionally chosen to be something we can deploy and get more feedback on, so don't feel like you need to provide any insight there, beyond maybe playing yourself and seeing if it feels roughly in line with expectations. |
SpinsRequired = (int)(minRps * secondsDuration); | ||
MaximumBonusSpins = Math.Max(0, (int)(maxRps * secondsDuration) - SpinsRequired - bonus_spins_gap); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About the only thing that I would want to highlight here code-wise is that due to the way this is calculated, i.e. due to int
truncations being here, the RPM requirements given in the OP are actually upper bounds rather than lower. As in, it's not "you need to spin at least this fast to complete", it's more of a "if you spin this fast, you are guaranteed to clear, but you can get away with spinning slower if you get lucky with rounding".
From the test cases added in this PR:
OD 0:
> (3000ms / 4) to 1/min
(3000 * millisecond) / 4 = 80 min^-1
> (3000ms / (4 + 2 + 6)) to 1/min
(3000 * millisecond) / (4 + 2 + 6) = 240 min^-1
OD 5:
> (3000ms / 7) to 1/min
(3000 * millisecond) / 7 = 140 min^-1
> (3000ms / (7 + 2 + 10)) to 1/min
(3000 * millisecond) / (7 + 2 + 10) = 380 min^-1
OD 10:
> (3000ms / 11) to 1/min
(3000 * millisecond) / 11 = 220 min^-1
> (3000ms / (11 + 2 + 8)) to 1/min
(3000 * millisecond) / (11 + 2 + 8) = 420 min^-1
All values are ever so slightly lower or equal to than the limits given in OP, due to the rounding.
I'm not saying this is actionable, just that I had a different impression of what this was gonna be from the OP - this is still probably okay, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could make the spins requirement a floating point. That will definitely work well when backporting to stable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jokes aside, I don't think this could easily be resolved, apart from using half spins and getting a bit more precision? Maybe a good pro for switching to half spin judgements.
A conversation for another day, nonetheless.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That, or you'd round / ceiling the bonus spin requirement rather than floor. But neither solution gets rid of the issue definitively, final effect will still depend on spinner duration and resulting rounding behaviour anyways.
Which is why I said this probably isn't actionable. Just highlighting for the sake of it I guess.
Balance-wise I will not attempt to say much except that (a) this appears to do what it says when tested on a set of test spinner maps I made a while back and (b) I can get up to half to 3/4rds of bonus spins even on OD10 despite being an absolute trashcan at the game, so I don't think anybody should complain about the limits being too high. (Too low, maybe.) |
Addresses / closes #23732
Glossary
Preamble
The RPM required to clear spinners (i.e. minimum RPM) is unchanged from stable and the previous implementation:
With this PR, the RPM required to complete spinners becomes:
https://www.desmos.com/calculator/pblnx0jyve (
A
represents RPM-to-clear,B
represents RPM-to-complete)I intend to get this out for testing, but these are not necessarily the final values as discussion is still ongoing (#23732). The values that do end up are intended to be backported to osu!stable sometime in the future™.
There are also areas not addressed - peppy & I like the idea of capping the spinning RPM to enforce consistency, and this will be required for lazer's implementation. This will be done as a separate change.
Explanation
To come to these values, I've taken a mix of:
I have four skill levels that I categorise spinner gameplay. This is NOT a representation of their overall skill level.
My (rough, biased, not rooted in absolute fact) observations from this are:
Keep in mind, however, that: