Skip to content
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

RNG calls from hits should be included in next estimate #66

Open
Amphitryon0 opened this issue Mar 13, 2022 · 0 comments
Open

RNG calls from hits should be included in next estimate #66

Amphitryon0 opened this issue Mar 13, 2022 · 0 comments
Labels
enhancement New feature or request frontend-functionality issues related to non-UI portions of the frontend priority:low low priority issues

Comments

@Amphitryon0
Copy link
Collaborator

Each hit can add up to 50 calls, which can increase the required standard deviation for the first interval considerably. Taking these into account (most simply by asking the user to fill in how many they got) could reduce the standard deviation by up to 30 calls. However, note that that's an optimistic estimate that assumes that no two hits are within 10 frames. In reality, many users who are throwing the first board will score a second hit while the screen is still shaking. In fact, if someone throws in less than 4 seconds, the average hit that is followed immediately by another hit adds less than 25 calls. If we assumed it was still 50, we would end up with a worse estimate than ignoring it altogether!

The best approach in my opinion is to stick with 50 as a base but, when the user is throwing, decrease it based on some criteria. If we know the users follow a certain path (or we require them to follow one), and we know approximately how fast they throw, then we can estimate not only which hits' animations were interrupted but also how early on they were interrupted. This process is not needed for non-thrown boards since successive hits tend to be much further apart when trying to win.

@Amphitryon0 Amphitryon0 added enhancement New feature or request priority:low low priority issues frontend-functionality issues related to non-UI portions of the frontend labels Mar 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request frontend-functionality issues related to non-UI portions of the frontend priority:low low priority issues
Projects
None yet
Development

No branches or pull requests

1 participant