If DIY means do it yourself, what does DDIY stand for?

DDIY – Don’t do it yourself

A daunting task

If you skimmed through my ‘simple game physics’ articles you would normally expect this to go into sample code or at least explanations regarding collisions and restitution, and so forth. My physics component demonstrated some of these behaviors. It wasn’t great, still useful in a limited way.

Integrating a physics engine was a daunting task. Until the day I actually tried, picked the Bullet physics engine and well - I thought it was alright. By the look of it, basic integration took about 10 days, leaving many loose ends but looking very promising.

Not in vain

Trying to roll my own physics component made it a lot easier and safer to integrate a third party library in place of my own, simplified physics component:

• My component provided an integration template. I kept the semantics I used, switched my physics classes to interfaces and provided Objective C ++ wrappers for the library objects I needed.
• I understood the kind of problems the library was trying to solve.

I’m guessing trying 2 libraries instead of just one may be the better way around in this case. While I would probably recommend this approach if you’re starting up, I don’t regret approaching the problem the way I did.

Pros and cons

Before going any further, there’s one point that we ought to clear right away: just because you want ‘simple physics’ doesn’t mean a physics engine will get in your way or integrating with one will be slower than rolling your own. Even if your physics are very simple (e.g. typical 3D RPG), the cost of integration is probably lower than your development cost. Additionally, a good engine like Bullet will make simple things easy and benefit high performance. Integration doesn’t just save the ‘raw development cost’. It saves you the cost of testing, debugging and optimizing your code. Additionally, it is forward looking and opens possibilities (e.g soft body dynamics) that will unlock as hardware becomes faster and your projects become more ambitious.

Reasons to roll your own:

• The dynamics you’re implementing are truly alien. In other words, you somehow can demonstrate that an engine based on newtonian physics will get in your way altogether.
  If you’re coding a block-world where everything occupies exactly one square on a grid, then there’s no benefit to using a physics library.
• You need very high performance based on a super-simplified model and can spend the time optimizing your code.

Reasons to integrate

• You want newtonian dynamics, either advanced or basic (collisions, restitution, forces)
• You want good performance at low cost

Reading further

Read Expectations: what a physics engine can do for us, then if you follow more recent articles, I give guidance about building and using the Bullet Physics Engine. Bullet is open source and free; I’m liking it so far.

Testing the technology you’re integrating with is important. This applies to Bullet and I think it would equally apply to, say, a game/rendering engine or an XML library.