Gemini dev log: The path to (rigid body) madness

Is having a physics engine wired into the base of your game engine madness?  Clearly the opposite extreme, waiting until the game is well underway and then bolting a physics system on is pretty close to my definition of madness, but I’m not shure if the other extereme is equally un-sane.

My reasoning for wanting to do something like build on top of a physics library from the start is that you can unify many systems that might otherwise grow into less-than-optimally-compatible interfaces.  I’m thinking specifically of movement in a game world.  Normally we teleport our objects around at 30-60 fps giving the nice illusion of fluid movement.  Of course you occasionally jump over a solid object if you’re moving too fast so you then step back and start interpolating the movement and eventually end up with something fairly close to a physics library, at least in terms of determining collisions.  So why not just start with the physics lib from day 1 and build your collision detection, vectorized movement, etc. on top?  Then when you actually want physics based behavior there’s no need to figure out how to integrate some external library, everything is ready to go.

I liken this to something like metaprogramming in your language.  If you start off with Java and then decide later, “gee I really need to hook into every method in this one class and do some logging”, well, have fun getting to know Mr AspectJ.  If you’re in a language like Ruby, the metaprogramming is built in just waiting for when you need it.  The unfortunate side effect though is that you’re paying for the metaprogramming facilities even when you’re writing Java style OO, one reason Ruby is so much slower than Java.  So would sticking in a physics system make Gemini 100 times slower?  I don’t think so, especially since the facilities of a Physics library mesh so well with things we already need in a game engine, like the aforementioned collision detection.  Time will tell to what factor of incorrect my assumption is though (I’m usually off by more than 3x, *sigh*).

My current candidate for a fast physics lib is Chipmunk.  Written in C it should be pretty easy to hook up via JRuby‘s FFI system (which wraps JNA and soon JFFI).  Thanks to Gemini’s awesome behavior system we’re fairly certain we can swap out Spatial for PhysicsSpatial and no higher level behaviors needs to know that the x, y, width, height are coming from a Chipmunk spatial struct vs local variables.  Of course the collision behavior would need to change to use the physics lib, but the nice thing is everything else is insulated.  You can could easily write higher level behaviors that depend on some sort of collision behavior, completely ignorant of weather they do their voodo via primitive shape intersection tests, complex physics based simulations or the divining of chicken entrails.  That last one is still a work in progress.

So, am I crazy to attempt such a thing?  Has this been done already?  Any war stories that you’d like to share?