I started at the start and created a base “class” that all sprites in the game would be instantiated from. Literally everything that moved in the game would have its properties set in line with this one object definition. It started to get messy since it made no sense, for example, for the player’s ship to have an attribute harmPlayer. By the end of the game I had got quite sick of examining attributes for sprites that just didn’t need them.
With the next game I am going to deliberately split out the object definitions and it was this that got me thinking about the types of sprite that I will present.
There will always be a player object. The character, ship, car or object that is under direct control of the player. In many respects this is a unique element of the game since it is potentially the only object that doesn’t carry aggression. With Invaders I was sure to set an aggression level for each sprite which was aimed toward the player object. Most other actions that the sprite could perform centred around this attribute.
But I needed to take a step back from this. I needed to look at the necessary actions that the game must take to make it all happen. I simply boiled it down to this:
With Invaders I had two functions handling movement. The first function was also bound to the animation function. You can see this between levels where the second method is employed whilst the aliens form the pack. There is no animation on the on-screen sprites !
The new game will completely separate Movement from Animation and handle it independently in the game loop. Collision will also be handled on the game loop as in Invaders. Death frames are handled within Animate but it is a unique state in its own right none the less. Firing of missiles is actually a trigger the object handling is a separate consideration.
Taking in to account the earlier problem of sharing attributes I will now be able to assign specific attributes to the sprite based on its role within the game.
For example, missiles are only concerned with movement, possibly animation and being tested for collision. They are not concerned with the triggers of launching missiles. Similarly the alien is concerned with all aspects and is by far the most complicated sprite since it will naturally employ intelligence of some kind. Alien movement can be a complicated and expensive affair. Coupled with collision detection and animation based on circumstances the alien is complex. The player controls his own sprite so much of the complications of intelligence and behaviour are removed.
Towards the end of Invaders I dabbled with the concept of spawning. This proved useful for generating such things as explosions and puffs of smoke. I also used it for the green gunk that the Beholder dropped on dying.
I used what I called a bucket approach for this. I defined an infinite bucket array that would handle each sprite. When something was spawned I dropped another sprite in to the bucket. The game loop handled every sprite object in the bucket and at the end of the level (or on player death) I emptied the bucket and reset the array index to 0. It worked beautifully and I ran several hundred spawned objects at once without any impact.
In a future entry I will post up some object definitions based on what I’ve written here and some basic code for handling the game’s sprites.