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

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

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

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

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

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 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 3 Origins

It's felt like time to work on another level design because I've been a bit tired of looking at the forest and the church levels for the last month.  Since the first level was exterior and the second interior, I guess it makes sense for the next level to be exterior again?  That wasn't planned at all, but that's how it seems to be panning out...

In the original "Chiller", there was a level called "The Ghetto" and I wanted to do a "call-back" to this, so I spent this morning starting the design for a level that I'm calling "The Apartments".  Using the word ghetto these days would seem a little non-politically correct.

When I say starting the design, it ended up being an almost complete design for the level, save some modifications that will probably need to be made to platform spacings, mushroom locations and some other embellishments (once I've thought of them).

The original brief to myself (i.e. what I dreamt up 5 minutes before pixelling commenced) stated that the window ledges were to act as the platforms and there was to be a couple of different coloured buildings for contrast on screen.  Drawing the the fence, brick and window chars took no time at all and I had a basic layout within half and hour.  However, it did look a bit plain with an all black background, even with my star, moon and cloud chars drawn in.

Then I had a brainwave, well as about as wavy as my ageing brain gets these days.  Make the sky a different colour to previous levels and since this game is supposed to be set at dusk/night, dark blue made sense.  I copied and reverse some existing chars (clouds, stars) to set on the night sky and then, as another "call-back" to the games of yore, used black chars to pixel in some silhouette skyscrapers in the background.  What old games inspired this?  Think "Ocean Software" and "Robocop".  Consider this level, therefore, my "love letter" to those Ocean games that gave me hours of pleasure as a young teen.

Here is the level as it exists at the moment in "ChillED", my screen editor.

My Grandson did give it an initial thumbs up when I showed him this afternoon and wanted to "play" it straight away, but I still need to export the screen and colour RAM data and add it to my level data "includes" file.  And then code the level set-up.  That will be another day.

On a side note, after giving the initial level 3 design the thumbs up, my Grandson asked to play a few games on my C64mini, so we transferred the latest build of game over as well for a quick test.  Chiller 2 seems to be C64mini compatible so far as well!  ;)

Next diary entry...

Animating Chars

When I first designed the church interior layout for level 2, one of the little background features I added to "fill the gaps" was a flaming wall torch.  I say flaming, but originally as designed, the flame was static (see gif's in previous diary entry).

This has now been bugging me for a few weeks; nagging away in the back of my head somewhere has been a little voice muttering, "You want that torch animating really, don't you?".  Being new to 6510 coding, I didn't want to start bogging myself down with extras (feature creep?) but it REALLY has been annoying me that the flames don't move.  So today the investigation/research into character animation started.

And I wish I'd done it earlier because it turned out to be rather easy!  First, here is the code I came up with to "fan the flames" so to speak...

 ; background animations subroutine ---------------           
   
 process_bkgd_anims  
             
           ldy bkgd_timer           ; load up the bkgrd anim timer  
           iny                      ; increase it by '1'  
           cpy #$04                 ; is the timer equal to '4' yet?  
           bne bkgrd_anim_skip      ; no? don't update animation!  
                                    ; yes? better do some animation then!  
           ldx #$00                 ; zero x register  
 flame_ror  
           lda $2390,x              ; load mem location of the flame char  
           lsr  
           lsr  
           lsr  
           ror $2390,x              ; shift char to the right a pixel (bit)  
           ror $2390,x              ; and shift again 
           ror $2390,x              ; and again               
           inx  
           cpx #$08                 ; all 8 bytes done?  
           bne flame_ror            ; no? do the next byte then!
                                    ; yes?  
           ldy #$00                 ; load y register with '0'  
 bkgrd_anim_skip                    ; to reset bkgrd anim timer and...       
           sty bkgd_timer           ; store y register to bkgrd anim timer  
   
           rts                      ; return to main loop

The code above includes a timer (bkgd_timer) that slows the animation so it only executes once every 4 (TV / screen refresh) frames otherwise it animates rather too quick to be visible!  How does the rest of it work?

First, where is the flame in memory?  Well, when assembling my code, my character set is loaded to $2000 in memory.  My flame character is number "114" ($72) in the charset - the blue boxed char in the image above, also shown larger in the magnified section in the right hand side of the above image.  Each char is made of 8 bytes (8 rows, or bytes, of 8 pixels, or bits), so 114 x 8 = 912 ($390).  Therefore, my flame char should be at $2000 + $390 = $2390 in memory.

In the 6502 instruction set there are a few handy commands called LSR, ASL, ROL and ROR.  These basically allow you to shift bits of a byte left or right.  When it comes to character sets, this has the effect of "scrolling" a char block left or right 1 pixel, while "wrapping" around within itself.

This is something I'm still coming to terms with; being a graphics person originally, I still think of images (pixels) moving up, down, left, right and so on.  But as a coder, you need to thing of bits and bytes of memory moving around, which is what is really happening.

And it's as easy as that!  In my code you can see the starting memory location of the flame char being loaded, then the starting location is LSR'd / ROR'd 3 times to shift the char (memory) 3 pixels (bits) right.  This is done 8 times overall so each row (byte) of the char is shifted.  Why 3 times?  Well, that was just experimentation.  After pixelling my flame, the overall shape of it suggested that it should be "moved" 3 pixels right every 4 TV frames (screen draws/refreshes) to get the best "flickering" effect.  I did try other combinations, but the above worked best for my flame char.

And what does it look like?  Savour the animated gif below (disclaimer, the animation looks better than the gif suggests, honest!)...

Next diary entry...

Level 1 Design

After a couple of false starts, I've spent the last few days off and on using my screen editor 'ChillED' to construct a level for the game, set in the forest - since the original game starts in a forest, it seems appropriate for the sequel to as well?

No doubt the layout will change considerably due to circumstances I've not foreseen yet (probably to do with code or gameplay restrictions), but I'm fairly happy with what I've come up with.

Here is a little animation of how the level was built up; most of the stages are here, with only a few left out that only had minor differences from a previous save.

EDIT:  After posting this, I decided to use Photoshop to overlay some of the sprites on the current final version of level 1 and post on Twitter.  There seems to have been some pretty good feedback, with some nice responses!  Anyway, the image that was posted on Twitter is below and a link to the actual Tweet is here...

Next diary entry...

ChillED Data Export

Been building to this, a feature for "ChillED", my screen editor, that will enable me to put screens/levels straight into the game with ease: screen and colour RAM data export!

The data format is simple text, but it includes a "byte!" label at the start of each line to copy and paste straight into my ACME formatted source.

Here is the feature in action:

To be honest, the export has been working for the last few days and I've been using the editor to pixel some PETSCII screens and have been exporting them to some hastily written display code which has then been tested on my C64mini.  Here is a very quick version of R2D2 pixelled in ChillED, data exported to my rough code and being display on my spare TV using the 64mini...

All appears to be working nicely!

Next diary entry...

Screen Editor

A few days ago, I was on IRC chatting to Jon "Moloch" Mines about my game project again and have showed him some initial screen mock-ups.

I have begun experimenting with a background layout using the Arkanix Lab map editor, "CartographPC", or at least an early unreleased rewrite of it that I've been working on.  Since the original game "Chiller" started in a forest, I've decided that so should the sequel!  Here is a *very* early version...

While working within the "CartographPC" unreleased rewrite, I decided to "fork" the PureBasic code and create a new tool specifically to create single screen levels for my game.  The intention is that the new tool will have features such as the ability to export screen and colour RAM to use directly within the ACME based code used to create my sequel to "Chiller".

Thus, my new screen editor "ChillED" is born.  See what I did with the name there?!  The editor looks a little like this...

I've begun using it already to recreate the background I was working on in "CartographPC", but there is still a lot of work to be done on the editor till it's ready to begin creating "real" levels!

Therefore, if the diary appears to be updated very infrequently over the coming weeks, its because I'm coding "ChillED" for my own needs!

Next diary entry...