I have a basic character controller set up for a 2D platformer with Box2D, and I'm starting to tweak it to try to make it feel good. Physics engines have a lot of knobs to tweak, and it's not clear to me, writing with a physics engine for the first time, which ones I should use. Should jumping apply a force for several ticks? An impulse? Directly set velocity? How do I stop the avatar from sticking to walls without taking away all its friction (or do I take away all the friction, but only in the air)? Should I model the character as a capsule? A box with rounded corners? A box with two wheels? Just one big wheel? I feel like someone must have done this before!

There seem to be very few resources available on the web that are not "baby's first physics", which all cut off where I'm hoping someone has already solved the issues. Most examples of physics engines for platformers have floaty-feeling controls, or in-air jumps, or easily exploitable behavior when temporary penetration is too high, etc.

Some examples of what I mean:

  • A short tap of jump jumps a short distance; a long tap jumps higher.
  • Short skidding when stopping or reversing directions at high velocity.
  • Standing stably on inclines (but maybe sliding down them when ducking).
  • Analog speed when using an analog controller.
  • All the other things that separate good platformers from bad platformers.
  • Dare I suggest, stable moving platforms?

I'm not really looking for "hey, do this." Obviously, the right thing to do is dependent on what I want in the game. But I'm hoping someone somewhere has gone through the possibilities and said "well technique A does feature X well, technique B does Y well, but that doesn't work with C", or has some worked examples beyond "if (key == space) character.impulse(0, 1)"


5 Answers 5


Here is an extremely detailed Sonic The Hedgehog physics guide. I would recommend reading it over, if not actually copying parts of it mostly-verbatim.


It's quite tricky to implement, say, 'Mario-like' physics using a real physics engine.

Last time I tried this, using Chipmunk, I modelled the player as 2 circles - a 'body circle' on top of a 'feet circle'

The 'feet circle' had some friction, was non-bouncy, and fairly small. The 'body circle' was larger and frictionless, to avoid sticking to walls/steep slopes

The object was constrained to not allow rotation - it would just slide around

If the 'feet' are touching something, or were within the last few frames (to allow falling down slopes), the player was considered as on the ground (may have had a surface normal check, too)

It's a while since I looked at the code, but the behaviour was along the lines of:

When on the ground:

  • Apply 'additional gravity' (downward force to help with running down slopes)
  • Apply ground friction (larger amount of horizontal damping)
  • Apply left/right movement force, based on the controls.
  • (Scale down the left/right movement force as approaching a maximum run speed)
  • If jump is pressed, apply upwards impulse

When in the air:

  • Apply air resistance (small amount of horizontal damping)
  • Apply regular (or reduced) gravity
  • Apply left/right movement force, if you're allowing in-the-air control

You've got to be a bit careful with switching between the two states - remember that when running down a slope, you may leave the ground for a couple of frames - you probably don't want to switch states/disallow jumping at that point

A few other things to watch out for, though... 'jump-up-through' platforms can be hard to implement, and when you start doing fun stuff (moving platforms, rotating worlds, etc), you have to be careful to make sure the player can't get trapped/crushed by any 'animation driven' moving object.

  • \$\begingroup\$ I know this is a pretty old answer but I have some questions on this. 1) How do you solve the "keep same speed whatever terrain slope you are on?" 2) If you're using a little circle for feet and a bigger circle for body, wouldn't the player get hung on edges some times? I'm really interested in your aproach. \$\endgroup\$
    – Notbad
    Commented Jan 16, 2012 at 8:27

Honestly I don't think using a physics engine is the right approach for something of that size domain with super strict requirements.

Just write it all yourself. You'll get much better results by saying "move character up by x units in this parabola shape when holding down jump button for length y" than by having a bunch of knobs to tweak.

  • \$\begingroup\$ I've done this several times in the past. It works to a point, but you always end up throwing something else out because it's "too hard" to do the physics right with a hacky controller. In this particular game I'm hoping to involve some spring/rope mechanics for the player's movement, and that crossed into the realm of "I'd rather hack down a real physics engine" rather than "I'd rather hack up a box mover". \$\endgroup\$
    – user744
    Commented Aug 15, 2010 at 19:56
  • 3
    \$\begingroup\$ I'd rather hack up a box mover, at least it can't get instable, whereas a physics engine tends to explode if you throw too many forces on it because you need to constrain movements to exact specs (and physics engine constraints ain't rigid, they can only try to comply so much). Also, applying forces to solve one undesired issue tends to influemce everything else, leading to tweakers hell. \$\endgroup\$
    – Kaj
    Commented Aug 16, 2010 at 5:24

I wrote a series of articles about building a platform game from the ground up using modern technologies and it includes how I handled the simple physics:


However if you want something more high-tech it's entirely possible to approach this using full a physics engine. Here's a technique you can use (from Little Big Planet) which makes the player character a fully integrated part of the physics engine:

Instead of applying impulses or setting velocities to move the player around as 'external inputs' to the physics engine, you can develop a constraint which controls the character.

So this constraint will have the player's desired speed and direction as an input (from the game) and will model things like the player's maximum strength and speed. The constraint will try to move the player according to its inputs (and obeying the maximums), and because its a constraint it will apply a equal and opposite force on the object the player is standing on, thereby allowing the player to stand on moving platforms and to affect the things he moves over.

Doing things like this means can you have the player totally naturally be able to deal with situations like being under a huge pile of boxes, or jumping across several moving platforms because he is now a core part of the physics engine.

Hope that helps!

Cheers, Paul.


This question has seen significant discussion on the Box2D forums. Reading though the discussions about character movement, jumping, or platformer and you'll come across every possible issue. However, the issue got complicated enough that the collision filtering system was updated and a Test Bed example created solely to show how it should be done.