Nicolas Goles

Code & Randomness

Choosing a 2D Physics Game Engine

Today I want to talk about a common issue among many indie/non indie developers. Deciding what third party library/engine to go with, in my particular case it was a 2D Physics to use in our current iPhone (for now) project, but the scope of the article will cover good tips that can help you to actually make your decision wether your are picking a JSON Parsing library, a Texture Loader in a platform independent way. ( You get the point :D )

Taking the correct decision is very important, an incorrectly chosen engine/library, can end up slowing you down quite a bit, thus frustrating you and your team. So you must do your best effort in order to make the correct choice.

DISCLAIMER: This article is based in my personal opinion and experience, thus can be subjective.

I. Ask yourself.

There’s a couple of important questions that I think we must ask ourselves before actually doing anything…

1) Do I really need a third party library/engine ? Why ? 2) What features are critical for my needs ?


1) I have several reasons about why I wanted to go with a third party physics engine and not actually coding it myself .

  • I’ve never coded any complex physics Apps. So Inexperience in the subject was an issue for sure, I would need to learn as I go and it would probably take more time than what I’m willing to spend in this issue. Gando Games is working in an Action RPG Game for iPhone, and right now we are trying to reach a very important milestone, time is golden.

  • I wanted to go with something that had been used in commercial games, with somewhat of a reputation, that could allow us to actually focus in our project main features instead of concentrating in that “strange collision detection borderline case, that wasn’t implemented correctly in the internal engine”.

  • Motivation, I’m not a big fan of physics, some people love physics. We are a small team, and need to stay motivated, so trying to minimize the number of non-appealing things to do, is actually crucial. A small demotivated Independent team is totally worthless, motivation is key.

So, in conclusion, I wanted an external 2D physics engine to avoid the hassle of coding from scratch, wasting a lot of time, and actually getting demotivated in the process.

Then, defining the 4 main features ( less is better ), that you are looking in that library/engine. Is speed that important for your Game?, does the size of the library matter for  you? Do you actually need portability?

2) I was looking for 4 main features:

  • Easy and Fast to integrate

  • Documentation

  • Good APIs

  • Permissive License

As you can see, the main feature that I was looking was the  integration capabilities, because that would directly impact the time needed to do so.  We don’t want to limit ourselves with middleware, so portability is a very important issue too, ( you may want to release for other platforms in the future ).

II. Do your homework.

This is key, and I can resume it in 3 steps

  • Enumerate available options

  • Ask other fellow developers about them.

  • Prototyping.

Enumerate available options

This is actually not very hard, ( thanks Google! ). Try to Google and enumerate the options that you currently have. This also include asking other developers about what are they using. Use IRC, Forums, or if you follow some blog of a developer (mostly iPhone devs in my particular case) whose opinion you actually happen to respect, try sending him/her an e-mail!, experienced developers can provide tons of good information, just approach them politely. While gathering your results, enumerate them, listing them in a spread sheet is a good idea.

In my case, my Enumeration phase looks like this:

They both seem to have been used widely, Chipmunk Physics has actually been used in several iPhone/Desktop/PSP Games and has bindings in several languages. Box2D has been widely used in Flash Games ( nearly every flash game that uses physics is using Box2D) and was recently adopted by Cocos2D-iPhone too, so it has been making an appearance in several iPhone Games lately. Also, they both offer a permissive license ( MIT license ). So I think they are both very valid candidates. There are other Engines such as bullet, but bullet aims for 3D Physics.

Ask other fellow developers about them

Getting feedback from other people is actually very very important, there is a lot of experienced people willing to answer one or two questions about an engine/library, why are THEY using it ?, sometimes a library can look quite good “in paper” but when you start playing with it you stumble with unexpected bugs, and some other unexpected stuff. Asking other people can actually save you a lot of time. I often like to use IRC for this, but other game developer forums are also interesting.

I asked a lot in IRC, where I know several Game Developers that are always willing to help, and of course to answer a question or two. In my case, I got mixed opinions about Box2D vs Chipmunk Physics for iPhone Games, but here’s a list of Pro’s and Cons that I was able to gather:


Box2D Engine Pros

  • Big community supporting it. It was just a matter of getting into Box2D Forums and check the amount of action and registered users there ( Right now there are 3465 registered users and a total of 4142 topics)

  • Decent Documentation. There’s a Box2D manual for using the C++ engine available. Also the big forum does also count as documentation for me, since you can always ask the tricky questions there, and the forum shows a lot of movement.

  • Object oriented, Box2D uses object orientation in C++ without any STL containers

  • Updated. Box2D shows very recent work, the project’s google code activity is high, and the commit history showed steady and constant work. This is extremely important, you don’t want to pick up an engine that doesn’t seem to be updated often. This can cripple you a lot, you may have to end up fixing the bugs yourself and since my main goals where speed and to “decouple” myself from the physics engine internals, this was extremely important for me.

  • Memory management. Box2D is great for this, since it perfectly owns all the memory that it uses. This is great since we don’t have to worry about memory leaks (unless there’s an internal problem in the engine, but according to what I’ve read, it doesn’t happen to be the case )

Box2D Engine Cons

  • Not the best APIs. Box2D can get quite verbose and complex, I’ve read they have improved a lot in that direction, but still lacks of a great API set.

  • I mentioned in the Pros that it had decent documentation, but it seems to be a bit outdated, ( in comparison to the latest SVN version ). I think this is an issue for the most part of open source projects, so we can’t ask for perfection about it, still it’s a counter point.

Chipmunk Physics

Chipmunk Physics Engine Pros

  • Very clean APIs. You read it, the APIs are crystal clear, a set of 5 or 6 principal well defined functions.

  • Great Documentation. The documentation of Chipmunk is very good in comparison to Box2D ( at least the on-line resources ).

Chipmunk Physics Engine Cons

  • The community behind it is not that big (about one fifth of the Box2D community)  , this makes me wonder. ( 763 registered members and 959 topics )

  • Not object oriented. I don’t have any problems with C (which is the language that chipmunk physics is written in) , but I really appreciate object orientation. In the end it tends to make things a lot easier for me. Also operator overloading simplifies code writing quite a bit.

  • You handle your memory. This can be good but can also be bad. I preffer to leave the memory management to the physics engine, that’s why I list this as a “Cons”.


In my opinion, the most important part of the process. After you narrowed down your choices, start prototyping!. Throw in a couple of dirty examples using the library/engine in question. Does it meet your “features” requirements ?, even try to go ahead and make a “dirty plug” for your engine. Does it seem to work fine? , are you comfortable with the APIs ? If speed is your main requirement, is it fast enough for you? maybe perform profiling here and not later.

Here are a couple videos of some of the prototypes that I made to understand the internals of the physics engines and how to integrate it with our iPhone Game:

iPhone Physics Engine Prototype from Nicolas Goles on Vimeo.

Physics prototype for iPhone 2D Engine from Nicolas Goles on Vimeo.


Time to make a decision.

After all that process, I ended up going with Box2D. I really like the simple Chipmunk API, and the great documentation behind it. My main problem was the community, Box2D seems to be more established right now, with a very active community of developers behind it. That itself is a powerful reason. You don’t want to loose “support” , and a big active community can do wonders to your workflow :D. Another important reason was that the documentation of Box2D is not that bad either, actually making the prototypes that I show in the videos ( the second one being a dirty Gando Engine Plug ) , took me about an hour, just basing myself in documentation and the help of some fellow Box2D devs.

I would like to say one more thing:

The decision you end up taking is not carved in stone. If you feel you took the wrong choice and that is actually impacting the project in a bad way, it’s better to turn around early than later, so if you are in time, re-evaluate and throw in a couple of prototypes with the other engine. It could be a time saver if the switch is done in the correct time frame.

Hope this article provided value for some fellow Game Devs, this is a question that I get asked a lot, and this sums up my answer :D