Changes to the physics system.

I've changed the Physics component to expose more the underlying Box2D implementation. The reason for doing this is that I didn't see much point in building a complete wrapper only to act as a relay to Box2D function calls and restrict functionality available to the game. Due to this the Physics class has become more of a helper class, defining functions which will make future code look cleaner and easy to understand, such as functions to create physics bodies and shapes rather than having shape and body definitions all over the place.

The other changes include adding an AbstractCollideable and AbstractCollisionHandler to the Physics component. Game entities will be able to inherit from AbstractCollideable and be notified of when a collision occurs between them and another body/shape. The other type of collision handler, AbstractCollisionHandler, can be registered in order to receive global collision notifications. This would be useful for the sound system for example, which could implement this class to play sounds when a collision occurs.

As is often the case when using third-party code, finding the right implementation in your code can be somewhat of a nightmare. Your natural instinct is to encapsulate the third party code in your own set of classes which masks its use to the rest of your application logic. The problem with this is that the used code can often be quite large and have a fairly complex interface, so unless you want to spend a great deal of time encapsulating every small function call you're probably going to end up masking some of the used library's functionality.

The alternative to is present the third-party code directly to your application. The problem with this is that it very much ties it to your game, so if you find a better solution to the problem down the line, then replacing the system can be quite a long drawn out and loborious task. It's extremely difficult to create a "one-size-fits-all" interface class for systems with complex interfaces. It's very rarely you'll find a perfect solution to this problem. In PhysTank you can see both approaches, with the Renderer I've very much gone down the route of masking functionality in favour of portability and modularity, where with the Physics component I'm tieing the Physics API being used to my game. The difference is that the Physics API should be portable between various platforms since it itself has been written platform-independent, where as there a good chance the rendering code can't be (especially in the case of Direct3D).

I am not entirely happy with the approach but as is often the case with Game Development, trade-offs are part and parcel.