Unsung Routines

I've been working quite a bit of what I've come to call 'unsung routines', as opposed to the 'hero routines' such as the all important sprite and background collision detection or the gravity and animation routines.

These unsung routines have no apparent visible effect on screen but are important to keeping the code running in a modular way so it's easy for me to add more features.

An example of this is my 'process background animations' subroutine.  When this was routine was coded originally, it was done only for the animating torch flame character (see this blog entry for more about animating chars) that appears in the current level 2 (the church).  Since this routine was called from the main game loop code, it meant that the flame char animation code was executed for every level, even if the flame wasn't present on the level!

What a waste of processing time!  How lame!

So, my background animations subroutine has now been restructured and had some code added so that it can handle multiple levels - it now checks the level the game is currently on and only executes the animations needed for that level.  If the level has no character animations at all, the animation code is skipped completely, so no processing time is wasted!

Of course, I had always originally intended to do things this way, it's just that I've only just got round to it!

Another example of making things more modular is the variables and code I've added for background colours.  I had originally set the background colour to black and had intended for every level to have a black background.  However, when designing level 3, I chose to have a dark blue sky just to make the level look different to the previous two levels (see this blog entry for more about the level 3 design).  The background is still actually black, but blue characters are used to represent the sky.

This created the problem of the sky being blue, but the top border being black and seeing that the borders are 'open' and the player sprite can jump up into the top border, it looked a little strange with the sprite moving over blue then into black 'sky'.  So the solution was, quite simply, to make the top border (now controlled by the background colour register since the border is open) blue.  Now there is a nice extension of the blue sky right to the top of the visible screen.

Problem - all other levels now have a blue top border, when not needed, including the title screen and intermediate screens!

To overcome this and returning to the idea of making the code more modular and flexible, the colour of the top border part is no longer hard coded, but controlled by a 'variable' that is changed for each level as part of that levels set-up code.

To be honest, these are the sort of things that more seasoned coders probably do right from the start, but since this is my first 'real' game, I'm still coming to terms with such things!

Next diary entry...