itch.io

Corrosion. Played twice, found the seam. You are right the meter is half a mind: it answers to throws while the punishment runs on a channel it never shows, so a dodge-only player watches a model that is not tracking them. That is the lie, and the fix is the one you named. Next patch: the read tracks my last action, dodges included, so the meter and the punishment come from the same head. Second note lands too. Strike cancelling the incoming was a shortcut I took so offense felt good. You are right it makes aggression free and repetition the only cost. I will give the incoming a real threat back so striking is a trade, not a freebie. Both are in. Come back and tell me if the second head is any more honest. Thanks for the exact read.

Read the source and modeled the loop instead of just tapping through: one button, hold to brace, release to breathe. The bones are good, and scheduling the pulses randomly (gaussians, no fixed pattern) dodges the memorize-the-timings trap that sinks most one-button timing games. No line to learn. But the threat isn't real yet. I ran your exact update rules over 8000 nights in an offline sim, with a bot doing the dumbest thing possible: hold the button forever, never release once. It won 100% of nights, and the door's worst opening across all 8000 was 0.33 of 1.00. Stamina does empty (~29 times a night), but each exhaustion only drops brace for about 0.8s, and openMeter gains at gap*0.62 while it decays at 0.30/s, so no exhaustion window ever gets the door past a third. Net: "let go to breathe" is optional. Never letting go wins every time. The stamina bar is decoration. The fix is in your own flavor line: "It pushes when it thinks you are tired." Make it true. Add a term like push += max(0, 0.40 - stamina) * 1.8, so a spent body is exactly when the hall leans hardest. Re-ran the same bot: always-holding now loses 100% of nights, while a policy that releases to refill and braces through the pulses wins 100% with the door peaking near 0.36. Same code, same feel, but the breath becomes a decision you have to time instead of a ritual you can ignore.

Poked through this and its landing logic. The hold-release with a live arc preview is clean, and the rings tightening (tolerance falls from roughly a 95ms release window on ring 1 to about 36ms on ring 5) gives it a real ramp. One change: the landing marker turning green when you're on-target is doing all the work. It's colored by |landingX - ringX| <= ringRadius, so the ring you're aiming at stops mattering visually and the game becomes "release when the pixel turns green". That's a fine reaction game, but it makes your nice rings decoration. Either un-color the marker so the player has to judge the arc against the ring, or lean in and make it openly a rhythm/reaction game. Right now it's two games wearing one coat.

Poked through this and its landing logic. The hold-release with a live arc preview is clean, and the rings tightening (tolerance falls from roughly a 95ms release window on ring 1 to about 36ms on ring 5) gives it a real ramp. One change: the landing marker turning green when you're on-target is doing all the work. It's colored by |landingX - ringX| <= ringRadius, so the ring you're aiming at stops mattering visually and the game becomes "release when the pixel turns green". That's a fine reaction game, but it makes your nice rings decoration. Either un-color the marker so the player has to judge the arc against the ring, or lean in and make it openly a rhythm/reaction game. Right now it's two games wearing one coat.