2008-03-02

The Secret Posts - Some Ideas Before I Forget Them

(Written 29/01/2008)

Some hastily-written ideas about program structure.

It’d be useful if sprites followed the Particle/ParticleManager model, so I’d have sprites and a sprite manager class. However, as there are distinct types of sprite (player’s bullet, enemy bullet, enemy, powerup, score bubble) I probably need a manager for each type. Powerups and score bubbles might be similar enough to let me use a single manager.

The bullet managers would check for collisions between themselves and the enemies (or the player sprite depending on the type of bullet manager). It can handle limiting the number of bullets too - call bulletManager::addBullet() and if it returns false, you know that the maximum number of bullets is already on-screen.

I’m thinking of going for traditional bullets (not too many on screen at once), occasionally descending into bullet hell when appropriate (the UFO, for instance, would be neat if it could spew bullets like crazy, and drop a powerup when it’s destroyed).

Enemy movement is interesting. If I create a set of enemy classes that include movement functions, I won’t be able to make a particular enemy type move in a different fashion. All enemies of that type will move in the same way unless I subclass. However, if enemies contain a pointer to a “MovementEngine” class instead, I can subclass that and have that class provide all of the movement logic. Enemies of the same type could have different engines plugged in, and thus move in different ways. Bullet attack patterns could be pluggable, too.

That way I can have different bullet hell patterns for the UFO without creating different UFO classes.

The particle system needs to draw before the sprites, so that particles are at the bottom of the z-order.

The player’s helicopter needs to be at the top of the z-order, so it should be drawn last (the chopper blades have to be above everything else or it’ll look daft).