Grapple Platformer Prototype

A 2D action platformer prototype exploring custom physics-driven movement

Role
Solo Developer — Design & Engineering
Engine
Unity 2D (C#)
Status
Ongoing prototype
Tags
action-platformercustom-physicsgrapple-mechanicsmomentum-systems

Play it: itch.io | Source Code



Design Intent

Three symbiote-derived abilities — grapple tendril, shotgun recoil, wall adhesion — each distinct in use, all interconnected in play. The design question isn't speed accumulation: it's how many interesting ways a player can chain these through a given space. The skill ceiling is spatial reading and creative routing. The prototype exists to test whether that's actually fun. It is.


Key Design Decisions

Custom physics over Unity's built-ins

Unity's built-in drag and friction assume the player stops when they stop inputting. Prototyped with the built-ins first — momentum died at exactly the moments it should have felt best.

Built a physics-assist layer instead, running in FixedUpdate after the physics step: reads the simulation result, applies corrections only when clearly wrong, leaves everything else untouched. Base move speed 12 units/s, global cap 32 — 3× headroom intentionally. Ground acceleration 80, air control 20 — the asymmetry makes airborne trajectories feel committed, not trivially correctable.

The grapple system

Custom pendulum simulation, not a Unity joint. On attach, records rope length as Euclidean distance to anchor. Each FixedUpdate, decomposes velocity into radial and tangential components, damps radial toward zero, preserves tangential as swing arc. Swing damp: 1.002 — fractionally above 1.0 to counteract floating-point losses, making the pendulum feel nearly lossless. Range: 20 units — forces players to position into swing angles rather than latching from anywhere.

Dynamic rope retraction. At speed mid-chain, the player often arrives at the anchor with inward radial velocity — in a fixed-length pendulum that goes slack, killing momentum right when it should compound. The fix: rope length retracts dynamically to match the player's actual position, keeping the tether taut and converting inward velocity into angular momentum at the tighter radius. The ice-skater effect, applied reactively. The grapple isn't a rope — it's the symbiote extending itself. A rope goes slack; a symbiote contracts. The physics necessity became the thing that makes it feel alive.

The shotgun as primary propulsion

Impulse: 18 force, stronger than jump force (14) — the shotgun is the primary propulsive tool, not a weapon with a movement side effect. While grappling, impulse adds directly to velocity (swing accelerator mid-arc); while grounded or airborne, triggers a timed dash — 0.3s, 4 units, max 15 units/s. Cooldown 1.6s enforces the rhythm: grapple, fire on the swing, reload, repeat.

Tradeoffs


What's Next

Movement loop is where I want it. Next: greybox levels designed to reward chains — long corridors to build velocity, vertical shafts for grapple-to-shotgun transitions, tight gaps that punish overcommitting.

The thing I'd change: the 1.6s shotgun cooldown is tuned for the intended rhythm but never communicated. A visual or audio cue tied to the swing tempo fixes this without touching any values — feedback design, not mechanics design.


Planned Combat Direction

Core question: what if every combat decision was also a movement decision?

A mark system: the shotgun applies marks to enemies; only marked enemies can be grappled. Grappling a marked light enemy pulls you toward them; grappling a marked heavy with enough momentum swings them. Same input, different mass interaction, different tactical outcome. PlayerCombat is already stubbed as a standalone component on the shared state hub — when comb

↑↓ navigate ↵ open esc close ⌘K toggle