petersn / web-sploosh-kaboom Goto Github PK

Naturally, we have very little data for intervals with rewards (since speedrunners don't play past that point), so we need a wider margin until there's more data. However, even ignoring that, these intervals also have much more time spent not in a game, which is variable not only in length but also in call rate.

this will allow more accurate estimation of offsets between games, allowing for a smaller error margin. Also obviate the need for manual entry of the offset

Something like "skip split" or "invalidate split", "invalidate timer" etc to make its function clearer

When the timed board standard deviation is sufficiently low, the RNG calls from actually generating the next board can make a significant difference. The required 9 calls can, of course, be taken into account with the intercepts, but any additional calls resulting from clashes should be added to the estimate for the next board. This should allow users to have significantly lower standard deviations.

The obvious problem with this approach is figuring out how many calls a particular board took to generate. It may seem like, in addition to the generated boards that we currently send, we would need to send a count for each index. However, it is actually possible to derive this information from only the list of boards.

Current board generation algorithm can be made more efficient and/or transferred to the Rust code

video link of shot order

(assume the bottom-left square is [1,1] while the top right square is [8,8])
Replicated shot order, Turbo Blurbo Mode: On

[4,5] miss
[5,4] miss
[6,3] hit
[5,3] miss
[6,4] hit
[6,5] kill

According to the screenshot above, the next suggested shot is [7,5] at 14.16%.

In non-Turbo Blurbo Mode, the exact same inputs yield different percentages. The square [7,5] is now 13.49%. I'm guessing that Turbo Blurbo Mode has an unspoken feature which highlights locations that are closer-by, rather than going for precision. However this should not affect the hit statistics of the squares. Both Turbo Blurbo Mode and Regular Mode should report the same statistics for all squares, assuming the same sequence of inputs.

After using practice mode for a while, the app crashed, which turned out to be very consistent in both Calculator Mode and Practice Mode, but not in Turbo Blurbo Mode. It appears to be caused by a memory leak. Each computation gradually increases the memory usage as seen in Task Manager. The error printed to the console about the crash is "Uncaught (in promise) RuntimeError: unreachable executed" at sploosh_wasm_bg.wasm:26231:1.

The visual effects of this bug differ between browsers. In Firefox, the board probabilities freeze at their current state, even after you hit reset. In Chrome, the probabilities will be crazy numbers for a short while, then all 100%.

I can reproduce 100% consistently on multiple browsers on my machine with the following steps:

1. Load the page and switch to Practice Mode.
2. Press z 64 times, then press reset. This is one iteration.
3. Complete step 2 5 more times, for a total of 6 iterations.
4. Press z 47 times. On the 47th press and any thereafter, the bug will happen.

My theory is that wee_alloc is to blame. 437 * 604584 * 8 is suspiciously close to 2^31, and this coincides with my inability to reproduce in Turbo Blurbo Mode, as calculate_probabilities_from_game_history() does not allocate nearly as much as calculate_probabilities_with_board_constraints(). Furthermore, safe Rust on its own shouldn't really be able to leak memory. You may find you can fix this by making board_priors an array instead of a vector, but if wee_alloc is, in effect, leaking memory, it would be best to change the allocator.

Because there is much more time spent outside of the game before the first board, the estimate of RNG steps for that interval cannot be as precise. This theoretical effect is observed in practice, where both Linkus and Alberto have much higher standard deviations for the first timer estimate than for later estimates (180 to 31 for Linkus and 179 to 33 for Alberto).

The effect of this right now is that the standard deviation used for one or both of the games will be suboptimal. The effect was initially so pronounced that Linkus asked for this change on the same day the timer was introduced, though changes introduced soon thereafter made it less necessary.

So far there are two suggestions for streamlined ship position entry:

1. Dragging from end to end the position of a ship

2. clicking on the square at one end of a ship and clicking on the square at the other end

both possibilities have the advantage of removing the need to identify which ship (2, 3, 4) is at a particular entry, and reducing the overall number of clicks.

Currently click/ double click is used to indicate to the application game progression on a particular square (hit/miss). Since user of the program will most likely be picking the recommended highest odd space each time, a streamlined input could involve either

1. keyboard shortcut for hit/miss

2. buttons for hit/miss on the suggested square

The sendSpywareEvent() call on App.js:893 makes use of gameHistoryArguments at App.js:901, which is null if not in turboBlurboMode. This results in

TypeError: u is null

Currently the drop down interface is used for number of ships eliminated, but that isn't very ergonomic in a speedrun setting. Possible interfaces:

1. radio buttons
2. set of large buttons for 1, 2, 3
3. single button that can be used to increment up/ down

Currently the Find Match Indices button scans ahead only up to 15,000 RNG ticks. This is sufficient for top level speedrun gameplay, but nowhere near far enough for casual/mistaken gameplay. The scan is purely linear from last match, so a worst case scan (no match found) is still O(n). As such this value can be raised to something like 50k safely, and it will just take longer in the no match case.

Spacebar is working properly but not the z,x,s buttons etc, could be a great fix because I use caps lock to change the values all the way down the page just before getting in the minigame.

Hello,
Apologies if this isn’t the correct channel for communication, but I’d love to learn more about contributing to this project. Is the discord channel still existent/active for development?

Currently clicking the Find Match Indices button will appear to be a noop if no matches are found. Ideally the match area would appear and indicate No Matches or similar.

Various interface suggestions made so far by various people. May want to break out into multiple issues later for better tracking

• Be able to drag out ship positions so that it requires less clicking and ship ID is automatically determined by length; alternately, be able to click on squid start and squid end
• if playing a game using the statistical method and you're always trying the suggested square, having a button or keyboard shortcut to declare hit/miss at the suggested space would speed up play
• left / right click for hit/ miss
• checkbox for if rupees were collected as that changes RNG tick rate
• be able to save the ship positions to the latest super duper mode board from the prediction interface with a "save to grid" button

I have reproduced the bug that Ian and I have encountered. As discussed on Discord, it can result in two similar issues. I have attached a log and will describe the steps I take to reproduce the issue using the same board as pictured:

1. Load the page and initialize Turbo Blurbo mode.
2. Click on the squares for the 3-squid and increment kills to 1.
3. Fill in the 4-squid and the 2-squid without counting their kills.
4. Click to turn on Timer Mode, and click off to prevent space deactivating it.
5. Quickly start the timer and increment kills 3 more times.
   At this point, the app is in an incorrect state. I have previously done this without the timer, and Ian did it before it was implemented, but it is the only way I can get it consistently now.

sploosh_tool_bug_output.txt

During a run, the runner might determine they need to change their first board mean/stddev based on gameplay. Having a set of buttons that allows incrementing/decrementing the textboxes might be helpful. This could be in the form of a set of orders of magnitude buttons e.g.

[-1000]
[-100]
[-10]
| mean entry field |
[+10]
[+100]
[+1000]

I don't know how relevant this or, how true this is.
But would it not be more optimial to instead of firing where there is a highest probability of success i.e. to hit a ship. To fire where there is the ability to spilt the state space in half. I.e. the area cloest to 50%, like in guess who?

Right now the live version has the default React App title and favicon. It would be useful for bookmarking etc if a more descriptive title and favicon were added.

A useful time saving function would be the ability to transfer the ship position information from the top suggested move board to the latest ship position grid. This can be as simple as a button that appears once all ship positions have been determined. In cases where the ship positions may be ambiguous (e.g. 2 and 3 ship laid end to end), the button can be disabled with a notification that the board is ambiguous. In this case we can fall back on manual entry.

credit for original idea to: @Kynsareth

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.

Currently, the tick guessing algorithm for the timer mode is consistently off. I think some data should be compiled to reconfigure the linear fit parameters. So that this can be continuously improved, it may be best to make the intercept and slope configurable and saveable in the user frontend.

If the three rupees behind the board are collected, the RNG tick rate in the room is changed. A user entry method to indicate the rupee state is required for maximally accurate prediction of offset.

Once we get the Sploosh Kaboom tool to a non-alpha/beta state, we will need instructions on how to use the tool.

The ship positioning can be more easily determined visually if the sploosh in game background is reproduced on the website. Maybe have the image overlaid with a lower intensity/ brightness

Currently the program uses click count count to indicate hit/ miss. Using click/right click would streamline data entry and save time on a run.

At the least, the hidden -940 should be removed, since that requires a user to study the code to calculate their ideal values. But it would be better if it was simply a "room entered intercept", so users could change their timed tick intercept without having to adjust this to compensate.

Currently the presumed RNG tick rates/ intercepts are hard coded in the timer prediction algorithm. Having these values be configurable would is desirable for HD/SD support and in case the default internal parameter needs to be corrected.