← Lab notebook

Before I Built a Platformer: What I Studied and What I Kept

8 min read

What I studied before building Skyline Run — six kinds of platformer, the jump, the camera, the first level — what I chose once the game existed, and what the AI agents that built it got wrong.

The first level of my platformer had a gap that was supposed to teach the dash. When I measured it, a plain jump could clear it.

That came later. Before I built Skyline Run, I didn't know what a platformer is made of. So I studied it: what kinds exist, how a jump should feel, what the camera owes the player, and how a first level teaches. This post is that research, plus what I chose once the game existed, how a team of AI agents built it, and where the research ran out.

Skyline Run's white player character crosses a six-tile rooftop gap with a cyan air-dash trail while measured jump and level values frame the scene.
Skyline Run today: a six-tile rooftop gap that finally needs the dash.

Just want to play? Play Skyline Run. You don't need to read this first.

The short version

Here's the order I'd give anyone starting a small platformer. It builds on the three questions from my tic-tac-toe post.

  1. Pick one kind of platformer and write the goal in one sentence.
  2. Describe the jump you want (height, distance, forgiveness) before choosing numbers.
  3. Make sure the camera shows where you'll land before you jump.
  4. Teach one idea at a time, then connect start, lesson, failure, retry and finish.
  5. Measure it, watch someone play it, and fix what gets in the way before adding more.

Pick one kind of platformer first

Jumping can serve very different games. I used six shapes to see the range. They overlap, and the examples are just landmarks.

  • 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, as in Dead Cells.
  • Runner: forward motion and anticipation, as in Canabalt.

The point is restraint: a first project picks one and leaves the rest.

In Skyline Run: precision. The whole game in one sentence: reach the rooftop exit of one neon district by running, jumping and dashing; a hazard or a fall sends you back to the latest checkpoint.

That choice raises four questions that keep feeding each other: how movement responds, what the camera shows, how a level teaches, and what happens after failure.

Movement, camera, level teaching, and failure or retry connect in a loop where each decision can prompt another revision.
Four questions, answered together and revisited.

Describe the jump before you pick numbers

Steve Swink's Game Feel is about how an action feels and how clearly the game answers an input. Kyle Pittman's GDC talk "Building A Better Jump" made that practical for me: start from the height, distance and time you want, not from a gravity number. He also shows variable jump height and a faster fall after the peak.

Maddy Thorson's "Celeste & Forgiveness" gave me three small tricks for inputs that arrive a moment too early or too late:

  • Coyote time: you can still jump for a moment after running off a ledge.
  • Jump buffering: a jump pressed just before landing fires on the landing frame.
  • Apex hang: in Celeste, holding jump halves gravity at the top, giving you time to line up the landing.
A jump arc shows height and distance alongside short input windows near a ledge, landing, and the top of the jump.
Describe the arc and its forgiveness windows first; numbers come second.

In Skyline Run: a full jump rises 56 px, three and a half tiles, and peaks on tick 14 of a 60 Hz game. A one-tick tap gives a 16.56 px hop, about one tile. Coyote time and the jump buffer each allow 5 ticks, about 83 ms. Gravity halves near the top while you hold jump, and falling gravity is 25% stronger than rising gravity.

Show the landing before the jump

You can't commit to a jump if you can't see where it ends. The camera's job is to show the next decision, not just follow the character.

Itay Keren's analysis of side-scroller cameras describes a camera window: the player moves freely inside it before the view scrolls. In Rastan, the vertical window is one jump high. Fez smooths a vertically locked camera, while Super Mario World can hold still through a jump and snap into place on landing.

A bounded camera window gives the player room to move before scrolling and keeps the next landing area within view.
A good first frame shows the destination without moving for no reason.

In Skyline Run: the camera looks 24 px ahead in the direction you face. Its upward window is 72 px, more than a full 56 px jump, and its downward window is 40 px, with smoothing on both axes.

Teach one idea at a time

Timothy J. Seppala's Engadget piece on Super Mario 3D World describes a four-step lesson. It comes from a 3D game, but the shape works for a first 2D level:

  1. Introduce one idea where mistakes are cheap.
  2. Develop it with a new position, rhythm or consequence.
  3. Twist it so the first solution needs adjusting.
  4. Conclude with one clear use, then move on.
Four connected spaces introduce one action safely, develop it, add a twist, and then conclude or retire the lesson.
One idea, four beats.

In Skyline Run: this is where the research held and my numbers didn't. District one's teaching gap was 5 tiles wide, meant to say "you need the dash here." Measured in the engine, a plain jump could clear it. The fix was a 6-tile gap over a recessed floor: a jump alone drops you into the pit, where you can walk back and try again, and only a jump plus an air dash reaches the far roof. At the next gap, two forgiving platforms had formed a staircase that let you skip the dash entirely; they became a single recovery platform that can't become a shortcut. The full story is in The jump that measurement corrected.

The teaching gap, rendered frame by frame from the game's own engine. First the recorded winning input with the dash removed: the jump falls short into the pit. Then the real run: jump, dash, clear.
A measured diagram contrasts the accidental five-tile teaching gap with the corrected six-tile gap and highlights the one-tick boundary that made the old gate unreliable.
The lesson was right. The gap width wasn't.

Make failure cheap

A platformer is mostly failing and trying again, so the moment after a mistake is part of the design. Decide when control stops, where the player comes back, and what a retry keeps.

In Skyline Run: a fall or a hazard locks input for 18 ticks, 0.3 s, then respawns you at the latest checkpoint. A retry keeps your time, your deaths and your checkpoint.

How AI agents built it, and what they got wrong

I didn't write Skyline Run's code by hand. On August 19 I pointed Claude Fable 5 at my research notes and asked for a detailed implementation plan. It wrote one: engine constants, four rooms, and a teaching room with "one 5-tile gap (jump-uncrossable)."

A Claude Opus 5 agent then ran the build as an orchestrator. It sent the work out in waves: GPT-5.6 worker agents wrote the engine, the level and the page in parallel, and separate QA and review agents checked what they produced. The plan put it simply: implementers, QA and evaluators stay separate, and QA owns the verdict. The first playable version landed that evening, in about two hours.

The mistake is the one this post keeps circling. The orchestrator retuned the plan's numbers and handed the workers a table titled "Measured ability envelope — authoritative for level authoring and tests." Its jump row said a jump crosses 4 tiles and "5 is impossible." Nothing had been measured in the real engine yet. A worker wrote that claim into a test, and the QA agent ran it. It failed: a jump could clear the 5-tile gap.

The orchestrator's own diagnosis was that the gap was a knife-edge a frame-perfect coyote jump could cross. The player stays grounded while the left edge of its 12 px-wide box is still over the roof, so the real takeoff point was 12 px later than it had modelled. That same evening it declared the level "not completable" when its own reach table was wrong, and a review agent found that holding Shift while pressing a letter key could leave you unable to jump for the rest of the run.

What I kept from this: an agent calling a number "measured" is a claim, not a measurement. What caught it was a separate agent running the claim against the real engine. That's why the level has a pinned test now: a recorded 1,304-tick winning run that must clear district one with zero deaths every time.

What I left out

The first version was one district in four rooms: running, jumping, an air dash, five checkpoints, keyboard and on-screen touch controls, and graybox art. A recorded replay clears it in 21.7 seconds with zero deaths. By August 30 the campaign had grown to ten districts.

Everything else waited: other movement abilities, enemies, combat, items, sound, real art, gamepad support, saving, a level editor and difficulty settings. None of it is hiding behind the finish screen.

Where the research ran out

Reading gave me the right questions. It couldn't give me numbers that were true for my game; only measuring the running engine did that. And I still haven't watched anyone play it uncoached, so I don't yet know whether a person reads the dash lesson.

What happened next: I measured the jump, then turned the game into a training ground and asked whether a neural network could learn to run the rooftops. It memorized one district instead.

You can help: play district one, then tell me where you fell first and whether you noticed the dash lesson. A DM or a comment on @ai.maker.lab on Instagram reaches me.

AI and automation helped research, illustrate, translate and review this article, and AI agents built the game it describes. I own AI Maker Lab and Skyline Run and take responsibility for the final wording and source checks.

Sources

Keep reading