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...
Showing posts with label level. Show all posts
Showing posts with label level. Show all posts
Saturday, 22 February 2020
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...
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...
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...
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...
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...
Friday, 17 January 2020
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...
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...
Thursday, 28 November 2019
FREEZE64 Christmas Demo
A few days ago, Vinny, who writes the really rather excellent C64 fanzine 'FREEZE64', messaged me on Twitter asking for a few screen grabs of Chiller 2 in action. He is going to send an email out to his subscribers on Christmas Eve and will include some information about the game, along with said screen grabs. He will also publish the URL of this blog to the "wider world". Up to this point he is one of a very small, select group of trusted people who even know that this humble dev diary exists.
I should say at this point that Vinny has been very supportive "behind the scenes", offering lots of encouragement and interest. Because of this support, I thought it might be a good idea to offer him an exclusive download as a thank you.
So currently, I'm stripping out all code pertaining to everything other than the title screen, level 1 and any display routines. The result will be the first playable demo of Chiller 2. I am limiting some things because I don't want to give too much away in this demo. Thus, only a partial charset is included with the minimum number of sprites needed. The music is a very early version of the main title screen music and amounts to about 10 seconds worth on a repeating loop. If you play the demo and it drives you mad, tough!
As a bit of an afterthought, since this demo is an exclusive Xmas gift from FREEZE64 to it's subscribers and also riffing on the FREEZE title, I've decided to make the text in the demo white and various hues of blue, while adding settled snow and ice to the forest level. I've also altered the "Chiller 2" sprites on the title screen to read "FREEZE64". Why am I explaining this? Surely some images would be better!
Next diary entry...
I should say at this point that Vinny has been very supportive "behind the scenes", offering lots of encouragement and interest. Because of this support, I thought it might be a good idea to offer him an exclusive download as a thank you.
So currently, I'm stripping out all code pertaining to everything other than the title screen, level 1 and any display routines. The result will be the first playable demo of Chiller 2. I am limiting some things because I don't want to give too much away in this demo. Thus, only a partial charset is included with the minimum number of sprites needed. The music is a very early version of the main title screen music and amounts to about 10 seconds worth on a repeating loop. If you play the demo and it drives you mad, tough!
As a bit of an afterthought, since this demo is an exclusive Xmas gift from FREEZE64 to it's subscribers and also riffing on the FREEZE title, I've decided to make the text in the demo white and various hues of blue, while adding settled snow and ice to the forest level. I've also altered the "Chiller 2" sprites on the title screen to read "FREEZE64". Why am I explaining this? Surely some images would be better!
Next diary entry...
Wednesday, 28 August 2019
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...
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...
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...
Monday, 13 May 2019
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...
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...
Friday, 12 April 2019
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...
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...
Subscribe to:
Posts (Atom)


















