PhysTank with Physics!

A basic physics component has been semi-implemented using Box2D. I still need to complete the interface and make sure everything is working as it should. Next I will probably move onto sound, I want to complete the tertiary components so I know what I'm working with when developing the game itself. The next step after that will probably be to allow users/developers to manipulate INI/XML files in order to change application settings. This will include things like choosing which renderer to use (only Direct3D at present), display resolution, setting AF(Anisotropic Filtering) on the loaded textures and MSAA (Multi-Sampling Anti-Aliasing) to make the line drawing seem smoother as well as run speed etc.

A good tip: Use the interface design pattern and use lots of them, I can't stress how useful a good interface class can be. By interface I mean an abstract class which contains nothing but pure virtual functions that you inherit from. The reason for doing this, for the renderer for example, is that it provides a common interface that lets you switch out various components. For example at some point I'll be writing an OpenGL renderer for PhysTank that I should just be able to plug-in without having to change any interactions between the UI and the Renderer. Even if you don't think you're going to need one, for example if your game is only ever going to have one renderer, I'd still recommend doing it because it makes you think about the interface to components you're creating.

All too often there's a temptation to use the D3DX extension classes for example in areas of code outside of the platform or renderer, i.e. in your main game code. D3DX provides perfectly good Matrix and Vector classes right? Along with an entire set of easy to use functions. Resist using these things in your game code at all cost. If you don't feel like writing your own vector or matrix class (although you probably should), at least use what are called wrappers which hide the underlying implementation as a D3DX class (or if you're really lazy use typedefs, i.e. typedef D3DXMatrix Matrix4x4). Then if at some point down the road someone offers to port your game to a UNIX OS they won't have to tare their hair out looking through file after file attempting to replace every D3DX call and instantiation, they can simply re-write the vector and matrix classes.

Keeping platform dependent code out of your main game code keeps things looking cleaner and easier to understand too, it also makes you more diligent against lazy programming.