← Lab notebook

Learning to Make a 2D Platformer: Where I Started

9 min read

I wanted to understand how to get started making a 2D platformer, but first I needed a clearer picture of its parts. At its simplest, a 2D platformer asks a player to move across platforms and obstacles in a two-dimensional space. That does not mean every game must side-scroll or follow one formula. The useful discovery was that choosing a kind of experience, then considering movement, camera, level teaching, and retry together, made the starting point more concrete.

An earlier article about questions of flow, information, and response gave me useful language for this study. It is not required reading, and I did not need to turn those questions into a long checklist. I needed a small set of connected decisions that could guide a first experiment.

AI and automation helped research, illustrate, translate, and review this article. I own AI Maker Lab and take responsibility for the final wording and source checks.

There is more than one kind of platformer

Choosing the experience comes before choosing physics parameters. A familiar action such as jumping can support very different things a player enjoys or works at. One game may focus on repeating a difficult sequence. Another may make movement part of a puzzle or a journey through a connected world.

I used six shapes to make that range easier to see:

  • Precision: repeatable movement and timing, as in Celeste.
  • Puzzle: solving a spatial or systemic problem, as in Braid.
  • Cinematic: animation, staging, and authored sequences, as in Inside.
  • Metroidvania: exploration reopened by new abilities, as in Hollow Knight.
  • Roguelite hybrid: repeated runs with changing conditions or resources, as in Dead Cells.
  • Runner: forward motion and anticipation, as in Canabalt.

This is a useful personal map, not an official or exhaustive classification. The categories overlap, and the examples only provide orientation. Its practical value is restraint: a first project can choose one main kind of experience instead of combining every feature.

That choice leads to four connected questions. How should movement respond? What must the camera show? How can the level introduce its rules? What happens after failure, and how does retry begin? I found it more useful to treat these as an iteration loop than as a chain controlled by any single mechanic.

Movement, camera, level teaching, and failure or retry connect in a loop where each decision can prompt another revision.
The starting point became clearer when four design questions could be considered together and revisited.

Movement has to respond to the player

Movement is one foundation of the experience, not the thesis of the whole game. Steve Swink’s publisher describes Game Feel through sensation and control. In ordinary terms, I use it for how an action feels and how clearly the game responds to an input.

A jump is easier to describe through a desired height, distance, and duration than through an unexplained gravity number. Kyle Pittman’s “Building A Better Jump” starts from those readable targets. It also presents variable jump height and a quicker fall after the peak as options. They are possibilities, not techniques every platformer needs.

Maddy Thorson’s “Celeste & Forgiveness” gave me three compact examples of responses near timing boundaries:

  • Coyote time is a short interval when a player can still jump after leaving a ledge.
  • Jump buffering records a jump held shortly before landing and fires it on the landing frame.
  • Holding jump at the apex applies half gravity at the top in Celeste, leaving more time to adjust for landing.

These choices acknowledge an intended action that arrives close to a boundary. They do not guarantee that a movement system will feel effective, and their exact settings still belong to the project.

A jump arc shows height and distance alongside short input windows near a ledge, landing, and the top of the jump.
Describing the visible arc and its input boundaries gives movement a response to aim for before it has numbers.

Air control adds one plain question: how much sideways correction should remain after takeoff? One project may allow only a little, while another lets the player steer strongly. Describing the intended response first gives later numbers a purpose instead of asking the numbers to define the experience.

The camera shows what a player needs next

A landing surface or obstacle must be visible before the player commits to it. The camera therefore communicates decisions; it does more than follow a sprite. Its frame can show a destination, preserve a stable view, or move ahead along the route.

Itay Keren’s analysis of side-scroller cameras describes a bounded camera window. The player has room to move inside that window before scrolling begins. In the cited Rastan example, the vertical window is one standard jump high. That measurement belongs to Rastan, not to every platformer.

Keren also describes contrasting choices. Fez uses smoothing on a vertically locked camera, meaning that the camera moves gradually rather than changing position at once. Super Mario World can hold the camera still through a jump and snap it when the player lands. Neither response is a universal prescription.

A bounded camera window gives the player room to move before scrolling and keeps the next landing area within view.
A useful first frame shows the destination while avoiding camera movement that does not help the decision.

The concrete starting question is simple: can the player see the destination without unnecessary camera motion? Looking ahead along the route is another framing choice to consider. Both questions keep the camera focused on what the player needs next rather than on a formula for following position.

A level can teach one idea at a time

A first level can introduce an action instead of merely adding harder obstacles. Timothy J. Seppala’s Engadget report about Super Mario 3D World describes a four-part teaching sequence. It comes from a 3D Mario game, but it offers a useful way to think about the first level of a 2D project.

  1. Safe introduction: present one idea where experimentation has little cost.
  2. Development: repeat the idea with a changed position, rhythm, or consequence.
  3. Twist: alter the situation so the first solution needs adjustment.
  4. Conclusion or retirement: ask for a clear use, then move on from the idea.

For a hypothetical beginner level, the idea could be one small obstacle. The safe introduction places it on flat ground. Development changes the approach, the twist places it before a landing, and the conclusion uses it once in a short route. This is an example, not a room I built or tested in Skyline Run.

Four connected spaces introduce one action safely, develop it, add a twist, and then conclude or retire the lesson.
Keeping the first lesson small makes each change easier to connect to the same idea.

This sequence helps distinguish a hard action from a rule the level never explained. A useful next step is to watch where a player notices the idea and whether the twist remains understandable.

Historical sales milestones showed that very different platformers reached large audiences. The figures below use different dates and reporting boundaries, so they show reach rather than a ranking, market total, forecast, or proof that particular mechanics caused sales.

These examples helped me understand the range of the field. They could not choose the first project’s controls or scope. That practical distinction kept market context useful without turning it into design instruction.

A first project needs a small, complete loop

A manageable starting workflow emerged from the study:

  1. Choose one player activity and a clear goal for a small level. This gives the first experiment one experience to serve.
  2. Make the basic movement and contact rules work in a safe space. The player should be able to learn the core action without extra pressure.
  3. Show what matters through the camera, status, and useful responses. Information should support the next decision.
  4. Connect the beginning, a short lesson, failure, retry, and finish. A complete loop reveals gaps that an isolated movement demo cannot.
  5. Watch someone try that small loop, then revise before adding more. Observation comes before expanding the feature list.

The shorter workflow still contains practical decisions. Movement advances over time, while contact rules distinguish ground, hazards, and goals. Controls need meanings for press, hold, release, and pause. The project must decide when control stops and what retry preserves. For example, a simple rule can say whether failure returns the player to the level entrance or a checkpoint.

The screen also needs an understandable flow. Some states may need an overlay, while others may deserve a separate screen. The destination should remain visible when the player must commit. Landing, failure, and retry need clear responses before extra sound, particles, or camera effects. Those choices matter, but they do not need an inventory of every possible state or contact case.

Scope depends on the experience chosen earlier. Precision timing and changing run conditions serve different kinds of play. Adjustable challenge and sharing courses are possibilities to consider, not requirements for a first build. Nintendo’s Super Mario Maker 2 page provides one concrete model: players can create and share courses, and Switch Online members can upload them. It does not establish a growth trend or product demand.

Advanced abilities, enemies, persistence, and creator tools can stay outside the first small experiment. This order is a useful starting point from my study, not the correct workflow for every platformer. The next step is to observe that small loop and revise it before expanding the feature list.

The study gave me somewhere to begin

The study turned a broad ambition into a few connected questions. What kind of experience am I trying to make? How should movement respond? What needs to be visible? How will the level teach its first idea, and how will failure lead into retry? Those questions gave me somewhere practical to begin without making one mechanic carry the whole design.

Update (2026-08-30): The small version became Skyline Run, which you can try here. Its local campaign contained ten districts at that time.

For a focused follow-up, read what happened when jump and level choices met measurement. That deeper technical account is optional; the useful result here is the smaller, connected starting point.

Sources

Keep reading