Sounding Off

I'm still immersed in the depths of GoatTracker!

Since the last blog entry a few days ago (read here), I've completely rewritten my 'get ready' tune so it now sounds more 'urgent' and suspenseful.  Well I think it does...

I've also written four more level tunes to accompany the one written the other day!  I was originally going to make them spooky sounding, but found that style didn't actually suit the gameplay.  More 'driving' bass lines are needed to motivate the player along.  Each tune is between 40 and 60 seconds long before repeat; I've deliberately made them short so I can have more tunes in memory for more variety for each level.  As mentioned in the previous blog entry, these tunes are written using only two voices, leaving the third free for sound effects.

Along with the level tunes, I've composed a really rather jolly game complete tune!  A bit premature maybe as I don't even know if I'll have a game complete screen yet, but it gives me options further down the line.

What?  You want proof I've actually written some music?  Below should be a player containing a test recording of the music currently assigned to Level 1 (this was recorded using SidPlay64 on my 8580 equipped C64c playing through my Dolby amp).  If the player doesn't appear from some reason, hear it on my SoundCloud page here.





Next diary entry...

Sound Start

After another busy week in work I've fancied a change from level designing, so yesterday evening I started work on some music for the game.

Now I will be honest, I did start writing some music quite a few months ago and by that I mean the first 10 seconds of the title screen music, along with some place-holder notes for the 'get ready' screen so I knew that the music was being called/initiated and played correctly for the sequence of screens from the title screen, through the get ready screen to the game screen.

After yesterday's bout of composing, I have now refined my first 10 seconds of title screen music, modified my get ready music and added a (very) short piece for game over.  The biggest addition though is a brand new piece that is currently around a minute long that I'm using for the in-game music.

Of course, all this music will be refined, extended or even deleted and composed again from scratch as time goes on.  At present, I don't really want to aurally share the music in it's current state, but here is a screen dump of GoatTracker in action:

When being assembled, the code is loading the music to $0900, with the next block of memory being used by the charset at $2000.  This gives me just under 6K of memory for music at the moment.  Quite a bit!

I've decided that I may do short, simple repeating tunes so that each level has it's own music.  To this end, I did dive into the code and add a short routine that can detect the level number then initialise and play a different tune for each level.  Naturally, this code will be removed if I run short of memory in the future and only end up with one in-game tune.

I've written the first in-game tune with only 2 channels, keeping the third free.  I'm toying with the idea of having some sound effects too in the future, maybe for jumping or energy depletion.  Maybe...

Next diary entry...

Level 4 Design

Off the back of sorting the cross locations for Level 2 yesterday, the evening saw the beginnings of me tentatively designing Level 4.  As stated in a previous blog entry (see here), I never intended to have levels set in exterior and internal locations alternatively, but since I've seemed to set off down this path, it shall continue!

Thus, after Level 3 being set outside, we're back indoors for Level 4 and most of today has been spent creating the inside of a haunted house!  This gives me a chance to save some characters in the charset by reusing some used in level 2, as well as adding new chars specifically designed for this level.  I need to do this after blowing five chars on the rain in Level 3!

New chars and features for this level include a wooden staircase that can be used to reach higher platforms, a stone fireplace (so as to reuse the animating flame char from Level 2) and a rather ominous looking rope and noose!

Since this is now Level 4, I'm assuming the player is getting better at the game, so platforms in this level are deliberately further apart to make them harder to cross, with gaps below that the player falls down if the jump is 'missed'.  Along with avoiding the planned to be fast moving enemies, this level should be the toughest so far. I hope!

What does the level look like?  On this occasion, I've done a time-lapse animation showing the build up over the course of the day it took to design.  Of course, things will probably change as the enemies and crosses are plonked into place and the level tested.

Next diary entry...

Level 2 Crosses

I've had a difficult week in work for one reason or another, so I set Friday aside to sit in the office, put my feet up and drink coffee!

Whilst taking it easy, I also decided to grab a screen-dump of Level 2 and work out some collectible 'cross' locations; since Level 3 is now in the game (see this blog post here), I don't want to end up with a load of levels in the game without anything to collect in them!

So, as well as the enemies, the crosses are now in for Level 2 and to prove it, here is my scrappy piece of paper with hastily scribbled hex number coordinates, along with some notes about slight modifications to the actual screen layout...

Next diary entry...

Level 3 Insertion

A fair few months ago, I started to design Level 3 for the game (see blog post here).  Up until yesterday, it only existed in my screen editor, but I've finally exported the screen and colour ram data and inserted it into the game, along with the code to set-up and call the level.

Since this level has been languishing for a while, I thought it deserved some habitation, so I've also added some data to the enemy table for this level and there are now various baddies crawling and flying around.  I still need to add some x and y data for the cross locations; currently the data table contains my stand-by data that only contains 2 locations that strobe back and forth.

Once it was all up and running, I wanted more screen action, but in a subtle way.  I've seen a couple of games recently that have rain in the background (it seems fashionable to have rain in your game at present and, at time of writing, appropriate given the weather outside) so I decided this level shall have rain!

I must also admit to having watched Simon Jameson's Twitch channel the other night where he demonstrated how he had implemented rain in his game and this also provided the idea and motivation for me to include rain in Chiller 2.  However, I wanted a much simpler solution for my game compared to Simon's code, so decided to go with the 'copying char data around' route rather than the pixel plotting through a char route he demonstrated.

So, to start I set aside 5 sequential chars that will be used for the rainfall and plotted a 1,2,3,4,5 repeating sequence in columns using these chars.  In the editor to begin with, the rain looked a little like this...

I did my very best to ensure it looked 'random', with columns of chars that were near or adjacent to each other not having identical numbers that were in-line (1's in line with other 1's, 2's next to other 2's and so on) - not doing this would have resulted in very unnatural looking rainfall methinks!  Once I was happy with the layout, I cleared the chars themselves of the numbers, knowing the chars were still actually in place on the screen.

I then designed a simple raindrop, not in the editor, but on a scrap piece of paper which I then turned into a table of hex bytes.  If you're interested, that table of data looks a little like this within my code...

 ; raindrop pattern  
   
 rain_patt     !byte $ff,$ef,$ff,$ff,$ef,$ff,$ef,$ff  

And then it was time to code a very simple rainfall by copy my raindrop pattern above into each char sequentially.  The code I came up with looks a little like this (please note, this is wholly unoptimised at present but was written this way to ensure it could be followed in the future by me!):

 l3_bkgrd_anim                          ; level 3 rain  
   
 ; clear all raindrops first  
   
           ldx #$00  
           lda #$ff                     ; char needs to be solid!  
 clear_rain            
           sta $2400,x                  ; raindrop 1  
           sta $2408,x                  ; raindrop 2  
           sta $2410,x                  ; etc  
           sta $2418,x  
           sta $2420,x  
           inx  
           cpx #$08                     ; all 8 bytes of each char cleared?  
           bne clear_rain               ; no? branch back  
             
 ; now check which raindrop should be drawn! 
   
           lda raindrop                 ; which raindrop are we on?
             
           cmp #$00                     ; drop '0'?
           bne *+$05                    ; no? go and check drop '1'
           jmp draw_rain0               ; yes? go draw rain0!
   
           cmp #$01  
           bne *+$05  
           jmp draw_rain1  
             
           cmp #$02  
           bne *+$05  
           jmp draw_rain2  
             
           cmp #$03  
           bne *+$05  
           jmp draw_rain3  
             
           cmp #$04  
           bne *+$05  
           jmp draw_rain4                                     
             
 draw_rain0       
           ldx #$00  
 rain0_loop  
           lda rain_patt,x            
           sta $2400,x  
           inx  
           cpx #$08  
           bne rain0_loop  
             
           jmp draw_rain_dun  
             
 draw_rain1       
           ldx #$00  
 rain1_loop  
           lda rain_patt,x            
           sta $2408,x  
           inx  
           cpx #$08  
           bne rain1_loop  
             
           jmp draw_rain_dun  
             
 draw_rain2  
           ldx #$00  
 rain2_loop  
           lda rain_patt,x            
           sta $2410,x  
           inx  
           cpx #$08  
           bne rain2_loop  
             
           jmp draw_rain_dun  
             
 draw_rain3  
           ldx #$00  
 rain3_loop  
           lda rain_patt,x            
           sta $2418,x  
           inx  
           cpx #$08  
           bne rain3_loop  
             
           jmp draw_rain_dun  
             
 draw_rain4  
           ldx #$00  
 rain4_loop  
           lda rain_patt,x            
           sta $2420,x  
           inx  
           cpx #$08  
           bne rain4_loop  
             
 draw_rain_dun  
           lda raindrop  
           inc raindrop  
           cmp #$04  
           bne reset_bkgrd_anim_tmr  
           lda #$00  
           sta raindrop
  

What's happening?  Well, when this routine is called, first of all I'm clearing all five rain chars to erase any previously drawn chars (this could be optimised to clear only the last previously drawn char!).  Then, using a 'variable' that stores which raindrop we're on (it starts with '0'), the code determines which char should be drawn to next and jumps to the drawing code for that char and copies the raindrop pattern data pattern into that char's memory location.  The code then jumps to a label called 'draw_rain_dun' which increases the raindrop variable and then checks to see if all five chars have been drawn to in sequence.  If they have all been drawn to sequentially over the course of the routine being called a few times (i.e. the fifth raindrop char was last drawn to), the code resets the raindrop variable to '0' so next run through the raindrop pattern is drawn to the first char again.

Hopefully that makes sense?!  Of course, this code is also inside a timer that executes it (at present) once every 4th frame.  Without the timer that rain would, er, rain too fast!

To be honest, if this code was applied to the whole screen and not just the top of the buildings as in my level, it would probably look pretty jerky.  However, in the context of my level and game, it has a nice cartoony feel that I'm very happy with!  What does it look like?  Something like this...

Next diary entry...

Level 2 Enemies

Late last night, I finally got round to 'plugging' some data into the movement table for the enemies on Level 2 (The Church).

On this level, the platforms extend quite high, so for the first time the player is able to 'jump' up into the top open border.  Therefore, it makes sense to have an enemy 'patrolling' this upper border making it more difficult to collect any crosses that appear there.  In conjunction with this top border enemy, there is another enemy patrolling the platform just below, so this should mean the player has to carefully time their jumps between the two enemies, while avoiding floor mushrooms (which zap the players energy) and any floor openings.

I can see quite a few crosses being placed up there to collect!

Next diary entry...

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...

Enemy Movement Delay

A small diary entry to celebrate the New Year!

In my haste when coding the the enemy movement code (see previous diary entry), I didn't think to include a timer to 'activate' the code.  Basically, when the enemy movement routine was called every enemy sprite position was updated *every* frame.  This had the effect of every enemy only being able to move 1 or 2 pixels (set by the sprite speed table) because any bigger movement made the sprite move too fast, which looked rather silly on screen.  Also, because there were only 2 speed choices, the movement looked a little 'unnatural', with too many enemies moving in-sync because of their same speeds.

I've now enclosed the enemy movement routine within a timer, so it only activates every so many frames set within the code.  Currently, the routine now runs every other frame, which means I can now have sprites that move 3 pixels without looking ridiculously fast.  This means that the screen now looks much more 'natural' with enemies moving seemingly at their own pace.

As the game progresses, I'll play more with the timer and enemy speeds to see if I can introduce even more natural looking movements.

Next diary entry...