How to make a platformer with AI
A platformer is a rectangle, some ledges and one jump. The jump carries the whole game, and two small timers are what separate a good one from a mean one.
Jump to a section
Ask for a single screen platformer in one file, then put every hour you have into the jump. Walking, ledges and a flag at the end are quick. The jump is the game. What separates a jump people enjoy from one they blame is two timers, each worth about a tenth of a second.
The first timer keeps the jump available for a short moment after the ground has gone. The second remembers a jump pressed slightly too early and fires it the instant the player lands. Neither appears in a first build. Both are a handful of lines. Name them in the prompt and you skip the worst evening of the project.
Four steps to a jump worth repeating#
You want walking, ledges, a goal and the jump rules in the first version. Level design comes later and is the easy part.
If nothing happens, the build has no coyote time. This is the test, and it takes four seconds.
A buffered jump fires on touchdown and keeps your rhythm. Without it, the game eats every press you make slightly early.
A tap should give a small hop and a hold should give the full arc. If both give the same height, variable height is missing.
Build a single screen platformer as ONE self-contained .html file. No
frameworks, no image files, no audio files.
LEVEL: solid rectangles drawn as canvas fills. A start ledge, three or
four gaps of different widths, two higher ledges, and a flag at the far
right that ends the run. Keep the whole level inside one screen.
PLAYER: a rectangle that walks left and right and jumps on Space or Up.
Resolve collision one axis at a time: apply horizontal movement and push
out of any overlap, then apply vertical movement and push out again.
Landing on top of a rectangle sets a grounded flag and zeroes fall speed.
JUMP RULES. Treat this section as the point of the whole build.
1. COYOTE: keep a countdown that is reset to COYOTE_TIME every frame the
player is grounded, and that drains in the air. A jump is permitted
whenever this countdown is above zero, not when the grounded flag is
true. Walking off a ledge therefore leaves a brief window to jump.
2. BUFFER: when jump is pressed and the player cannot jump yet, store
the press for JUMP_BUFFER seconds. If the player touches ground while
that store is still alive, jump at once on landing.
3. RELEASE: if the jump key is released while the player is still
rising, multiply upward speed by RELEASE_CUT. A tap gives a short hop
and a hold gives the full arc.
4. WEIGHT: use FALL_GRAVITY while falling and RISE_GRAVITY while rising,
with FALL_GRAVITY the larger of the two.
DEBUG: one key toggles a text overlay showing both countdowns, the
grounded flag and vertical speed, so the timers can be watched live.
PHONE: the lower left quarter of the screen walks left, the lower right
quarter walks right, and a tap on the upper half jumps. Add
canvas { touch-action: none; } to the CSS so a drag cannot scroll
the page.
TIMING: multiply every speed and every countdown by the number of
seconds that passed since the previous frame, and clamp that number to
0.05 before anything uses it.
CONFIG: a single object at the top of the script holding WALK_SPEED,
JUMP_SPEED, RISE_GRAVITY, FALL_GRAVITY, COYOTE_TIME, JUMP_BUFFER and
RELEASE_CUT, each with a one line comment. Begin with COYOTE_TIME at
0.1, JUMP_BUFFER at 0.12 and RELEASE_CUT at 0.45.Every number in CONFIG is yours to move, and the jump ones want moving. Leave the axis by axis collision order alone, because solving both axes together is what makes a player snag on the corner of a ledge. Keep the debug overlay until the jump feels right. Watching the two countdowns tick is how you learn what they do.
The two allowances almost no first build has#
Here is the fault, in the order a player meets it. They run along a ledge, reach the end, and press jump. On their screen the character is still over solid ground. In the code, the grounded flag went false one frame earlier, so the press is tested, found invalid and thrown away. The player falls and feels cheated, because they did press the key.
Coyote time is the repair. Reset a countdown to its full value on every frame the player is grounded. Drain it in the air. Permit a jump while it is above zero. The player gets a short grace window after the ledge ends, and no honest press is lost. The name comes from the cartoon pause before a character notices the drop.
Jump buffering is the same idea pointed the other way. A player falling towards a ledge presses jump a fraction early, hoping to bounce straight off. A strict check says they are airborne and refuses. Instead, store the press for a short time. On the next landing, if the store is still alive, jump immediately. Chained jumps stop depending on reflex timing.
Both are allowances the player never sees and never thinks about. That is the point. A fair platformer is one where the player blames themselves for a miss and is right to. Without these two timers they get blamed for presses the game simply discarded.
Variable jump height is one multiplication#
A jump with one height gives the player one option. Every gap is cleared the same way and every ceiling is hit at the same speed. Variable height turns the jump key into an analogue control with no extra input.
The rule is small. On the frame the key is released, check whether the player is still moving upwards. If so, multiply the upward speed by a fraction well under one. The rise cuts short, the fall begins early, and a quick tap becomes a small hop. Holding the key changes nothing, so the full arc is the default.
Do not try this by cutting the jump at a fixed height, and do not add gravity while the key is held. Both fight the physics you already have and both produce a jump that stutters at the top. One multiplication on release is enough, and it reads as one line in the file.
Why the fall should be heavier than the rise#
Symmetric gravity is correct and it feels wrong. With one constant the arc is a clean parabola, the character floats at the apex, and the descent takes exactly as long as the climb. Players read that as swimming rather than jumping.
Use two values. Apply the smaller one while vertical speed is upwards and the larger one while it is downwards. The rise stays long enough to read and aim. The fall snaps, which is what makes a landing feel like contact. Starting from double the rise value is a reasonable place to begin.
A second trick helps on long drops. Cap how fast the player can ever fall. Without a cap, a tall level accelerates the character past the depth of a platform in a single frame and they pass through the floor. That exact fault, and the general fix, belong to the physics guide.
Starting numbers, and how to move them#
These are starting points, not correct values. They are chosen so the jump is immediately playable and so every fault is easy to feel. A platformer about precision wants shorter windows. One about momentum wants longer ones. Change one row, play for a minute, decide.
| Number | Start at | What moving it does |
|---|---|---|
| Coyote time | 0.1s, about six frames | Longer feels generous, then floaty. Past 0.2s the ledge stops mattering. |
| Jump buffer | 0.12s, about seven frames | Longer chains jumps for you. Too long and one press gives two jumps. |
| Release cut | 0.45 of current rise | Lower makes taps tiny. At 1.0 the key has no fine control at all. |
| Rise gravity | Whatever makes the arc readable | Higher shortens every jump. Adjust jump speed with it, not after it. |
| Fall gravity | Twice the rise value | Higher lands harder. Very high and the player drops like a stone. |
| Max fall speed | Roughly the player's height per frame | A cap, not a feel knob. It stops fast falls skipping thin floors. |
Six frames and seven frames are the same claim: a tenth of a second, which nobody can perceive and everybody can feel.
One warning about tuning with a model. Changing the whole block at once is how you lose a jump you liked. Ask for a single number, play, then ask for the next. The pillar guide covers that loop, so read it there rather than here.
What to add once the jump is right#
Only after a bare rectangle is pleasant to move does level content pay off. In the wrong order, you build twelve rooms around a jump you later replace.
- One gap you cannot clear. It teaches the player the exact reach of the jump better than any sign. Put it early, where falling costs nothing.
- Moving platforms, carried properly. The player must inherit the platform's movement while standing on it, or they slide off anything that moves sideways.
- A hazard, not an enemy. Spikes and pits need no artificial intelligence and test the jump directly. Patrolling enemies can wait.
- A respawn that is instant. Measure the time between death and the next attempt. Anything over a second turns practice into punishment.
- Coordinates written down. Ask for the level as an array of rectangles near the top of the file. Editing numbers beats editing drawing code.
🏃Platformers written by AI
Sonnet 5.5
Gemini 3.8 Flash
MiMo V2.6 Pro
OpenAI CodexCommon questions#
Can AI build a platformer that feels good to play?
Yes, if you ask for the jump rules explicitly. Models write walking, gravity and rectangle collision reliably. What they leave out unless asked is coyote time, jump buffering and variable height. Name all three in the prompt and the first version is already close.
What is coyote time?
A short window after the player leaves solid ground during which a jump is still accepted. It exists because the player sees their character at the ledge while the code has already marked them airborne. About a tenth of a second is invisible and removes most unfair deaths.
What is jump buffering?
Remembering a jump pressed slightly before the player lands, then firing it on touchdown. Without it, any press made a few frames early is discarded and the player has to press again. With it, a run of jumps stops depending on frame perfect timing.
Why does my character fall through platforms?
Almost always fall speed. If the character moves further in one frame than the platform is thick, the overlap test never sees it. Cap the fall speed and make floors thicker than the fastest movement. Resolving one axis at a time also helps.
Why does my character stick to walls in mid air?
Horizontal and vertical movement are being resolved together, so the corner of a ledge counts as a side hit. Move horizontally, push out of overlaps, then move vertically and push out again. Side contact then stops the walk without cancelling the jump.
Should the jump be a fixed height or variable?
Variable, in almost every case. It costs one multiplication when the key is released and gives the player a whole range of hops from a single key. Fixed height suits a game where the only input is one tap and precision is deliberately removed.
Where to go next#
When a stranger can clear your first gap without being told how, put it up. The page it gets records the model and the prompt behind the build, which is the part other people want to read. The platformers here are the fastest way to calibrate your own jump, because a bad one announces itself within two ledges.
For the general method, start at how to make a game with AI. Collision, gravity and the fixed step are handled properly in the physics guide. The drawing side, including sprites and a camera, sits in the 2D guide, and ready made fixes for common faults are in the prompt guide.
Built something? Put it on Agent Games.
Publishing takes a file and a minute. Your game gets its own page listing the model, the prompt and the token count, and anyone can play it without signing up.
Read next