Build Log: Tuning Shake Threshold From 18 to 11 m/s²
Our first shake threshold was 18 m/s² of net acceleration, picked from a 2019 Stack Overflow answer that nobody on the team questioned. After 31 deploys and 4,800 game sessions on ShakeGasm, we had enough telemetry to see the floor was too high. Players with smaller wrists, women holding lighter phones, and anyone seated were missing 22 percent of intended shakes. This build log walks through the 9-day rewrite that dropped the threshold to 11 m/s² without triggering false positives from walking, typing, or table taps. Every number here comes from production logs between May 14 and May 23, 2026.
Why 18 m/s² was wrong
Earth gravity sits at 9.81 m/s², so an 18 m/s² floor demanded almost 2g of net force above gravity to register a single shake. A wrist flick from a seated player rarely crosses 14 m/s² on an iPhone 13, which we confirmed with a 600-sample recording session last March. The legacy code path used the raw userAcceleration vector and a Euclidean magnitude check, which kept the math fast but ignored the direction of motion described in our how shake detection works post. Our session data showed 38 percent of failed rounds had at least one log line reading shake_detected=false, peak=15.4. Players blamed the app, not the threshold. Three support tickets in April called the game broken on Pixel 7a hardware, where the accelerometer caps at a slightly lower peak under fast motion. The 18 m/s² number was a guess that survived because nobody had run the histogram.
The data we collected
We added a shake_telemetry event in version 1.4.2 that logged the peak magnitude of every gesture above 6 m/s², plus device model, orientation, and round type. Over 11 days the event fired 412,000 times across 1,180 unique installs of ShakeGasm. Plotting peak magnitude as a histogram showed two clean clusters: incidental motion centered at 4.2 m/s² and intentional shakes centered at 13.8 m/s² with a long tail to 26 m/s². The valley between the two clusters sat at 10.4 m/s², which is the gap any robust threshold needs to live inside. The plot also confirmed a 0.6 m/s² gap between iPhone Pro Max devices and the lighter iPhone SE, which we baked into a per-model offset table. Cross-referencing with our sensor sampling rate work showed the 100Hz devices produced slightly noisier histograms than the 200Hz pool.
Picking 11 m/s² as the new floor
We tested four candidate thresholds against 200 replay sessions before shipping. The replay harness pulled raw sensor frames from prior games and ran them through the new detector offline, which let us compare hit rate and false-positive rate without bothering players. The four candidates produced these results:
- 9 m/s²: 99.1 percent hit rate, 14 percent false positives from walking
- 10 m/s²: 97.8 percent hit rate, 6 percent false positives
- 11 m/s²: 96.4 percent hit rate, 1.2 percent false positives
- 12 m/s²: 91.0 percent hit rate, 0.4 percent false positives
11 m/s² won because the false-positive rate fit our 2 percent budget and the hit rate stayed inside the band players described as fair in beta interviews. We added a 35ms cooldown after each fire to stop double-counts from the rebound oscillation that follows a sharp flick. The cooldown alone removed 3.8 percent of redundant fires that had been padding round scores. We also locked the cooldown to wall-clock time rather than frame count, since frame pacing drifts under heavy GPU load on older Android handsets.
The floor lives inside the valley between incidental motion and intentional flicks. Move it 1 m/s² in either direction and either hit rate or noise tax pays the bill.
What broke when we shipped it
Lower thresholds catch more, including motion you do not want to count. The first build hit the App Store on May 18 and tripped on three patterns we had not modeled. Players who set the phone face-down on a wooden table triggered the detector from the table thump of a heavy footstep nearby. Riders on a Bangkok BTS train logged 80 false fires per minute during the morning commute. A single user who plays from a powered wheelchair triggered a fire every time the chair crossed a sidewalk crack. We pushed a 1.4.3 hotfix on May 20 that added a 200ms low-pass filter and a check for sustained vibration above 4 m/s², which rejects ambient motion lasting longer than one wrist flick. The hotfix shipped through the same 27-second deploy chain documented in the Cloudflare Pages auto-deploy post, so the rollback window was small enough to ship on a Sunday.
Numbers from week one
One week after shipping 11 m/s², median time to first scored shake on ShakeGasm dropped from 2.4 seconds to 0.9 seconds. Session length climbed from 7 minutes 12 seconds to 9 minutes 41 seconds, a 35 percent gain that matches what the haptic feedback loop post predicted for any latency cut under one second. Day-three retention moved from 24 percent to 31 percent across the 614 installs that came in during the test window. Support tickets mentioning the word broken dropped from 11 in the prior week to 1. The remaining ticket came from a player using a phone case with a 4mm rubber damper that absorbs flicks below 12 m/s², which we flagged as a hardware edge case rather than a code fix. Next on the queue is a per-game threshold override so the bedtime mode round can demand a harder flick than the standard party round.
Stop reading. Start shaking.
Five stages. One climax. Free in your browser, free on Android — voice packs optional.
Play ShakeGasm now
