Because I won't want to spend any extra time on background artwork or map design, I'll probably go with one of those hardcore shmup designs, with random waves of enemies and bullets flying everywhere. With my aging reflexes I'm not exactly a brilliant player of that genre, but it should be a good sample game to make. Any suggestions of good features you've admired in those games or sample shmups to study would be welcome.
As for collision detection, I've decided to go with the old tried and true segmentation bin approach that I've used before. With this approach, the objects to be tested fall into three categories:
- Point Objects (with no dimensions): these are usually bullets
- Small Objects (under a fixed radius): small ships, the player ship and missiles
- Large Objects (over the fixed radius): bosses and absurdly large laser blasts
For the point objects and small objects, the playing field is divided into a grid of the size of the fixed radius. The point objects can be placed into a single grid box (since they have no dimensions).
The small objects can fall into a maximum of four grid squares, so either the algorithm needs to check the neighbouring grid squares, or you can reference the object in more than grid square, or you can use a separate grid to counter that.
The large objects are special cases. You could put the large object in the grid by referring to it in every square it overlaps. However since there is unlikely to be more than half a dozen of these objects it doesn't really matter if these are treated as a separate case.
Damn, I realised I forgot to consider the effects of time: bullets at high speed may pass through an object all together. This makes it a 3D problem (normal 2D space plus time). I don't know if my approach will work well in that case.
I might as well plan to put all the collision detection within its own special module and be prepared to experiment if things start acting strange.