Platformer Design

Summary

Platformer design is the practice of building games where jumping is the primary mechanic and skill test. Despite appearing simple, the platformer genre has one of the widest gaps between good and bad design in all of game development (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers). Decisions about jump feel, camera framing, level structure, obstacle sequencing, and difficulty calibration all interact — a change to any one demands a review of the others. This page covers the core design vocabulary and practical considerations for both 2D and 3D platformers, with Unity implementation notes throughout.

---

Key Ideas

Committed vs. Variable Jumping

Committed jumping locks the player’s trajectory the moment they leave the ground. The player has exactly two jumps available: standing and moving. This makes every jump a fixed, predictable arc, turning obstacles into pseudo-puzzles with one correct solution. It is the easier system to implement and to balance, but severely limits design variety. Moving enemies and moving platforms become particularly punishing because the player cannot make corrections (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers).

Variable jumping allows the player to adjust horizontal velocity and jump height mid-air. It enables micro-adjustments — fine, constant corrections to trajectory while airborne — which are the foundation of high-skill platforming. Variable jumping requires more careful tuning to feel right, and players need time to learn the feel, but it is the standard for any platformer where jumping is the core test (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers).

When to use which:

• Committed: retro homages, adventure platformers where jumping is secondary, slower puzzle-focused designs (Prince of Persia, Tomb Raider).
• Variable: any platformer where the challenge is the jumping itself (Super Mario Bros., Celeste, Super Meat Boy).

The Eleven Variables of a Jump

Every jump in every platformer is defined by the following variables (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers). Changing any one has knock-on effects for the entire level design:

Variable	What it controls
Jump Delay	Frames from button press to character leaving ground
Jump Max Height	Maximum altitude reached
Jump Min Height	Shortest possible jump (tap and release)
Jump Cancelling	Can the player cut the ascent short?
Ascending Speed	Rate of rise; slower ascent = more time to react to hazards above
Descending Speed	Rate of fall; affects maximum jump distance
Committed / Variable	Whether air control is permitted
Momentum	Does horizontal velocity carry through into the air?
Horizontal Movement Speed	Air speed; combined with descent speed = jump distance
Additional Jumps	Double jump, triple jump, etc.
Jump Distance	Total horizontal reach; determines safe gap widths

Jump Distance is the master constraint for level design: gaps should be set relative to maximum jump distance, and the closer a gap is to the character’s maximum reach, the harder the jump.

Coyote Time and Jump Buffering

These two techniques are not named in Bycer’s text but are standard practice in modern platformer implementation. Both address the gap between player intention and mechanical response, making jumps feel fair rather than fussy.

Coyote time (also called “late jumping”) grants the player a short window — typically 6–12 frames — after walking off a ledge in which they can still jump, even though they are technically airborne. The name comes from Wile E. Coyote cartoons, where characters hang in the air briefly before falling. Without coyote time, players who move slightly past a ledge before jumping feel cheated; with it, the jump still works and the player does not notice the forgiveness.

Jump buffering (also called “input buffering” or “jump queuing”) records a jump input for a short window — typically 6–10 frames — before the character lands. If the player presses jump slightly early, the jump executes automatically on landing. This prevents the frustration of a missed jump caused by slightly imprecise timing.

Both are standard inclusions in any variable-jumping platformer. They do not change the physics or alter level design requirements; they are purely a quality-of-life layer on top of the base movement system.

2D Camera Design

In 2D platformers the “camera” is the view window over the level. Good practice (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers):

• Keep the character model roughly one quarter of the screen length from the edge toward which they are moving. This maximises the player’s view of incoming obstacles.
• The character should be on the opposite side of the screen from their direction of travel — i.e. moving right means the character is positioned left of centre.
• The same rule applies on the vertical axis when the player is jumping or climbing.
• When the character changes direction, the camera must re-orient its lead direction.

Sonic the Hedgehog is the canonical counter-example: at full speed, Sonic shifts to the centre of the screen, eliminating reaction time for incoming obstacles. Bycer argues the correct fix was to either lock Sonic’s screen position to the quarter-rule or zoom out the camera.

Older games also struggled with blind jumps: sections where the camera pans up with the player’s ascent, removing the view of the landing platform. Collectibles (coins, gems) arranged along the intended path are one solution — they guide the player through the blind section.

3D Camera Design

The 3D camera is a separate, controllable entity — this is the single largest new complication when moving from 2D to 3D platformer design (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers).

Camera systems and their trade-offs:

System	Best for	Limitations
Behind the back	3D traversal, seeing what’s ahead	Gets stuck in walls and large models
Over the shoulder	Aiming, horror games	Poor for all-direction platforming
Isometric / angled	Combat + platforming, full 360° awareness	Cannot show what’s ahead; slower to reposition
Fixed angles	Cinematic moments, specific tricky sections	Can make sections unplayable if angle is wrong

For platforming specifically, the isometric / angled camera is considered the most effective when the character needs to jump in any direction. Many 3D platformers use multiple systems and allow the player to switch.

The shadow rule: In a 3D space the player cannot judge jump depth from the character model alone. A drop shadow projected onto the ground directly below the character is essential — it is the primary visual cue for gauging landing distance. When the shadow is obscured (dark levels, the character is high above a pit), the game must compensate with camera repositioning. Epic Mickey 2 is cited as a case study in how removing the shadow makes 3D platforming sections nearly unplayable.

Control orientation: Input direction should be relative to the camera, not the character’s facing direction. “Left” should move the character to the left of the screen, regardless of which way they are facing. Tank-like controls (relative to the character) are acceptable in survival horror but are not suitable for any game requiring quick jumps.

Obstacle Design

Platformer obstacles fall into two categories: hazards to avoid or defeat, and surfaces to reach by jumping. Three ways to interact with an active hazard: avoid entirely, attack with a weapon, or stomp from above. If some enemies can be stomped and others cannot, the game must make the visual distinction immediately clear (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers).

When designing a jumping obstacle, there are exactly three variables the designer controls (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers):

1. Where the player jumps from — static platform = baseline difficulty; moving platform = additional calculation required.
2. What happens in the air — dodging projectiles, navigating gaps above and below, using a double jump or dash.
3. Where the player must land — size, movement speed, and predictability of the landing surface.

Combining multiple difficult elements across all three produces the hardest challenges in the genre.

Taxonomy of hard jumps (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers):

• Blind jumps — the camera does not show the landing point.
• Character-wide challenges — safe space equals the character’s hitbox width; no room for error.
• Pixel-perfect jumps — gap distance equals maximum jump distance; one valid trajectory.
• Bouncy jumps — launching surface constantly propels upward; player does not control the platform.
• Icy jumps — slippery surfaces prevent momentum control on take-off and landing.
• Moving jumps — landing surface is in motion; player must synchronise timing.
• Trick jumps — a second action must be performed mid-air (dash, attack, item use).
• Aborted jumps — player must deliberately stop horizontal momentum mid-jump to land on a close target.

These jump types are not inherently bad design — they become frustrating only when stacked carelessly or introduced without prior teaching.

Level Flow and Checkpointing

Levels are composed of sections — collections of obstacles the player must clear before reaching safety (a checkpoint). Key principles (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers):

• Difficulty should grow across the level, culminating in the hardest challenge at the end.
• Do not repeat the same obstacle in the same level — this is padding.
• Every level needs a theme: one central mechanic or obstacle type to explore in different ways.
• For any especially technical section, place a checkpoint before and after it. The player should be able to focus on the challenge, not on repeating content they have already completed.
• Stages lasting longer than a few minutes should include at least one checkpoint as a matter of fairness.
• Avoid the “wall” — a point at which a player cannot improve and must stop playing. This is especially important in linear designs where progress cannot be bypassed.

See also level-design for spatial design principles, and interest-curves for the wider difficulty pacing model.

Subjective Difficulty (3D Platformers)

Subjective difficulty is a design property of open 3D levels where the challenge adapts to the player’s skill without the designer explicitly branching the content (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers). A novice completes the level using simple jumps along the obvious path; an expert uses wall jumps, long jumps, and triple jumps to bypass sections and complete it faster. Both paths are valid.

Super Mario Galaxy 2 is the exemplar: novices play through normally; expert-level jumps (long jump, wall jump, triple jump) are available from the first level but are not required until later stages “officially” introduce them. By the end, both player types have converged on the same skill set, and the novice’s growth feels organic rather than forced.

Subjective difficulty stands in direct contrast to mechanical gameplay (Kaizo and its commercial equivalent 1001 Spikes), where there is exactly one correct sequence of inputs and no room for individual expression.

Physics-Driven Platforming

Physics-driven platforming gives the character a minimum and maximum jump, but every intermediate value is calculated live from the character’s velocity and momentum — the jump is not locked to a preset arc. This means near-infinite jump variety, enabling very high-skill challenges, but it also means (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers):

• Levels must be shorter per section, with frequent checkpoints, because the difficulty comes from execution rather than memorisation of a fixed path.
• Enemies and puzzles are typically minimal — the focus is entirely on the movement.
• Camera tracking must keep pace with the character; if the player outpaces the camera, sections become unreadable (a known issue in Dustforce).
• The design space eventually saturates: once the player has mastered the movement system, the designer cannot create new challenges without adding entirely new mechanics.

Sonic the Hedgehog introduced physics-driven movement at the AAA level; the indie era refined it with Celeste, Super Meat Boy, and the N/N++ series.

Teaching the Player

The platformer genre favours organic tutorials — level design that teaches mechanics through play rather than stopping to explain them (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers). Principles:

• Introduce every mechanic in a low-stakes context where failure carries no penalty.
• The more important a mechanic is to the rest of the game, the earlier it should be introduced.
• If a mechanic requires a non-obvious input combination, it must be formally introduced — never assume players will discover it.
• Advanced techniques that are not required for the main path can be withheld until difficulty levels that demand them (as in Celeste’s wall-dash-jump, which is available from level 1 but only formally taught in the B-side stages).

This intersects with smooth-learning-curves and the wider game-loops discussion of player skill growth.

Challenging vs. Frustrating

The defining line is who is responsible for the player’s failure (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers). Challenging design ensures the player fails because of their own choices or skill. Frustrating design introduces failure states outside the player’s control:

• Kaizo traps: invisible obstacles that kill on first encounter with no telegraph.
• Difficulty spikes: sudden jumps in challenge that have not been taught.
• Training the player to do X and then punishing them for doing X.
• Requiring hitbox knowledge — designing sections where the character model appears safe but the hitbox does not connect.

Practical indicators from playtesting: pain points are sections where players repeatedly fail or quit. A checkpoint before and after a pain point, or the addition of a forgiving platform, is often sufficient to resolve them.

Hitboxes and Collision Detection

The hitbox is the invisible volume the game engine uses for collision. For platformers (Bycer, Game Design Deep Dive: Platformers, see source-game-design-deep-dive-platformers):

• The game must constantly check whether the character hitbox is touching a ground surface to determine ground/aerial state.
• If the check frequency is too low, the player can jump slightly after walking off a ledge because the engine still registers them as grounded — this is the technical underpinning of coyote time (whether intentional or exploitable).
• A hitbox that is not well-matched to the character model creates visual confusion: attacks or hazards that appear to miss may still register as hits, and vice versa.
• Any change to a character model’s size must be accompanied by a corresponding hitbox adjustment. The Crash Bandicoot N Sane Trilogy is a well-documented case where a change from a square to a pill-shaped hitbox made previously straightforward jumps significantly harder.

---

In Practice (Unity)

Ground / Aerial State Check

The canonical Unity approach uses Physics2D.OverlapCircle to check for a ground layer:

[SerializeField] private Transform groundCheck;
[SerializeField] private float groundCheckRadius = 0.1f;
[SerializeField] private LayerMask groundLayer;
 
private bool isGrounded;
 
void Update()
{
    isGrounded = Physics2D.OverlapCircle(groundCheck.position, groundCheckRadius, groundLayer);
}

Place the groundCheck transform at the character’s feet. The check runs every frame, keeping the ground/aerial state up to date. This is the direct implementation of the two-state model Bycer describes in Chapter 6.

Coyote Time Implementation

[SerializeField] private float coyoteTime = 0.12f;   // ~7 frames at 60fps
private float coyoteTimeCounter;
 
void Update()
{
    if (isGrounded)
        coyoteTimeCounter = coyoteTime;
    else
        coyoteTimeCounter -= Time.deltaTime;
 
    if (Input.GetButtonDown("Jump") && coyoteTimeCounter > 0f)
    {
        Jump();
        coyoteTimeCounter = 0f;   // consume the window
    }
}

The window resets on every grounded frame. Walking off an edge sets the countdown; any jump input within the window is accepted.

Jump Buffering Implementation

[SerializeField] private float jumpBufferTime = 0.1f;   // ~6 frames at 60fps
private float jumpBufferCounter;
 
void Update()
{
    if (Input.GetButtonDown("Jump"))
        jumpBufferCounter = jumpBufferTime;
    else
        jumpBufferCounter -= Time.deltaTime;
 
    if (jumpBufferCounter > 0f && isGrounded)
    {
        Jump();
        jumpBufferCounter = 0f;
    }
}

Combine both systems: a jump queued during the buffer window that lands within coyote time will execute correctly.

Variable Jump Height (Jump Cancelling)

Allow the player to cut the jump short by releasing the button early. This implements Jump Min/Max Height and Jump Cancelling from the variable list:

[SerializeField] private float jumpForce = 12f;
[SerializeField] private float jumpCutMultiplier = 0.4f;   // cuts vertical velocity on release
 
private Rigidbody2D rb;
 
void Update()
{
    if (Input.GetButtonUp("Jump") && rb.velocity.y > 0f)
    {
        rb.velocity = new Vector2(rb.velocity.x, rb.velocity.y * jumpCutMultiplier);
    }
}
 
private void Jump()
{
    rb.velocity = new Vector2(rb.velocity.x, jumpForce);
}

Tap → low jump (button released quickly, velocity cut). Hold → high jump (velocity not cut until apex).

Faster Fall (Descending Speed Tuning)

A common polish technique is to apply extra gravity during the fall phase, making jumps feel snappier and more controllable:

[SerializeField] private float fallMultiplier = 2.5f;
[SerializeField] private float lowJumpMultiplier = 2f;
 
void Update()
{
    if (rb.velocity.y < 0f)
    {
        // Falling — apply extra gravity
        rb.velocity += Vector2.up * Physics2D.gravity.y * (fallMultiplier - 1) * Time.deltaTime;
    }
    else if (rb.velocity.y > 0f && !Input.GetButton("Jump"))
    {
        // Rising but button released — low jump arc
        rb.velocity += Vector2.up * Physics2D.gravity.y * (lowJumpMultiplier - 1) * Time.deltaTime;
    }
}

This is a direct implementation of Bycer’s Ascending Speed / Descending Speed variables as per-phase gravity multipliers.

Camera Lead (Cinemachine)

Unity’s Cinemachine Virtual Camera supports a “Dead Zone” and “Screen X” offset that implements the quarter-rule described by Bycer. In the CinemachineVirtualCamera component (see cinemachine-overview):

• Set Follow to the player transform.
• In the Body section (Framing Transposer), set Screen X to approximately 0.3 (placing the character 30% from the left when moving right) and implement a script that flips Screen X to 0.7 when the character changes direction.
• Adjust Dead Zone Width to prevent jitter on small movements.

For more advanced lead-ahead cameras, use a “look-ahead” target that sits ahead of the player in their direction of travel, and point the virtual camera at that target rather than the player directly.

---

Evidence

Bycer’s central claim is that jumping “is a mechanic that looks very simple to design” but “there is a lot that goes into making the mechanic feel right in the player’s hands” (Foreword). He supports this through a combination of historical analysis — tracing committed jumping from Donkey Kong (1981) through variable jumping in Super Mario Bros. (1985) and Sonic (1991) — and direct design taxonomy (the eleven variables, the hard-jump types, the level design principles).

On level design, Bycer is emphatic that organic teaching through level design outperforms explicit tutorials: “Regardless of your game, just about every platformer I’ve ever played starts with the player simply trying to jump over an obstacle. Ideally, there will be no penalty for failure.” (Ch. 7)

On accessibility, he uses Celeste as the exemplar: “The important element of Celeste in terms of difficulty balance was that the accessibility options were not factored into the design of the stages. Celeste was balanced around expert players, but became open for anyone to enjoy.” (Ch. 14) This aligns with the wider accessibility principle that difficulty modifiers should be a layer outside the core design, not built into it.

On hitboxes, the Crash N Sane Trilogy case study demonstrates that a change to hitbox geometry in a remake can render previously trivial sections nearly impossible — evidence that hitbox shape is as consequential as any explicit design decision.

---

Implications

• For designers: The jump feel is not an afterthought — it is the product of eleven interdependent variables. Fix these values early and design all levels around them. Any change to jump parameters after levels are built may require redesigning every gap in the game.
• For designers: Always include coyote time and jump buffering as standard. They do not change the difficulty of well-designed jumps; they remove the friction of technical imprecision that makes easy jumps feel unfair.
• For designers: Match checkpointing density to your design’s difficulty philosophy. A hardcore physics-driven platformer needs a checkpoint per room; a light adventure platformer can space them further apart.
• For designers: If your game tests jumping, use variable jumping. If jumping is incidental (exploration in an action-adventure), consider auto-jumping.
• For designers: Playtest specifically to identify pain points — sections where players fail repeatedly. Pain points are often fixable by a single additional platform or a checkpoint, not a full redesign.
• For lecturers: The two-state (ground/aerial) model in Chapter 6 is an excellent entry point for teaching state machines in Unity. The progression from two states to coyote time buffering naturally introduces the concept of state timers.
• For Unity developers: Cinemachine’s dead zone and screen offset tools directly implement Bycer’s camera quarter-rule. Teaching both together connects design theory to engine practice.

---

Open Questions

• Coyote time and jump buffering are not discussed in Bycer’s text under those names. Are there design contexts where they should be disabled or shortened (e.g., very precision-focused Kaizo-style games where lenient input windows undermine the intended difficulty)?
• Momentum carry in variable jumping: Bycer notes that momentum in the air is realistic but increases difficulty — how do games like Celeste manage to make momentum feel good rather than punishing? (Arguably the dash mechanic resets momentum explicitly, giving the player full control over when to carry and when to reset.)
• The wall: Bycer identifies the problem of players hitting an impassable skill ceiling but offers only accessibility options and organic teaching as mitigations. Is there a structural design approach — beyond optional assist modes — that prevents the wall without compromising the game’s integrity?
• 3D platformer revival: Bycer writes in 2019 that AAA 3D platformers have largely disappeared. Does the 2023–2024 period (Astro Bot, Super Mario Bros. Wonder, Prince of Persia: The Lost Crown) suggest a return, and if so, what changed?

---

Related

• game-feel — The tactile sensation of jumping; how polish techniques (coyote time, screen shake, squash-and-stretch) affect perceived responsiveness
• level-design — Spatial layout, visual guidance, and readability principles that apply across all genres
• game-loops — Jumping as the core loop; how the primary mechanic defines the entire design
• challenge-types — Taxonomy of difficulty; where platformer hard-jump types fit the broader model
• interest-curves — Pacing difficulty across a stage and across a game
• smooth-learning-curves — Teaching mechanics through organic level design
• game-balance — Difficulty calibration, subjective difficulty, and accessibility options
• systems-thinking — How the eleven jump variables form an interdependent system
• cinemachine-overview — Unity’s package workflow for dead zones, follow framing, and camera lead
• source-game-design-deep-dive-platformers — Primary source for this page