I've been working on the physics for my 2D game and for the past two weeks it's been doing my head in. I wanted something a little more complicated than what you see in 2D platformers, but I wanted to keep the feel of them by making it far less than realistic (for example, angles are out of the question). Because of this, I don't want to just implement a more comprehensive physics engine that already exists like Box2D and just disabling rotation on every body as it has so many extras that I won't be using that will be wasting valuable processing time - this game is going to be running on mobile devices so that is quite important.

I call this kind of physics engine I'm trying to make an AABB physics engine, as all bodies will be rigid and rectangular in shape. I can't find any documentation on something like this anywhere. I thought that I could take the really basic platforming engine that I could make in my sleep (object has horizontal speed and vertical speed, move until it collides, stop at collision point and set either horizontal or vertical speed to 0 depending on collision), and then put in some more "real world" physics such as manipulating objects through forces rather than directly changing the speed, and implementing friction on every body. It didn't take long for me to realise that the code was just getting messy and ugly and I needed to start that from scratch and that's sort of been me for the past week reading up as I've never delved far into the physics part of games. Problem is, most tutorials and resources deal with things that I'm not interested in, collision detection with shapes that aren't rectangles, and angles, it's frustrating.

So I'm looking for a starting point, or some really useful documentation, or even a physics engine like this that already exists, I'm writing this game in AS3.

The problem is that while axis-oriented rectangles look simple from afar, their response to collisions is full of special cases. If your objects will always remain AABB's, especially if they can go in any direction at any velocity, your collision code gets quite tricky. The first step clearly is to implement collision detection and collision response.

The first one is rather easy and I'm sure you've already found links, but here is one. The second one is not too bad because if you model your objects as rigid, frictionless, nonrotating entities, you can apply conservation of momentum and solve for the two objects' final velocities, using the normal of the colliding side (which you can get from collision detection). See how it is done for two spheres and you should be able to solve for the general case (hint: the reason objects identical in every way except their shape collide differently is because they have different collision normals). Implementing friction on top of this is not too hard now.

If you are looking for documentation on how to implement physics for rectangular objects, you should google "rectangle" and not "AABB", because AABB's are often just containers for broad-phase collision detection which is not what you are looking for.

Thanks for the post, I'll do some reading up on "rectangular" physics instead. Me searching for things like AABB just proves how little informed I am in this world of physics programming - it's good to learn though!

I don't want my engine to be frictionless (to allow for moving platforms and such), how much more complicated do you think that will make it?

Hi there,

I wrote a series of articles about the process of creating a 2D platform game which uses AABBs exclusively for collision detection. Here is a link to the article which covered the collision detection and resolution:

http://www.wildbunny.co.uk/blog/2011/12/14/how-to-make-a-2d-platform-game-part-2-collision-detection/

There is some free downloadable source-code linked in the article as well which should get you off to a good start

Cheers, Paul.

I had actually read several of your other tutorials on my way to finding out how to do this and so far they have been a big help! I hadn't found that particular one so thanks for linking that to me - your blog is a wealth of knowledge.

I think I found out my problem was just how stubborn I was being when it came to implementing a more complicated solution. If I ever saw "collision resolving" or other terminology that I thought to be remotely scary in a tutorial I'd just sort of switch off, I thought there would be an "easier" way to do it. There really wasn't so I started making an engine the proper way and things are starting to slot together and I'm realizing just how simple a physics engine can be. It's been an awesome way of learning and I may post some code here once I get it really smooth.

Not exactly AABB, but I had similar thoughts to yours, and ended up using physics based off the kinda popular n the way of the ninja game.

They have some very cool tutorials here: http://www.metanetsoftware.com/technique.html - which also include source (in .fla, but you can extract it with notepad++, and adopt it fairly easily)

Their source basically allows collision between AABB/Circle with different other shapes. The assumption here is that the 'other shapes' are static. It's more limiting than Box2D, it doesn't have complete physics simulation, but it allows for some cool stuff fairly easily. Since circles are radially symetrical, for example, I was able to implement a character that leans as multiple circles, which makes jumping physics puzzles a lot more interesting (since collision with corners, and slope in general is considered):

This is a screenshot of my implementation under c++:

You don't necessarily need to consider all cases.

You can extract the collision that basically performs AABB vs AABB collisions and use it as a quite simple method to do box vs box