Skip to main content

Browse GamesGame JamsUpload GameDeveloper LogsCommunity
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
Shroobz1 day ago

It is both skill and luck,

luck: the timing window to get a +100 is 0.2 pixels in each direction, meaning 0.4 total, notes move at 200 pixels a second. At the game’s fps limit that’s 200/144 ≈ 1.4 pixels per frame

0.4 / 1.4 = 0.288 = 28.8% chance a +100 CAN be hit

9 in a row: 0.288^9 = 1 in 73000


the second part of my comment was about skill, at 8 ms of standard deviation (which is pretty much the human limit, his is probably much higher) the chance of hitting a perfect note is 2 * Φ(1/8) - 1 ≈ 2 * 0.5497 - 1 = 0.0994 = 9.94% (https://www.calculator.net/z-score-calculator.html?c2z=0.125&c2p=&c2pg=&c2p0=&c2pin=&c2pout=&calctype=converter&x=Calculate#converter)
So hitting 9 in a row would be 0.0994^9 = 1 in 1.055 billion (yes, I got this slightly wrong from rounding errors)


To get 9 100’s in a row, you would need to get 9 perfectly positioned notes (1 in 73000), and then hit those 9 perfectly positioned notes at the perfect time (1 in a billion at the human limit), combining to around 1 in 73 trillion.

If you were to hit 1000 notes a second for 24 hours a day with the human limit of precision, it would take you 2300 years to get 9 100’s in a row


FAQ:

Yes, this is just an explanation of my previous comment.

Yes, I decompiled the game to get the scoring logic

Yes, I saw the message in the code

Yes, I am writing all this because I’m bored

Yes, I am also writing all this because I don’t believe opgrhythm


tl;dr: at the human limit, you would need to hit a 1 in 73 trillion chance to get 9 perfect notes in a row.  Also input delay n hardware stuff that make that chance even lower.

Reply
EzioEagle1 day ago

Hmm, I added the grace period that rounds it to 100 if you get over 99.75, hoping to remove that rng aspect so it would at least always be possible to get 100, but I never actually calculated if it actually was enough to do that. I guess it wasn't, oops! I was actually already planning to completely remove the fps cap in the next update, good to know I was right in doing that lmao. Ideally input would be separate from fps, but I'm not sure there's a good way to do that in godot.
If they're playing at 60fps (vsync, which I'm turning off in the update), and playing on a map where the tempo is 60 or 120 (there's probably a few, off the top of my head I know megalovania definitely is 120 for example), it's possible that could line up and always give you the chance to hit 100 (no idea if this works in practice, just theoretically). Then it's just hitting 60fps frame perfects, which is difficult, but definitely possible, especially in a rhythm game where you've got great timing queues from the music.
But also like, I don't think this is that serious lmao, this isn't a competition where it matters, there's no consequences here lol.

Reply
Shroobz1 day ago

Scoring logic is indeed very inconsistent and fps based (I’m pretty sure hitting above 98 100% of the time isn’t even possible at 60 fps: 200/60 = 3.33 pixels per frame, 75 + (100 - 1.6 * 5) / 4 = 98, meaning there’s a 1.6 * 2 = 3.2 pixel window. (though this might be wrong if int() rounds the value, but I’m pretty sure it truncates)

Also, about the “bpm matches fps” theory, the desync variable should be making that impossible anyway, on my decently powerful laptop desync still jitters by around 3-5 ms every time it’s recalculated, which is more than enough to make a +100 improbable. I don’t have a pc to test this with right now but I doubt it’d jitter much less.

Though, for funsies I will assume that: 

1. there are 9 notes in a row that could hit +100

2. the player is playing 60 fps 

3. The player’s reaction time standard deviation is 16

4. The player’s spatial awareness is so great that they can attempt a hit in the exact middle of the +100 frame (yes, this is an advantage)

the player’s playing at 60 fps, meaning 16.66 ms per frame, they hit in the middle, meaning the range is ±8.33 ms

with SD = 16 ms, we calculate:

Z = 8.33/16 = 0.5208

putting this into the wonderful invention “calculator” we get P(-Z<x<Z) = 0.39752

9 times in a row, 0.39752^9 = 1 in 4000

Meaning if you ignore about half the game, 9 100’s in a row becomes somewhat believable


Though, honestly, I’m just ‘debunking’ this to prove to myself reading obfuscated code and rereading my math homework from last year for 3 hours was a worthwhile investment 😭 (and I am very bored), I highly doubt opgrhythm is actually lying


tl;dr: fix scoring pls

Reply
EzioEagle10 hours ago

Ah yeah it does make sense that the desync mitigation system would stop the tempo sync from happening. Next update will remove the that, so it might work there. Although since it's also removing the framerate cap, it won't matter. Although unfortunately vsync cannot be turned off on browsers (not in chrome at least, there is technically a way to force it off using arguments on its shortcut, but that seems to break other stuff, the maps just don't play correctly at all for some reason despite them playing fine at unlocked framerates in the windows version?), so it'll be only for the downloadable build.
I get around 1800-2000fps when playing the downloadable version (with a 5600x and 4070), which equates to a frametime of about half a ms, so enough to fix it for me at least lol.

Reply
AboutFAQBlogContact us
Copyright © 2026 itch corp · Directory · Terms · Privacy · Cookies