Variable-Height Jump

A variable-height jump goes higher the longer the button is held. The jump starts at full speed, and as soon as the button is let go the rise slows to a low speed. A tap gives a short hop, a long press a full jump. Check whether the button is still down, not when it is let go.

Also called: Variable jump height, Jump cut, Short hop, Hold-to-jump-higher.

Paste this to your AI

Copy it into Claude, Cursor or ChatGPT. It already has good values and the usual mistakes in it.

Add "Variable-Height Jump" to my game.

What it should do: One button gives the player a whole range of jumps, from a short hop to a full leap, just by how long they hold it. So every jump is in their hands.

Build it exactly as this state machine. First check that it fits my game, then build it like this:

```mermaid
stateDiagram-v2
  [*] --> ground
  ground: On the ground
  full: Full rise
  slow: Slow rise
  falling: Falling
  ground --> full: press and hold
  ground --> slow: quick tap
  ground --> falling: walks off the edge
  full --> slow: button up, or slowing
  slow --> falling: reaches the top
  falling --> ground: lands
```

Use these starting values:
- jumpSpeed: 12 units/s
- cutSpeed: 4 units/s
- gravity: 32 units/s²
- maxFallSpeed: 20 units/s

Watch out for these common mistakes:
- A quick tap gives a full jump: Tell your AI: start the jump first, then shorten it in the same step.
- The button is already up when the jump starts: Tell your AI: check on every moment of the rise whether the button is still down. See jump buffering for more.
- The short hop changes with the frame rate: Tell your AI: limit the rise to one fixed speed, or add extra gravity that takes the time passed into account.
- Being thrown up gets cut short: Tell your AI: only shorten a rise that came from a jump.

Do not change anything else in the game. Do not claim anything without proof: model what it takes, and show me what your solution rests on and how I can see that it works. If you cannot show something, say you do not know. When you are done, tell me in plain words how to try it.

Or skip this and connect the MCP: your AI then finds all of this by itself.Connect the MCP

What it does

One button gives the player a whole range of jumps, from a short hop to a full leap, just by how long they hold it. So every jump is in their hands.

How it runs, as a diagram

Everything it can be in, and what moves it on. Your AI builds from exactly this.

Good starting values

What usually goes wrong

How to check it works

• Your character stands on the ground. Press jump and hold until the top of the jump: The jump reaches full height.
• Your character stands on the ground. Tap jump as quickly as you can: You get a short hop, well under the full height.
• Your character is rising fast in a jump. Let go of the button: The rise slows down at once, and after that only gravity acts.
• Your character is falling after a jump. Hold the button, then try again without holding it: The fall is the same either way.
• Your character is thrown upward by something other than a jump. Do not touch the button: The character keeps its speed, apart from gravity.
• Your character is in the air. Press jump: Nothing happens.

Works well with

• Jump Buffering: The other way round, a quick press can give a full jump. See jump buffering. Start the jump first, then keep watching whether the button is still down.
• Coyote Time: A jump from the extra moment after a ledge should be just as easy to shorten as one from the ground. Start the jump first, then shorten it.
• Double Jump: An air jump can be shortened the same way. Decide if it should be; a fixed air jump is easier to judge.

Common questions

Where it comes from

Earliest example we could find: Super Mario Bros. (Nintendo) (1985). Jeremy Parish's 2013 analysis says how long the button is held sets the height and length of Mario's jump, and that starting speed also changes it. The 2016 DiGRA paper's history section reports the game as cited for player control of jump height and distance. Nothing opened here documents the behaviour in an earlier game, but no systematic check of earlier games was possible.

1. 1985 Super Mario Bros. (Nintendo): Jeremy Parish's 2013 analysis says how long the button is held sets the height and length of Mario's jump, and that starting speed also changes it. The 2016 DiGRA paper's history section reports the game as cited for player control of jump height and distance. Nothing opened here documents the behaviour in an earlier game, but no systematic check of earlier games was possible. [Anatomy of Super Mario: X. Super-sized (Jeremy Parish, The Anatomy of Games, 2013-08-07; archived mirror)][You Say Jump, I Say How High? Operationalising the Game Feel of Jumping (Fasterholdt, Pichlmair, Holmgard, DiGRA/FDG 2016)]
2. 1988 Super Mario Bros. / Duck Hunt instruction booklet (Nintendo of America): The official booklet tells players that holding the button longer gives a higher jump. The booklet itself could not be opened; the wording is taken from a MarioWiki user page that quotes and cites it, which is a weak route to a primary document. [User:KamekSans/Projects/Lists of Jump Profiles/List of Jump Profiles (1981-1989) (Super Mario Wiki user page)]
3. 2010 Adam Saltsman, 'Tuning Canabalt': A developer's technical write-up explains a held-button jump driven by a timer that also depends on running speed. It is a public account of how such a jump can be built, with the reasoning given by its author. [Tuning Canabalt (Adam Saltsman, Game Developer/Gamasutra blog, 2010-09-29)]
4. 2010 Super Mario Bros. development notes, printed in Nintendo's 25th Anniversary Collection book: Undated pre-release planning notes became public when Nintendo printed them, and a December 2010 blog post on GlitterBerri reproduces them. In the English translation, jump height depends on Mario's speed when the button is pressed. The blog says the Japanese original also mentions button input, and contains unresolved placeholders. These notes show planning, not what shipped. [Mario Development Notes (GlitterBerri, 2010-12-19)]
5. 2014 Yoann Pignole, 'Platformer controls: how to avoid limpness and rigidity feelings': A developer blog post contrasts a fixed jump with one that can be cut short, argues the difference matters in jump-focused games, and names Super Meat Boy, Mario and Sonic as examples. [Platformer controls: how to avoid limpness and rigidity feelings (Yoann Pignole, Game Developer, 2014-01-03)]
6. 2016 Kyle Pittman, 'Math for Game Programmers: Building a Better Jump' (GDC 2016 talk): A GDC talk on building jump trajectories from designer-facing inputs. Its session overview lists height that varies with player input among the non-parabolic cases it covers. Only the overview was read, not the talk. [Math for Game Programmers: Building A Better Jump (Kyle Pittman, Minor Key Games, GDC Vault, GDC 2016)]

Super Mario Bros. is the earliest documented case here, not an established origin. Source claim: Fasterholdt, Pichlmair and Holmgard (2016) say the game 'is cited as the first game' allowing control of jump height and distance, reporting Tom Butler's 2014 Polygon feature 'The Rise of the Jump', which could not be opened. That is their report of Butler's account, not this project's claim. Parish contrasts Mario with the fixed arcs of other platformers but gives no list of checked games. No source opened here shows a pre-1985 game with hold-length jumps, and none rules one out. Pac-Land (1984) was checked as a candidate because it came up as a predecessor, but its Wikipedia article says nothing about holding the jump button. Design intent is undocumented: the Iwata Asks chapter on the original developers, read here, covers moving jump from the D-pad to a button but not hold-length height, and no Miyamoto or Tezuka statement on variable height was found. The GlitterBerri notes tie height to speed, which is a related but different dependency from hold time, so they should not be read as evidence for the hold mechanic on their own. Parish names no written sources for his description; it reads as direct play analysis, which is acceptable for an observable behaviour. Steve Swink's Game Feel analyses the Super Mario Bros. jump according to the 2016 paper, but the book could not be opened, so it is not used. Booklet page numbers are left out because results disagreed. Celeste's jump peak is also relevant, but Thorson's description of it gives a numeric gravity ratio, so it is left out under the no-constants rule.

Games are named only as references. Names and marks belong to their owners, and nothing here is endorsed by them.

What was checked

• 11 tests pass on the reference code.
• The state diagram was checked against the code, at the default values and at every listed low and high value.
• The Godot port passes the same tests on the real engine.

This is what separates the blueprint from a catalogue entry: the values on this page come from code that runs.

Your AI gets the code

Tested example code comes through the Spielerando connection, so your AI can use it right away. How to connect it