2D physics in games

In our last blog post we talked a bit about the history of physics games. Now it’s time to talk about how we do physics in today’s games.

Smoke and mirrors In the game industry, like in the real world, nothing is perfect. But we try hard to hide the imperfections. In visuals you’re limited by the number of dots on your screen, in physics you are limited to a few simple shapes like a circle or a polygon which have to represent your game objects.

That’s what we call approximations.

This is a screenshot of our game Paper Streetball:

And this is the phyics setup for the same screenshot (shown in green):

As you can see the ball is approximated by a circle (which is good approximation) and the hoop is approximated by 2 circles on each side and a rectangle for the table.

But what if you’re trying to model this in your physics engine:

It would probably look something like this:

Now this approximation is far from ideal – trying to roll a ball down these hills would look weird. This is solved by modeling the hills with more line segments, but every line you add makes the physics engine run a bit slower – so physics in today’s games is all about balancing perfomance and accurate simulation.

Physics are free!

Instead of writing your own physics code, you can do what everyone does – use a free physics engine. You want 2D physics – use Farseer, Box2D, Chipmunk, you want 3D – use PhysX, Bullet, JigLibX. Every one of them has it’s strenghts and weaknesses, and you should choose very carefully. Picking the wrong one could (and probably will) spell disaster for your physics game to be. And as always you should promote the library you’re using by listing it in the credits, it’s the least you can do.

As Paper Streetball didn’t have a credits screen, we’ll use this blog post to promote the Farseer physics engine – even if it didn’t do quite well for our game we think that it’s a very well equipped physics engine with plenty of advanced features.