My general policy of ‘code it first, ask questions later’ has bitten me on the bum this afternoon. Settling on an elegant way to detect and utilise Bullet collision detection in my game components has proved to be as fiendish as I had feared. My first decision was where exactly I wanted game specific collision responses to be resolved. I got hung up on whether to have a single collision resolver class (which had to know about all the relevant pairs of objects and what to do with them) or to allow game objects to resolve their own collisions. In the end I plumped for the latter, which seemed to produce a cleaner structure. I then just cracked on with implementing a technically interesting solution using proper events via Boost::Signals2. This allows a type safe subscription of multiple interested objects to each of my PhysicsObject’s collision events. However, now I’ve spent hours on it, I’m thinking that I don’t really need multiple objects to receive these, and it doesn’t really solve the other problem of distinguishing between the different objects that can be the source of a collision :(
Still I think I might have unlocked the ‘Bletchley Park Achievement’ for the most arcane line of C++ syntax by using a lambda in the subscription code:
m_physics_controller->SubscribeToCollision([&](Object3DPhysicsController* source){OnCollided(source);});
Can anyone top this? 
I’m going to make use of SVN now and roll-back 3 hours of my life and re-implement this stuff using a simple ICollidable base class, from which interested objects must be derived.
Ho hum. Hopefully another video in the morning.
No comments:
Post a Comment