[KongchangAI]
· 4 min read· 2,019 words

AI Game Development in Practice: Designing Levels with the Four-Step Method and Pacing Curves

AI Game Development in Practice: Designing Levels with the Four-Step Method and Pacing Curves

Design level difficulty with data: the four-step method, pacing curves, and moving platforms, with AI self-checking against feel constraints.

Based on lesson 10 of Bilibili's "AI Game Development in Practice," this article tackles the difficulty cliff where the author's playtest feels fine but players die constantly, proposing to design levels with data rather than feelings. It covers the four-step level design method (teach, practice, combine, test), four pacing curve rules (alternate tension and relaxation, rise overall, new mechanics in valleys, checkpoints before peaks), sightline guidance and safety zones, and implementing moving platforms with Animatable Body 2D plus physics-frame tweens. It also breaks down the ASCII sketches for 1-2 and 1-3 and points out the typical AI-drafted level failure—all peaks with no valleys, and pits wider than the ~3.5-tile jump ability—requiring feel constraints in prompts and AI self-checks. Finally, it gives the practical workflow and acceptance criteria.

Why Your Levels Always "Look Great but Play Like Hell"

Many indie developers and AI-assisted developers run into the same dilemma: when they playtest their own levels, the design feels solid, but the moment players get their hands on it, they die constantly—sometimes getting stuck in the same spot and dying over and over. In lesson 10 of "AI Game Development in Practice," the Bilibili creator presents a typical case: in the first playtest of level 1-2 Underground Cavern, 16 out of 20 deaths came from falling into the same pit—80%. This kind of difficulty cliff is nearly impossible to spot through the author's own playtesting, because you know the level too well—you know exactly where to jump and where to stop.

The core idea of this lesson is: design difficulty with data, not with feelings. Specifically, master four level design tools first, build moving platforms and level switching, then use a death heatmap to find and smooth out difficulty cliffs. This article focuses on the first part: level pacing design, the four-step method, three-level ASCII sketches, and moving platform implementation.

The Four-Step Level Design Method: Let Players Learn Without a Manual

Every new mechanic should go through the complete cycle of teach, practice, combine, test. The creator draws an analogy to learning to ride a bike: first walk it along in an open lot, then ride a few laps yourself, then take a small path with slopes and turns, and finally ride to school.

Using the spike mechanic as an example:

  • Teach: In level 1-1, columns 44 and 45, two isolated spike tiles on flat ground, with coins above guiding you to jump over—extremely low risk.
  • Practice: In level 1-2, columns 84 to 88, climbing one-way platforms with spikes below, repeated a few times with slight variations.
  • Combine: In section F of 1-2, moving platforms plus a bottomless pit, with bats above the pit—two threats appearing at once.
  • Test: In phase two of the BOSS fight in 1-3, falling rocks, shockwaves, and lasers all at once—but always placed after a checkpoint.

The value of this four-step method is that it breaks "difficulty" down into an actionable sequence. The most common mistake AI makes when generating levels is skipping teach and practice and throwing players straight into combine and test phases.

Pacing Curve: Turning Level Tension into Quantifiable Numbers

Divide a level into segments and rate each segment's tension from 1 to 5, then connect them to see the rises and falls. Take the nine segments of 1-1: it starts with a safety zone at 1, then pit jumps, slimes, and spikes at 2 each, and later combinations and tests reaching 4.

The creator gives four rules:

Rule 1: Alternate tension and relaxation. Place a valley after every peak. After the two 4-point segments G and H in 1-1, segment I is the coins and flag before the goal, back to 1.

Rule 2: Rise overall. Each level's peak should be a little higher than the previous one. 1-1 peaks at 4, 1-2 peaks at 5, 1-3 also at 5, and the BOSS's second phase goes even higher.

Rising overall—each level's peak is a little higher than the last

Rule 3: New mechanics appear in valleys. The first time one-way platforms appear, tension is only 1, with safe ground below, giving players plenty of room to get familiar with the controls.

Rule 4: Place checkpoints before peaks. The checkpoint in section F sits right before the two peaks G and H, so failure doesn't mean replaying a long boring stretch.

These four rules are essentially a constraint system that can be written directly into AI prompts, letting the AI self-check whether its output satisfies them.

Sightline Guidance and Safety Zones: Let Players Naturally Know Where to Go

Players naturally look at things that are bright, moving, high-contrast, or regularly arranged. The most common tool is a coin trail—an arc of coins above a pit means "jump here." The creator shows a two-tile-wide pit in 1-1 at columns 20 to 25, where the knight jumps along the coins, collects all four, and lands exactly on the other side. The trajectory is calculated frame by frame using the feel parameters from lesson 6, so whether the coins are placed correctly can be verified.

Other guidance tools include: checkpoint stones lighting up with blue fire (light source), dimming the background by one level (brightness contrast), moving platforms and fluttering goal flags (motion), ascending platforms pointing toward the exit (terrain shape), and camera look-ahead so players see threats ahead.

Safety zones are another easily overlooked design element: a stretch with no enemies, no traps, and flat ground—at least 6 tiles is recommended. Four locations must have safety zones—the start of the level, each checkpoint, before the BOSS fight, and the end of the level. The entrance of 1-3 is a checkpoint plus a healing heart, with flat ground before and after, serving as a supply station before the BOSS.

Collectibles include coins and healing hearts, used for sightline guidance and rewarding exploration

Moving Platforms: Solving the Stubborn "Can't Stand Still" Problem with Animatable Body 2D

Moving platforms are the new content in this lesson. A common failure scenario goes like this: you change the platform's position directly in the per-frame processing function. The platform moves, but the character standing on it doesn't inherit the platform's movement, gets left behind, and slides off as soon as the platform moves on.

The correct approach is to use Animatable Body 2D with a tween animation running on physics frames. Animatable Body 2D is an object that moves on its own but isn't affected by gravity or pushed by collisions; once synced to physics, characters standing on it move along with it. The AI-generated reference implementation has three key exported parameters: round-trip displacement of 96 pixels (about 6 tiles), 2 seconds one way, and a 0.5-second pause at each end. The two moving platforms in 1-2 are made by changing just these three numbers. The most critical line sets the tween's process mode to physics, syncing with physics frames so the character stands steadily. Then use sine easing so the platform starts and stops smoothly.

Moving platforms first appear in section D, carrying you up to a 6-tile-high stone platform—falling just drops you back to safe ground

Physics frames and process mode: In Godot, physics simulation runs at a fixed frequency (60Hz by default) in physics frames, decoupled from render frames. If you move a platform in _process (render frames), the physics engine cannot correctly calculate the relative velocity between the character and the platform, and the character gets "thrown" off by friction and inertia. When the tween's process mode is set to Physics, the Tween binds to the physics frame callback, so every step of the platform's movement is synced with the physics world, and the character automatically inherits the platform's velocity through CharacterBody2D's move_and_slide, standing stably. This is also why moving platforms must use AnimatableBody2D rather than a regular StaticBody2D: the former reports its own motion to the physics engine, while the latter is stationary by default.

Three-Level ASCII Sketches: Breaking Down the Structure of 1-2 and 1-3

The map legend adds four new characters to lesson 8: M is a moving platform (adjacent Ms merge into one), H is a healing heart, D is the BOSS door (vertically adjacent Ds merge into one door), and G is the BOSS.

1-2 Underground Cavern has 100 columns and 14 rows, 44 pixels taller than the screen, with the camera moving up and down. Section A is the entrance safety zone; section B has the ceiling pressed down to only 4 tiles high for fighting slimes in a confined space; section C teaches you to dodge arrows with a skeleton archer on a high platform behind a cover pillar; section D introduces the first moving platform carrying you up to a 6-tile-high stone platform (low-risk teaching); section F is the level's highest 5-point peak—moving platforms crossing a bottomless pit with bats above and slimes on the landing, with the second checkpoint at column 78. Section G is climbing one-way platforms above spikes; section H gives a healing heart first, then faces high-platform archers before reaching the goal.

1-3 Guard Hall has 52 columns and is the BOSS level. Section A is the entrance and coin buffer; section B is a checkpoint plus healing heart as the pre-BOSS safety zone; section D's corridor uses falling dust from the ceiling, low rumbling, and sound effects to build anticipation; the arena interior is exactly 20 tiles wide—one flat screen width—with low platforms on the left and right and a high platform in the middle for dodging shockwaves, falling rocks, and lasers. After the player crosses column 32 into the trigger zone, the door closes, the camera locks between 496 and 816 pixels, the BOSS awakens with two seconds of invincibility, and the health bar appears.

Crash Site: Why AI-Drafted Levels Can't Be Used Directly

If you let AI draft levels directly, a common result is every segment packed with enemies—spikes next to slimes, bats in a row—with the pacing curve at 4 or 5 from beginning to end and not a single valley. Worse, the AI will design 5-tile-wide pits—when the measured jump distance is only about 3.5 tiles, so no one can make it. It looks fine, because the AI doesn't know your feel data.

The fix is to state the feel constraints in the prompt—56 pixels, about 3.5 tiles—have the AI self-check every pit width and step height, and require it to output a pacing table first to check that every peak has a valley after it. The creator's practical prompt also constrains the AI not to modify files directly but to wait for your choice—because whether a level is fun must ultimately be judged by a human.

Have the AI output a table by segment and check four things

Feel parameters and jump constraints: A platformer's "feel" is usually defined by a set of physics parameters, such as gravity acceleration, jump initial velocity, horizontal movement speed, and air control coefficient. From these parameters you can derive the character's maximum horizontal jump distance and vertical height. The "56 pixels, about 3.5 tiles" mentioned in the article refers to the maximum number of horizontal tiles the character can cross from takeoff to landing back at the same height under the given parameters. If AI doesn't know these values when generating levels, it will design physically unreachable pit widths or step heights. Therefore these constraints must be explicitly stated in the prompt, and the AI must be required to self-check reachability for every pit width and step height—otherwise the level "looks reasonable" but "plays like hell."

Practical Workflow and Acceptance Criteria

Three steps: First, have the AI analyze 1-1's pacing and give revision suggestions (no more than three, each with before-and-after snippets). Second, implement mechanisms and level switching—check one-way collision on moving platforms, make healing hearts not collectible at full health, provide a method to toggle the BOSS door, add level numbers and next-level paths to level scripts, and when touching the goal flag, print a completion log first before delaying the scene switch. Third, generate 1-2 and 1-3 map files by extending the generation script from lesson 8—adjacent Ms merge into platforms, vertical Ds merge into doors—and for 1-3 additionally generate the arena trigger zone and camera boundaries.

The acceptance criteria are very specific: first check the completion log (level number, time, death count, coins collected and total), then confirm one by one that 1-1 switches to 1-2, that standing on platforms doesn't slide or jitter, that healing hearts don't disappear at full health, that the door can be toggled, and that there are no physics callback errors. Finally, enable collision shape display and run through the whole level, focusing on the platform teaching in section D and the bottomless pit combination in section F.

The next episode will build the two-phase BOSS "The Guardian of Truth" and use death heatmaps to verify the difficulty cliff fixes.

#AI game development#level design#four-step method#pacing curve#Animatable Body 2D#moving platforms#Godot
Share:

Related articles