Saturday, 29 February 2020

Let it Snow!

After designing Level 9 (The Log Cabin) a few weeks ago (read here...), I've been looking for ways to improve the on-screen look as the level has been looking rather plain - currently, there is quite a lot of background moment (animated chars) used in the levels before and after Level 9.

I did ask on various forums for ideas because I was fresh out of them and a couple of people suggested perhaps animating (glowing) eyes, or wisps of smoke coming out of the log cabin chimney.  I did try these and, although they looked quite nice, I was still disappointed with the amount of animation on-screen compared to Levels 8 and 10.

Yesterday, I had a brain-wave!  I already have rain in some levels, so why not have some snow?

Today, I loaded up the Xmas demo level that was completed for FREEZE64 fanzine (see here...) to see how I made the Level 1 forest look all icy and Christmassy, took ideas from that and incorporated them into Level 9.  Then I had to make it snow.

I started quite simple.  The log cabin background was plastered with a single 'snow' char that depicted a few pixels and that char was then slide repeatedly downwards using a simple bit of code.  That was quite effective, but I wanted more.  I added a little more code to slide the snow char left after the downwards movement and now there was quite the little blizzard blowing, with snow falling diagonally down/across the screen.

To cut a long story short, I spent most of the rest of today experimenting with variations of snowfall - the snow char itself, the speed of 'fall', patterns of fall (including zig-zag patterns) and so on.

In the end, I decided on one of my simple patterns that, although (a lot) less complex than some of the other patterns, works well in the context of the level - there is lot's of movement on screen, but it's not too distracting; some of those more complex patterns drew the eye away from the player sprite and enemies!  Also, it saves me some chars since only 2 are used for the effect!  At present it looks a little like this...


It's quite a subtle pattern that may not even be noticed.  If you look closely, the snow is actually falling in 2 alternating strips (each strip made of one char), perhaps best highlighted in the static image below...


As mentioned, there are only 2 chars being used, each drawn in downwards strips, alternating across the screen - the first char strip is highlighted using a red line in the image above, the second char strip is highlighted in pink.

For this level, the code then animates (slides) the 2 chars downwards, but not at the same time.  Every time the snow routine is called, only one of the char strips is slid downwards, with the other char strip being slid the next time the routine is called.  As a result, you end up with a slight 'jutter' that breaks up the snowfall a little in an attempt to make it look more natural.

The code was quite simple in the end.  I have a variable that remembers whether strip 1 or strip 2 should be moved each time the subroutine is called, the appropriate char is then 'slid' downwards and to finish the strip variable is changed to make sure the alternate strip is slide next run through.  Finally, there is a jump to a small piece of code that resets the background animation timer - as with the majority of the background animations in the game, the snow doesn't fall every 'frame' and on this occasion the snow slides down every fourth frame.


; snowfall anim subroutine  
   
 snow_anim  
           lda snowstrip                 ; which snow strip should move?  
           cmp #$01                      ; strip 2?  
           beq snow_fall2                ; yes? do strip 2 then!  
                                         ; no? then do strip 1!  
 ; move snow strip 1...  
 ; shift snow char 196 a pixel down!  
 ; (char location $2620 to $2627)            
   
 snow_fall1                              ; move strip 1                 
           lda $2627                     ; load up the last byte of the char  
           sta chardown_temp             ; put it in a temporary byte store  
   
 snow_move1  
           lda $2620-$01,x               ; now shift each byte down  
           sta $2620,x                   ; until 7 of the bytes are done  
           dex  
           bpl snow_move1  
        
           lda chardown_temp             ; now put the byte that was originally  
           sta $2620                     ; last into in the first byte of the char  
             
           lda #$01                      ; next time, do snow strip 2!  
           sta snowstrip  
             
           jmp reset_bkgrd_anim_tmr            
   
 ; move snow strip 2...  
 ; shift snow char 197 a pixel down!  
 ; (char location $2628 to $262f)       
   
 snow_fall2                              ; as above, but for snow strip 2!  
           lda $262f  
           sta chardown_temp  
             
 snow_move2  
           lda $2628-$01,x  
           sta $2628,x  
           dex  
           bpl snow_move2  
             
           lda chardown_temp  
           sta $2628  
             
           lda #$00                      ; next time, do snow strip 1!  
           sta snowstrip  
   
           jmp reset_bkgrd_anim_tmr
  

This code can be compacted by using only one slide routine for both strips, inserting the appropriate memory locations for each char as necessary, but as written above, it's nice and easy to read!

Next diary entry...

Friday, 28 February 2020

More Whoosh Hair

Waaayyyy back in August last year, I added a 'jump' sprite for when the player was jumping left or right (see diary entry here...).

It's always bothered me, however, that when the player jumped straight up and/or fell straight down, only the static 'standing still' sprite was displayed.  Well, I've spent some time today fixing that!  I've pixelled up a jump/fall sprite for both the boy and girl and added a tiny bit of code to check whether the player was jumping/falling (gravity is active or it isn't!) and if the gravity is active, the jump/fall sprite is displayed.

In practise, it looks a little like this; very simple, but quite effective I think...?


I've been intending to do this for a while, but have been concentrating on other things such as level design.  Now the jump/fall is done, I have now also fixed a slight movement issue whereby after a left/right jump, the walking animation didn't reset and the jump left/right sprite remained making it look as though the player was sliding everywhere.

If you're wondering why the sliding issue took so long to fix (it's been this way since August last year!), that's simple because after a joystick movement, the player movement routine checks what current sprite is being displayed and makes decisions on what sprites to display next based on that.  Since the jump up/fall down sprite has only just been done, now was the time to fix it!

I regard the control system in Chiller 2 quite simple, but it's still a bit of a maze of checks and conditions!  Please spare a thought and admire games with much more complex control systems!

Next diary entry...


Tuesday, 25 February 2020

Dangerous Scenery

Another piece of the gameplay puzzle has finally fallen into place!

It's not really been necessary to do it until now since some gameplay mechanics just get in the way of testing and debugging, but I have now coded the, er, code that detects 'dangerous' scenery around the player and drains energy if touched.  The main 'obstacles' in the various levels are mushrooms and pools of green slime and if they are walked upon, energy is subtracted.

I've tried to be fair however; the detection is quite 'loose' and you can jump up near or through such scenery without being penalised, with the energy drain only occurring if the player directly walks on such scenery.  However, on some levels the mushrooms may be 'reversed' chars and appear only as silhouettes amongst other scenery; they can be quite difficult to spot in the heat of the action and will probably annoy those who go charging around without stopping, looking and thinking!

Here's how it looks in action (the animation below also showcases the first outing of the girl player, who is now selectable from the title screen!):



The scenery collision detection reuses values calculated from the gravity subroutine so checks what is underneath the players feet.  There is a bit of a cheat going on - the subroutine is not checking the mushrooms directly, but 'special' chars underneath the mushrooms that trigger the collision!

Next diary entry coming soon...

Saturday, 22 February 2020

Level 10 Design

To wrap up my short break from work, late last night I completed the design for Level 10, set down in a basement.  As ever, the design is likely to change slightly once proper testing begins, but it already look and 'feels' good to me!

The level includes some pipework and conduit; anyone who knows me knows my love of 8-bit pipes in games!  The pipes pump out some green slime which drains your energy on contact.  Also new to the scenery are some wooden boxes and some wall chains.  I may well add some extra detail later on, depending on whether I have many chars left.

The basement looks a little like this at present...


Although I still need to work out the cross locations for Level 4 onwards, I've have now added all the enemy paths and pattens for all the levels, including Level 10.  Here is Level 6 (The Cinema) with it's enemies inserted...


Next diary entry...

Friday, 21 February 2020

Level 7, 8 and 9 Design

I've been away for the week, but took my laptop with me so I could carry on designing more levels for Chiller 2!  Take pity on my long suffering wife!

Level 7 is set in a park and features the rain from an earlier level expanded to fill more of the screen.  I do intend to go back to this level and add a bit more silhouette detail once I've designed further levels - I don't want to run out of chars too early!  The park level looks a little like this (excuse the lower quality screen-grab as I'm getting worried about sharing too much of the game)...


Level 8 is set underground in a sewer!  This level features an expanded version of the slime pools from the cemetery level, with additional slime 'falls'.  As with the park, more detail may be added later when I get a better idea of how many chars I will have remaining after the majority of the levels have been designed.  The sewer looks like this (although some modifications have been made since this grab)...


Level 9 is set outside and features a log cabin.  All the best horror films have a cabin in the wood scene don't they?!  The great thing about this level is that it was pixelled using practically all existing chars, leaving me chars for future use!  The log cabin looks like this...


I've also already started designing Level 10, which is set in a basement and will feature more slime oozing from a feature I have a slight fetish for - 8bit pixel pipes and conduits!  More on this soon!

Next diary entry...

Saturday, 15 February 2020

Level 6 Design

Hot on the heels of designing Level 5 a couple of days ago (read here...), I've only gone and designed Level 6!  This level is set inside a cinema and is a call-back to the original game, which also had a level inside a cinema.

The original Chiller level had a slightly odd perspective, with a screen in the distance and chairs that decreased in size the closer to the screen.  When static, that kind of looks fine, but when your character sprite approaches the never changing cinema screen, the sprite stays it's original size and things tend to look all strange then.

In Chiller 2, I've drawn a screen at the top of the display and chairs on platforms all around, with no perspective tricks tried at all.  I have reused, albeit with different colours, some of the staircase chars from Level 4 (The Haunted House) for some variety. And to combat the original game having a cinema screen that never changed, my cinema screen will have a very simple animated noise effect, with flickering black and white pixels - truth be told, this is already coded and working!

Here's what the level looks like in my editor, ChillED...


As an aside, I've now altered the code slightly so that each level can have it's own 'timer' for the background animations.  Up until now, all the background animations (flame, rain, slime, etc.), have shared a timer and been updated every fourth frame, which has been fine until the cinema screen 'noise' was coded up and ended up being too slow.  Thus, each animation has now been tweaked to a more suitable speed for what it's displaying.

Also, I cannot tell a lie.  I've installed a cheat mode whereby pressing up on the joystick skips to the next level!  Hey, the game is getting bigger now and it's the only way I can check that everything is working properly!  This cheat will be removed before release!

Next diary entry...


Thursday, 13 February 2020

Level 5 Design

In the diary entry called 'Level 4 Design', I described that level as 'the toughest so far'.

Forget that!

I've just designed Level 5, set outside in a cemetery and it's an absolute pig of a level!  Virtually all of the enemies are in your path constantly, the platforms are quite far apart and are peppered with mushrooms ready to drain your energy AND now there is a new introduction to the gameplay - small pools of green slime that, although can be walked on, drain your energy just like the mushrooms!

I've already added the enemy paths and just need to enter the cross locations in hex.  I really may need to make this level a little easier; it may not look that hard but playing it is something all together different, particularly if your energy is low!  At the moment, the cemetery looks a little like this...


Next diary entry...

Friday, 7 February 2020

Level 3 Crosses

Another Friday rolls around and I treat myself to another 'feet up in the office, drink coffee and work on the game' day.

This time I've worked on the coordinates for the crosses that will appear on Level 3 (The Apartments).  Even these days in this world of technology, there is something therapeutic about working on paper! 

Later this evening, these hex coordinate locations will be typed into the data table for Level 3 crosses!  There are actually more locations here than the required 20, but that just gives me more choice!


Next diary entry...

Tuesday, 4 February 2020

SFX

I've been thinking about how to incorporate sound effects in the game since, when writing the music recently, I've kept the in-game music to two voices to enable this.

After reading my digital copy of Compute's 'Mapping the 64 and 64C', specifically the sections relating to the SID registers, I thought it might be easy to shove some data into said registers and see what happens!

After a bit of fiddling, low and behold, I made noise!  It really was as simple as writing a short routine that inserted some previously created values for the waveform type, pitch (note), attack/decay and so forth into their associated registers and then changing those values over a short period of time using another small routine.  It did sound a little like Paradroid to start with though!

Next, I inserted these little routines into my Chiller 2 code and called them when certain actions were performed, in this case when the player jumps or when crosses are collected.

It worked!

But... problem...

It seems that, even though I had kept a voice free on SID (in this case voice 3) for the effects, the GoatTracker music driver still writes values to the voice 3 registers, effectively neutering my sound effects.  Damn...

After a bit more reading around, it turns out that GoatTracker has a sound effects routine built in.  I've read the GoatTracker help file a few times over the years, so how the hell have I ever missed this information about sound effects!?!?  So I investigated this and within about 20 minutes, had sound effects playing using this GoatTracker routine!

The process goes a little like this:

When exporting your music file from GoatTracker as a .prg to include in your code (press F9), there is an option to enable the SFX player. Do this and once saved the SFX module is now part of the overall music file.  This does add about 150 bytes to the overall file size.

You then create your SFX exactly the same way as creating instruments in GoatTracker.  These instruments are then saved from within GoatTracker.  The instrument file is then converted to a sound effect using a tool bundled with GoatTracker called 'ins2snd2.exe', which gives you a text file with the associated hex data for the sound.  There are a couple of rules to follow for the tool to be able to convert the instruments to effects, but you'll have to read the GoatTracker help file yourself for those!

Currently, the data for my jump and collect SFX look a little like this...


; sfx data (lower the sfx data, the higher play priority it has)  
   
 sfx_jump  
     !byte $38,$F6,$04,$A0,$21,$A0,$A0,$A6,$A6,$A6,$20,$A9,$A9,$A9,$A2,$A2  
     !byte $A2,$A6,$A6,$A6,$A9,$A9,$A9,$A2,$A2,$A2,$A6,$A6,$A6,$A9,$A9,$A9  
     !byte $A2,$A2,$A2,$A6,$A6,$A6,$A9,$A9,$A9,$00  
       
 sfx_collect  
     !byte $00,$89,$04,$A2,$41,$A2,$A2,$A6,$A6,$A6,$40,$A9,$A9,$A9,$A2,$A2  
     !byte $A2,$A6,$A6,$A6,$A9,$A9,$A9,$A2,$A2,$A2,$A6,$A6,$A6,$A9,$A9,$A9  
     !byte $A2,$A2,$A2,$A6,$A6,$A6,$A9,$A9,$A9,$00 


To play the effect, you then insert a small simple piece of code that is triggered when, for example, the player jumps or collects a cross.  Something like this...

  
 lda #<sfx_jump       ; start address of the effect  
 ldy #>sfx_jump  
 ldx #$0e             ; 0, 7 or 14 for channels 1-3 (channel 3 use here, or $0e)  
 jsr music+$06        ; music = memory location where music is stored in memory  
                      ; sfx player is at +$06!


So Chiller 2 finally has some sound effects!  I've purposefully kept the sounds quite low in the 'mix' (quiet) currently, since both the jump and collect will be played quite frequently and I don't want to annoy the game player!

Sound effects... TICK!

Next diary entry...