Fall was still too slow after decision 0029's bounce fix -- fixed the real drag mismatch (velocity_damping) plus raised gravity, roughly halving real fall time

Context

Direct user report after decision 0029/0030 shipped: the descent's pace ('rate of decline') was still too slow and needed to be 'much faster.' Decision 0029 had deliberately left gravity unchanged, since measurement at the time showed the *elastic rebound*, not the raw descent, was the demonstrated defect -- but explicitly flagged entity.velocity_damping as 'the more effective lever than gravity itself if further slowing is wanted later,' along with the finding that this constant's real, compounded effect (per-frame 0.98, which is ~30% of velocity kept after one second of continuous freefall) already contradicted its own doc comment's description of 'a little' drag. With a direct user report now confirming the descent itself needs to be faster, not slower, that same lever applies in the opposite direction: raising velocity_damping toward 1.0 reduces drag, letting gravity actually dominate free-fall the way the original doc comment always intended, rather than being capped by an implicit ~80 units/s terminal velocity the drag alone was imposing.

Options considered

Raise gravity alone, leave velocity_damping at 0.98 — rejected

velocity_damping's compounding effect scales with gravity too (a higher per-frame gravity kick is proportionally damped by the same 0.98 factor every frame) -- raising gravity alone runs into the same implicit terminal-velocity ceiling sooner, just reaching a higher (but still artificially capped) plateau, rather than genuinely fixing the mismatch between the constant's documented intent ('a little' drag) and its real, measured, dominant effect.

Raise velocity_damping alone (toward 1.0, less drag), leave gravity at -98.0 — rejected

Computed and confirmed the ceiling this hits: even with drag reduced enough to let gravity ~fully dominate over an 80-unit fall, gravity itself (-98.0) only produces a ~1.3s fall by pure kinematics (sqrt(2*81/98)) -- a real improvement over the previous ~1.7-1.85s, but not the 'much faster' the user asked for after already seeing the bounce fix alone wasn't enough.

Fix both together: raise velocity_damping from 0.98 to 0.997 (so it's genuinely 'a little' drag, ~17% lost per second instead of ~70%) and raise gravity from -98.0 to -250.0 — chosen

Addresses the real, measured root cause (drag was never 'a little', contradicting its own doc comment) rather than just compensating for it with a bigger gravity number, while also giving gravity itself more room to work with. Verified the per-frame gravity kick at the new value (250/60 ≈ 4.17 units/s) stays comfortably under half of genuine_impact_velocity (15.0, decisions 0027/0028's ramp reference), preserving the invariant that resting-contact absorption still applies to ordinary per-frame gravity disturbance -- so this doesn't reopen the resonance/perpetual-bounce investigation those decisions closed.

Decision

entity.gleam's velocity_damping raised from 0.98 to 0.997 (doc comment rewritten to state the real, compounded per-second effect of both the old and new value, not just the per-frame face value, which was the actual source of the original mismatch). game.gleam's main() gravity raised from Vector2(0.0, -98.0) to Vector2(0.0, -250.0), doc comment updated to reference this decision and the measured before/after numbers.

Verification

146 Erlang / 169 JavaScript gleam test cases passing on both targets, unaffected (no test asserts an exact fall duration or velocity_damping's specific value). Re-ran the real headless-Chromium full-height-drop trace (same methodology as decision 0029): fall time from spawn to settled rest dropped from ~1.7-1.85s to 0.95s -- roughly a 45-50% reduction, with the landing still settling cleanly (a small ~0.5-unit wobble, not a large rebound -- decision 0029's restitution fix is unaffected by this change). Re-ran the real two-different-tier stacking probe three more times at the new, higher speeds specifically to confirm decisions 0027/0028's resonance fix still holds under faster impacts: all three runs converged to the exact same stable resting y-values (2.2767 and 15.277, repeating with zero variation across the sampled tail) rather than oscillating -- no regression.

Consequences

Drops now read as noticeably snappier, addressing the direct 'still too slow, make it much faster' report. entity.velocity_damping's doc comment now accurately describes its real effect at both the old and new value, which should prevent a future change from re-introducing the same 'a little vs. actually dominant' mismatch without noticing. Gravity (-250.0) and velocity_damping (0.997) are still tunable constants, not claimed to be exactly, provably 'correct' -- if the descent still doesn't feel right after this, the same two levers (this decision's reasoning for which does what) are the ones to revisit, not new ones.

References

• src/glemy/pe/entity.gleam
• src/glemy/game.gleam