Platforming and Coin Collection Mechanics
The small invisible details that make a jump feel fair, and how coin placement communicates a level's intended route.
Why some jumps feel right
Three techniques account for most of the difference between a jump that feels responsive and one that feels broken, and all three are invisible.
The first is variable jump height. Releasing the jump button while still rising cuts the upward velocity - typically to somewhere between forty and fifty percent. The effect is that a tap produces a short hop and a hold produces a full jump, which gives the player fine control over a single button. Without it, every jump is the same height and the player is constantly overshooting.
The second is coyote time: a short grace period, usually around a tenth of a second, during which a jump still registers after the player has walked off a ledge. Physically this is nonsense. In practice it converts a whole category of frustrating near-misses into successful jumps, and players never notice it is there.
The third is jump buffering: if the player presses jump slightly before landing, the input is remembered and fires the moment they touch down. The window is typically a little over a tenth of a second. It fixes the equally common failure where an early press is simply discarded.
Coins as a map
In a platformer built around collection, the coins are the clearest communication channel a designer has. A short line on a platform marks a landing spot. A line curving upward marks a route that climbs. An arc over a gap traces the jump that clears it. None of this needs a tutorial, and players read it without consciously noticing.
The corollary is that misleading coin placement is genuinely punishing. A coin placed somewhere unreachable reads as a route the player has failed to find, and they will waste attempts looking for it. A coin placed on a hazard reads as a trap rather than a reward. Good practice is that every coin should be on a route the player can travel, and the arrangement of coins should describe that route.
This is also why the best platformers in this genre offer two visible coin routes - a high one and a low one - rather than one. Two routes turn the coins from instructions into a choice.
Platform types and how they collide
Solid blocks are the simple case: resolve the overlap along the axis of least penetration and stop the player. The standard approach is to move and collide one axis at a time, which avoids a class of bugs where a diagonal move squeezes through a corner.
One-way platforms are harder than they look. The rule is that the platform is only solid when the player is falling and their feet were above the platform surface on the previous frame. Without that previous-position check, a player rising past a platform gets snapped up onto it, which feels like the game grabbing them.
Moving platforms need one specific detail to feel right: the rider should be moved by the platform's position change this frame, not by its velocity. Using velocity accumulates a small error every frame and the player slowly drifts off the platform. Storing the frame delta and adding it to the rider is exact.
Crumbling platforms are a timer attached to a platform. The important part is the warning: the platform should shake harder as the fuse burns down, so the player can see how long they have without any UI. A crumbling platform that gives no visual warning is simply a trap.
Lives, respawns and what a mistake should cost
Platformers in this genre almost always use a life system rather than instant run-ending. The reason is that a platformer asks the player to experiment with routes, and experimentation is only reasonable if failure is cheap.
The design choice worth copying is keeping collected coins and score on a respawn. Losing a life then costs time and position but not progress, which means a player who dies while trying an ambitious route is not punished for having tried. That single rule makes the difference between a game that encourages exploration and one that teaches caution.
Where a game does want caution - a complete-collection requirement, for instance, where the exit will not open until every coin is taken - the correct lever is the objective rather than the respawn penalty. The player still experiments freely; they simply cannot leave until they have covered the map.
Key takeaways
- Variable jump height - holding for a high jump, tapping for a low one - is the single biggest contributor to a jump feeling good.
- Coyote time lets a jump register shortly after walking off a ledge; jump buffering remembers a press made shortly before landing.
- Coin placement is the clearest way to communicate a route without a tutorial.
- One-way platforms need a previous-position check, or the player gets snapped up through them.
- Riders on moving platforms should be moved by the platform's frame delta, not its velocity, to avoid drift.
Frequently asked questions
What is coyote time?
A short grace period after walking off a ledge during which a jump still registers. Typically around a tenth of a second. It converts near-misses into successful jumps and is standard practice.
Why does holding the jump button jump higher?
Variable jump height. Releasing early cuts the upward velocity, giving fine control over jump distance from a single button.
Why do I sometimes land on a platform I was jumping past?
In a well-built game you should not. That is the failure mode one-way platforms have when they do not check the player's previous position, and it is a known bug pattern rather than a design choice.
Do I lose my coins when I lose a life?
On this site, no. Coins already collected stay collected and your score carries over; you simply return to the level start.
A note on terminology. Everything described as a coin, gem or treasure in this article is a virtual in-game collectible used for scoring. Nothing here relates to real-world currency, numismatics, collecting physical coins, or any form of financial value.
Alex Morgan is the editorial persona under which the guides on Coin Collector Arcade are published. Articles are written and reviewed by the team that builds the games on this site, and every mechanical claim is checked against the actual game code. Read more about our editorial team.