Two Level Demo

It's been a difficult couple of weeks for everyone (and by that I mean the entire World) with the onset of Covid-19 across the globe.

Therefore, to spread a little bit of love and cheer, I've decided to release a 2 level demo version of Chiller 2!

First a word of warning!  The game has not undergone extensive play testing yet by anyone else other than me, so some may find it a little hard!  After the play testing is complete, there are lots of tweaks that can be made to make things easier if required.  It has already been discussed that perhaps energy will be reset between levels and/or energy being 'topped-up' during play somehow.

This demo aims to give a little taster of the type of game it will be!

On the title screen, select either to play as the boy or the girl by pulling left or right on the joystick.  The boy is ' stronger' than the girl so can take collisions and lose energy a little slower than the girl.  However, the girl is a little lighter than the boy, so when jumping will stay in the air just a fraction longer making it easier to cross larger gaps or reach higher platforms.  Choose carefully, then press fire to play!

The aim of the game is to collect 20 crosses on each level to progress to the next level.  Each cross collected adds '1' to the cross counter in the middle of the status panel at the bottom of the screen and '100' to your score on the left of the status panel, as in the screen below.

Move your character around the level using the joystick, left and right to move.  A single fire button press activates 'jump'.  Holding down fire enables a double-jump; some 'platforms' may initially appear too high to reach with one fire button press so holding down the button and double-jumping means the character will jump up to the platform and then jump again.

Gravity is always active in the game, so walking off the edge of a platform will result in your character falling down the screen.  There is no limit as to how high you can fall from and no energy is lost.

If your character touches an enemy or certain parts of the scenery such as mushrooms, then energy is lost from your energy bar at the very bottom of the status panel.  Collision with enemies is quite 'loose' so they can often be passed without energy loss even if a few pixels are overlapping.  Mushrooms will only drain energy if they are walked over or fallen on.  You can jump up through or past them without energy loss.

A few tips!

Although the player character can move relatively quickly, rushing about is a guaranteed way of losing energy very quickly, ending the game.

Each level has been purposefully designed to be a type of 'puzzle' with some routes through being more optimal than others.  Take your time and plan your path; there is no time limit so you can stop and think.  Use strategy!  There are safe places on the levels where you can stand without fear of enemies crashing into you!

While stopping, watch and learn the enemy patrol routes.  Timing your jumps between and over them will result in more success!

The game ends when you run out of energy.

Please have fun, but more importantly, ensure you and your loved ones stay safe during these troubled times.

To play the 2 level demo, you can download it here...

You can also download the game preview from CSDb here...

TRIAD have released a cracked version which you can download from CSDb here...

Next diary entry coming soon...

Machine Detection Intro

I've spent twenty minutes today adding a *tiny* (and simple) little intro screen to the game before the main title screen appears.  This intro displays information about the type of machine the game is being played on as detected by the code added yesterday in the previous diary entry here...

This intro informs the user the machine type being used (PAL or NTSC) and the fact that the music and sound was designed for an 8580 SID chip.

It also gives me a chance to use the 'Cosine' sprites that I designed months ago and that have been languishing in the sprite bank unseen and unused up until now!  The sprites and messages look a little like this when running in WinVICE using NTSC...

Obviously, the message changes to PAL if such a machine is being used.

I'll own up to hacking my own code a bit!  The game essentially uses two 'modes', title screen on or title screen off, which is stored in a label called 'title_mode'.  When title screen is off, the game is in play - the two modes use slightly different code branches.  For example, the colour washing of text on the title screen is handled in one of my IRQ splits, but when the title screen mode is off, the colour washing code is skipped.

However, for this little intro and for various reasons, I need to run a little portion of title screen code and a little portion of game screen code, so there is now an intro check to skip or add certain elements and I admit to doing this in a quite hacky, yucky way!  It works, but I may need to recode this as it's stirring my OCD tendencies!

Next diary entry...

NTSC

I'm guessing that this little game of mine will mainly appeal to people in Europe (hopefully!), but since I'm part of a C64 group (Arkanix Labs) that is U.S. and therefore NTSC based as well as a U.K. and PAL based group (Cosine Systems), I would feel a little disloyal towards my American cousins if I didn't include compatibility for NTSC systems.

If you don't know anything about NTSC, then do some research possibly by starting here...

Basically, NTSC machines run at 60Hz instead of 50Hz as on PAL.  Also, they have fewer display scanlines, 262 versus 312.  For my game, this means that my blue top border I wanted for 2 levels and which works nicely under PAL (see diary entry here...), starts waaay too early on NTSC and appears at the bottom of the screen, something like this...

To combat this, I've included an extra IRQ split in the top border.  Thus, the first IRQ split colours the background (therefore border area) black to eliminate the blue at the bottom of the screen under NTSC and the second IRQ split, which starts just as a PAL machine begins displaying the visible area of the top display, then colours the background blue.

Miraculously, this seemed to work!  Well, in WinVICE at least - I'll have to wait for my NTSC friends to test on real hardware for me and report back to be sure!  At present, it now look like this under NTSC in WinVICE...

Adding an additional split did have a knock on effect on some other timings; since the NTSC display has less screen time to execute in it seems, the title screen code was over-running and everything was slow and flickery.  A little rearrangement of some of my IRQ code later and all was back up to speed!

The other NTSC issue is the music.  Since NTSC machines run slightly quicker, the music was playing too fast and sounded awful.  Therefore, I've coded up a timer/counter that skips calling the music driver every few frames thereby slowing it down.  Of course, the game needs to know what type of machine it is running on, so I've now included a check at the start of the code to do this.

I've used a modified version of code that was posted on CSDb so thanks to all those involved in that discussion and who shared code, which you can find here...

Next diary entry...

Player Characteristics

I still need to calculate coordinate locations for crosses on many levels and seem to be putting this off at the moment, mainly down to the fact I find it rather boring...

However, I'm putting this task off by actually tweaking and/or adding code to other sections!  Honest!

The girl finally became 'properly' selectable/playable the other day and until now has shared characteristics with the boy.  But no longer!  I've altered certain variables so that when the girl or boy are selected they handle slightly differently.

The boy is slightly 'stronger' than the girl - he can be in contact with enemies or dangerous parts of the scenery for just a few milliseconds longer before experiencing an energy drain.

The girl is slightly 'lighter' than the boy - although she can jump no higher, she can stay in the air just a few milliseconds longer than the boy, making it a tiny bit easier to successfully make the longer jumps between platforms on some levels.

Those differences above are only subtle, but does give the player some choice as to how to play - do you choose easier jumps or more strength?  No doubt the variables will be altered further once play testers get their hands on the game and maul my efforts to death, but it will be easy for me to change in the code now since it's all handled by a couple of labels.

I've also finally got round to moving my screen splits slightly to accommodate the fact that on two of the levels (Level 3 - The Apartments and Level 7 -  The Park, if you're interested!) I've used a blue background.

I wanted to 'extend' the blue sky background into the upper border, an easy task since the top border is open, but not-to-hot looking because the split was in the wrong place, therefore the blue colour 'bled' too far down the screen.  Also, the blue was appearing on levels where the background and top border should have been black.

It was simple fix in the end - the two levels needing a blue top border set a flag telling my top border split to colour itself blue, otherwise colour itself black.  The result on Level 3 looks like this...

Next diary entry...