Guide

Game bounce pad, spring and trampoline systems explained

Harbor Ascent's Crystal Spire shaft stacks four bounce pads in a narrow column with moving hazards between each tier. Playtesters reached the summit exit at 29% when pads were cosmetic flippers that added a flat +4 m/s upward bump on any contact. They overshot the second landing by two meters on a full run-up jump, then undershot the third tier when they tried to tap-jump off the pad instead of letting it launch them.

Level designers widened one platform and added a checkpoint. Summit rate moved to 38%. Physics shipped velocity-set springs with per-pad apex targets, entry-speed clamps, and a 0.35 s re-trigger lockout; the same geometry hit 74% without mesh edits. Bounce pads are authored vertical beats, not floor decorations. This guide covers pad taxonomy, velocity-set vs impulse-add models, directional and angled launchers, chain and cooldown rules, stomp and pogo interactions, variable jump coupling, readability and telegraph design, the Harbor Ascent refactor, a technique decision table versus manual jump arcs and moving platforms, pitfalls, and a production checklist. It pairs with jump arc and gravity tuning and platformer design fundamentals.

Pad taxonomy: bounce, spring, trampoline, launcher

Players lump every upward surface into “springs,” but systems teams usually distinguish four families:

Bounce pad (fixed launch)

A bounce pad sets vertical velocity to a fixed target when the player lands on it, regardless of entry speed (within a clamp). Classic Mario question-block bounces and Celeste dash-refill crystals behave this way. The player learns: “stand on it, get height H.”

Spring (directional impulse)

A spring applies impulse along a authored normal vector. Angled springs launch diagonally; wall springs push away from surfaces. Impulse magnitude may scale with entry velocity or stay constant.

Trampoline (momentum-preserving)

A trampoline reflects or amplifies incoming vertical velocity: v_out = -k × v_in with restitution k > 1 for super-bounces. Skill expression comes from how hard you hit the surface. Sonic springs and competitive platformer footstools use this model.

Launcher (one-shot catapult)

A launcher fires once per activation — often after a charge animation, switch trigger, or stomp. Trajectory is fully scripted; player input during flight may be locked or heavily damped. Boss arenas and carnival levels use launchers for set-piece arcs.

Mixing families in one level without visual distinction is the fastest way to make vertical rooms feel random instead of fair.

Physics models: velocity-set vs impulse-add

Implementation choice determines whether pads feel predictable or chaotic.

Velocity-set (authoritative apex)

On contact, set vy = v_target (and optionally zero vx for pure vertical pads). Entry speed above v_target is clamped down; below is boosted up. Players get identical apex from a idle stand or a running approach — ideal for teachable vertical gauntlets.

Impulse-add (additive bump)

On contact, add Δv to current velocity. A fast-falling player gets a higher peak than a gentle landing. Additive pads reward momentum but punish players who do not understand the coupling — the Harbor Ascent 29% failure mode.

Hybrid: target with entry scaling

Many shipped titles use vy = lerp(v_in, v_target, blend) where blend is 0.8–1.0 for forgiving pads and 0.3–0.5 for skill trampolines. Document the blend per pad tier in data, not hard-coded.

Grounded-only vs airborne triggers

Decide whether pads fire when the player lands from above only, or also when passing through from below (one-way collision). Stomp-from-above pogo chains need a separate hitbox on enemies; floor pads usually require vy <= 0 and grounded contact to avoid mid-air re-triggers.

Chain rules, cooldowns and pogo interactions

Vertical shafts fail when pads re-fire every frame or when players cannot chain intentionally.

Re-trigger lockout — ignore pad for N frames after launch (Harbor uses 21 frames at 60 Hz). Prevents double-bounce jitter on thin colliders.
Pad-to-pad minimum airtime — require time_since_launch > T_min before the next pad can arm. Stops infinite height on stacked triggers in one physics step.
Pogo stomp budget — enemy head-bounce chains share a counter with floor pads or use separate cooldown namespaces so a stomp does not consume pad lockout.
Jump hold after launch — if variable jump cut applies while rising off a pad, define whether hold extends apex or is ignored until apex pass. Ignoring hold for 6–10 frames after launch makes pad height consistent.
Double jump consumption — clarify whether a pad reset aerial budget (refill double jump) or only modifies velocity. Celeste-style refills are a separate flag from generic bounce pads.

Publish a one-page FSM: Grounded → Launched → PadLocked → Aerial with transitions and which inputs are accepted in each state.

Directional springs and angled launchers

Diagonal springs complicate level metrics. Author launch normal n and target speed |v|; set velocity to v = n × |v| on trigger. For wall springs, zero velocity component into the wall to prevent embedding.

Debug-draw the predicted arc from pad center using the same gravity constant as player movement. Designers place receiving ledges at apex or at a taught landing frame, not by eye. Angled pads that launch into ceiling spikes need a minimum clearance check in the level validation tool.

Moving platforms as launch surfaces inherit platform velocity at trigger moment: v_player += v_platform before applying pad impulse. Omitting platform velocity is a common source of “the pad lied to me” bug reports on elevators.

Readability: telegraph, audio and color language

Pads are UI for vertical puzzles. Players should parse behavior before stepping on:

Color tier — weak / medium / strong launch tiers map to consistent hues across the game (Harbor: teal = 3 m apex, gold = 6 m, violet = 9 m scripted launcher).
Compression animation — squash on contact, stretch on release; 80–120 ms total. Animation must match physics trigger frame.
Pre-activation glow — optional for switch-gated launchers so inactive pads read differently from armed pads.
Audio pitch by tier — same SFX family, semitone step per strength; players hear overshoot before they see it.
Particle burst direction — sparks along launch normal sell diagonal springs without a tutorial text box.

Never reuse the strong-pad mesh for a weak pad with different data. Players trust shape memory more than tooltip copy.

Harbor Ascent Crystal Spire refactor

The shaft has four tiers: 3 m, 6 m, 6 m, and 9 m apex targets with wind gusts between tiers. Before the refactor, pads used impulse-add +4 m/s on any contact. Problems:

Tier 1 with run-up jump: 68% overshot into ceiling vines (damage).
Tier 2 tap-jump off pad: 61% undershot — players fought the pad.
Tier 3 chain: only 29% reached summit in one life.

Changes shipped:

Velocity-set vy per tier with entry clamp [0, v_target].
21-frame pad lockout and 0.35 s inter-pad minimum airtime.
Jump-hold ignored for 8 frames post-launch so cut gravity does not steal height.
Moving platform on tier 2 adds velocity at trigger.
Debug arc overlay in editor for each pad normal.

Results on unchanged geometry: tier 1 overshoot 68% → 9%; tier 2 undershoot 61% → 14%; summit reach 29% → 74%; chapter completion 38% → 71%. Surveys ranked “pads feel consistent” above checkpoint and width changes from the prior patch.

Technique decision table

Approach	Best when	Strengths	Trade-offs
Velocity-set bounce pad	Teachable vertical shafts, puzzle platformers	Predictable apex; fair for all entry speeds	Less skill expression; speedrun routes need alternate tech
Impulse-add / trampoline	Momentum games, stomp chains, speedruns	Rewards mastery and entry velocity	Harder to author; opaque for casual players
Directional spring	Diagonals, wall kicks into lanes, circus levels	Compact vertical+horizontal beat in one object	Requires arc debug tools; easy to launch into hazards
Scripted one-shot launcher	Boss transitions, story set-pieces	Cinematic control	Low agency; poor for repeated mastery loops
Manual jump-only (no pads)	Tight precision gauntlets, fighting-game platforms	Full player ownership of arc	Tall shafts need wider spacing or more verbs

Common pitfalls

Additive bump on variable entry speed — players cannot learn tier heights; use velocity-set or document scaling clearly.
No re-trigger lockout — physics substeps fire pad twice; random double height.
Pad fires while rising — passing through pad hitbox from below triggers unintended launch.
Ignoring platform velocity — elevator pads feel inconsistent at different platform speeds.
Jump cut steals pad height — hold-to-cut applies same frame as launch; apex collapses.
Visual tier mismatch — same art, different v_target; players distrust all pads.
No editor arc preview — designers place ledges at wrong frame; art pass fixes mask physics bugs.
Network desync — pad trigger on client only; server rejects position. Authoritative trigger on grounded contact server-side.

Production checklist

Define pad taxonomy (bounce, spring, trampoline, launcher) in movement spec with one FSM diagram.
Pick physics model per tier: velocity-set, impulse-add, or hybrid blend — expose in data.
Set v_target, entry clamp, launch normal, and lockout frames per prefab.
Wire pad lockout and inter-pad minimum airtime; test stacked pads at 30/60/120 Hz.
Specify jump-hold and double-jump behavior for N frames after launch.
Add platform velocity inheritance on moving launch surfaces.
Build editor arc overlay from pad using production gravity constants.
Establish color/audio tier language; ban mesh reuse across strength tiers.
Sync squash-stretch animation to physics trigger frame.
Telemetry: overshoot/undershoot rate per tier, pad re-trigger counts, summit reach.

Key takeaways

Bounce pads are authored vertical beats — physics model choice matters more than platform width.
Velocity-set launches teach stacked shafts; impulse-add trampolines reward momentum mastery.
Harbor Ascent raised Crystal Spire summit reach from 29% to 74% with velocity-set tiers and lockout rules alone.
Chain rules, jump-hold grace, and platform velocity must be specified in the same FSM as the pad trigger.
Color, audio, and arc debug tools are part of pad design — not polish pass.