How to make a good platforming character (Developing 6)

After the first minimum viable version of the magnet game, one piece of feedback stood above everything else: the character did not feel good enough.

The little robot felt slow and floaty. Landing had an annoying hitch. The jump was too large. Throwing the magnet asked too much of the player. So the next task was not adding more levels or mechanics. It was rebuilding the character.

Before opening a new project, four goals shaped the work. First, movement around the environment needed to feel genuinely good. Second, aiming and throwing the magnet had to be simplified down to one button. Third, both the robot and the magnet needed more charm and personality. Fourth, accessibility options needed to be added while the code was still early enough to change.

The first practical step was finding a compact character controller to use as a foundation. There are many good ones available, including controllers built for snappy platformers and controllers inspired by Celeste. The useful choice here was a small controller with only the basics: a box that moves around and a few numbers to tune.

That simplicity mattered. It made the controller easier to understand, easier to change, and easier to shape around the game instead of inheriting a large system full of assumptions.

For movement, the important variables were acceleration and top speed. Tuning those values let the character start moving almost immediately, creating a fast, responsive feel.

For jumping, the key was using two kinds of gravity. The upward arc can be a little lighter and floatier, while the fall can use much heavier gravity that snaps the character back toward the ground. That split makes the jump feel springy without making the whole character feel weightless.

A lot of the work was simply changing numbers, testing, changing them again, and moving through a blocky test environment until the basics felt right.

Once the basics worked, the controller needed the small bits of forgiveness that make platforming feel polished.

The first is jump buffering. A strict jump check asks whether the player is on the ground at the exact frame they press the button. If the player presses jump a split second before landing, the input is ignored, even though the intention is obvious. A jump buffer stores the request for a few frames, then performs the jump if the character touches the ground during that window.

The second is coyote time, which solves the opposite problem. If the player presses jump just after leaving a ledge, a strict controller says no because the character is no longer grounded. Coyote time remembers that the character was on solid ground a few frames ago and still allows the jump.

Both systems are tiny acts of mercy. They do not make the game play itself. They make the controller respect what the player clearly meant to do.

Variable jump height is just as important. Hold the button for a larger leap or release it quickly for a short hop. The implementation can be simple: when the player lets go of jump, apply the heavier downward gravity immediately.

Finally, the character's collider changed from a box to a capsule. That small switch stopped the robot from snagging on edges or bonking awkwardly into platforms, because rounded corners slide across geometry more gracefully.

At this point, the character already felt much better than the prototype. But the same movement can feel even stronger with presentation around it.

Dust particles on running, jumping, and landing make motion visible. A slight tilt while running gives the character momentum. New pixel art made the robot cuter and more cartoony while keeping the same basic identity: an orange robot with a single wheel and a screen face.

Animation needed to support responsiveness, not fight it. In traditional animation, anticipation helps sell an action. In a responsive platformer, too much anticipation can make the controls feel delayed. When the player hits jump, the robot needs to move immediately, so the screen pops up first and the wheel follows a fraction later.

Animations also need to interrupt one another quickly. If the player changes direction or starts another action, the character should react at once. That is not a rule for every game, but it is the right choice for a precise platformer.

Once the robot worked on simple blocky platforms, it was time to try less sterile level geometry.

Slopes felt natural with the robot's wheel, and they opened the door to more height and verticality without asking the player to jump constantly.

Moving platforms were much harder. Depending on how a character controller is written, it may not cooperate cleanly with the physics system. The fix was to track the platform's velocity and add that motion to the player, so the character moves with the platform instead of sliding, sticking, or falling out of sync.

Even this needed extra work. The player still had to be able to jump properly while riding a platform. That kind of detail is easy to underestimate until the mechanic breaks in play.

With the character movement in a better place, the next goal was the magnet throw.

A lot of the prototype code could stay: picking up nearby objects, aiming with a trajectory arc, and snapping the magnet to metallic surfaces. The control scheme needed more work.

The new target was one button. Press the button to pick up the magnet. Hold it to enter aim mode. Release to throw. Or tap once to throw quickly.

Mouse support complicated this, because a mouse and an analog stick are similar but not identical. One points to a position; the other expresses a direction. Making both input methods feel right takes specific design work rather than assuming they can share every rule.

The result was a much simpler aiming system. The player spends less attention remembering controls and more attention thinking about where the magnet should go.

The throw also needed animation and feedback. The robot now swings the magnet behind itself before throwing, which makes the action feel like a physical chuck across the screen.

The magnet gained facial expressions, screen shake, a particle burst when polarity changes, and clearer visual effects for the magnetism system. Large directional arrows help show which panel is pulling or pushing, making the invisible force easier to read.

That matters because the magnet is not just a tool. It is the other half of the game's central interaction. If the robot has personality and the magnet feels like a dead object, the relationship between them feels weaker.

Charm does not replace game feel, but it can reinforce it. A cute robot, an expressive magnet, responsive animation, particles, and readable magnetic direction all make the same underlying mechanics easier to understand and more satisfying to use.

Accessibility options need the right timing. Add them too early, while the prototype is still changing constantly, and they may be thrown away with the next rewrite. Add them too late, near release, and retrofitting them can become painful.

This was the right moment: still early in development, but hopefully close to final game code for the character.

The options included remappable controls, a toggle for aim mode instead of requiring a held button, low-sensitivity snap aim, and ways to turn off particles, trails, screen shake, and other effects.

Colorblind support mattered because the game is built around red and blue magnetism. Red and blue are distinguishable for many forms of colorblindness, but relying on color alone is still risky.

A better setup was to make the magnet black and white by default, then apply a color tint in code. That lets the player choose whatever colors work for them, and the same chosen colors can apply to matching panels. Symbols can also appear on top of the colors, so a plus and minus communicate magnetic direction without relying only on hue.

Accessibility work is hard. It takes time and adds code. Some options may need to be cut if they make an already messy script worse. But the result is worth doing, and doing it before the final systems harden makes the work much less painful.

The finished controller was a huge improvement over the first prototype character. In many genres, the main character is the backbone of the whole game. If moving through the world feels bad, everything else rests on weak ground.

But the work also revealed a sobering truth. A complete playable prototype with ten levels took thirty development days. This one character moving around one simple test room took almost two months of coding, problem solving, bug fixing, and polish.

There was still more to do. The camera was a placeholder. Death and respawn did not exist yet. The magnetism system still had broken edges. Sound effects were placeholders. A single polished character controller did not mean the game was close to finished.

That gap can be exhausting. Part of game development is being aware of productivity, energy, and mood. A long sprint can leave the project better and the developer depleted at the same time.

Sometimes the smart next step is to stop adding features for a moment, put the tools down, and regain perspective. Polishing one core action can transform a game, but it can also show just how much work a good-feeling game really takes.