# How do I build a 2D physics engine? [closed]

The most advanced games I've made are a 8-ball pool game made with the physics engine Box2dFlashAS3 and a platform game with levels.

When I did platform games, I've always wished to know how to make an engine, so that I could re-use it. When I see games that have slopes, curved slopes, perfect gravity and real-life physics, I've always wished I knew how to code the engine.

Please suggest techniques and articles for whatever relevant knowledge-base is necessary.

While I recommend against rolling your own physics engine for anything other than the experience of doing it (just realize you probably should throw it away when you're done -- it's really hard to get all the edgecases and numeric limit/stability issues sorted out, and your time may be much better used by contributing to an existing engine), here are a few resources:

Pool Hall Lessons: Fast, Accurate Collision Detection Between Circles or Spheres discusses circle/circle and sphere/sphere collision.

The N Tutorials are wonderful for a basic understanding of Separating Axis Theorem-based detection and response.

Erin Catto has all the GDC lectures about Box2D's implementation online. Box2D also has straightforward code to read, in my experience.

• the pdf's are really tough materials. But, when I read through the cpp and h files, as you said, they are "understandable".Thank you. Oct 18, 2010 at 12:52
• +1. Box2D also is very careful about stability, one of the things that is very difficult when you are rolling your own. Oct 18, 2010 at 17:00

Here's how you might do it:

# Approximating movement

Every physics object needs these vectors:

• Position: Where the object is.
• Speed: How its position is changing.
• Acceleration: How its speed is changing.

So, intuitively, you need to do this sort of thing every frame to every physics object a:

a.speed    += a.acceleration
a.position += a.speed


Pitfalls: This is known as the Euler method of integration. This approximation is better for small speeds and accelerations and with small time-steps. In a game, this is normally true. But if an object moves really fast toward a thin wall or directly toward another moving object, it may skip collision with that object when its position is incremented by a large enough amount to cross it entirely. If you have fast-moving objects, you may need Continuous Collision Detection to get away with this.

# Collision

Collision can be approximated with this sort of sequence:

1. Detection: It is detected that two bodies intersect.
2. Resolution: The position of each body is changed so they no longer intersect.
3. Physics: The speed of each body is changed to account for momentum, friction and restitution (bounciness).

This is known as Discrete Collision Detection, as it happens at discrete points in time. Each step deserves attention:

## Step 1: Collision detection (Are things colliding?)

For two circles: Just check if their centres are more than the sum of their radii apart.

For two rectangles: Check if any of their corner coordinates are within the other rectangle.

For anything involving more complex polygons, you'll need the Separating-Axis-Theorem, which is a topic for another question.

Pitfalls: There are really many other collision types you might want to consider. Some are really complex: Convex polygons might intersect multiple times!

## Step 2: Collision resolution (Moving them apart.)

A simple method to resolve a collision is translation by minimum penetration, using values obtained from collision detection. This essentially involves moving the objects apart with the minimum possible distance of movement.

As an example, consider circle-circle collision where one of the circles is fixed in place. The minimum displacement vector has the same direction as the difference between their midpoint vectors. Its length is the difference between the sum of their radii and the distance between the centres.

This idea easily generalises to other shapes.

Pitfalls: If both colliding objects are moveable, you may have to move both of them by some fraction of the overall distance to get a believable approximation of their movement. They'll obviously have to move in different directions.

## Step 3: Collision physics (Other changes.)

The most obvious thing that tends to happen is that one or two of the objects changes direction i.e. rotates its speed vector. This is pretty easy to implement.

Pitfalls: Objects might be elastic, but they might not be, in which case the total energy in the system is reduced. You might need drag due to air resistance. Friction (particularly static friction) are notoriously complex to implement.

# Some conclusions

Simulation of reality is exponentially harder the more if it you want to simulate. You're walking into a minefield of countless edge cases, mindblowingly difficult formulae and ever-growing stacks of research papers.

If your needs are simple or you're eager to learn, try it.

If your needs are complex or you don't like maths, get a physics engine to gloss over the details for you. Box2D and Bullet are pretty popular in games.

I think this could be useful: http://gafferongames.com/game-physics/integration-basics/

• not bad, but It doesn't take me anywhere,much. Oct 18, 2010 at 11:11

Probably the most comprehensive tutorial style resource:
http://www.wildbunny.co.uk/blog/2011/04/06/physics-engines-for-dummies/