theC64 Challenge: #6 Para Lander DX - Part 1 / 3

1st April - 13th April 2021 

First of all, you may noticed that I deleted the previous dev-blog entry based on this project. Sorry about that, but I wanted to try and squeeze things down more and give you slightly less to read.

You may remember back in December 2020 I wrote a couple of games for the Cassette 50 Charity competition and I submitted them into the competition. The two games were Rocket Away (source code now lost) and Para Lander Mini (Created on theC64 in Turbo Assembler). 

During the Easter holidays, I felt like setting myself a challenge in creating an enhanced version of Para Lander Mini and write Para Lander DX. I was quite font with the development of Para Lander Mini. I also felt that this game could have looked and felt much better if I enhanced it. Since the source code was still on my USB I decided to set myself a new theC64 game development challenge to make it happen.

I chose to develop the game fully on theC64 using the following C64 applications:

* Faces Sprite Editor V1.3 (Sprites)
* Jon Well's Multi Screen Construction Kit (Charset graphics and game design)
* Face Painter V1.0 (Title screen logo)
* DMC V4.0 (Music composing)
* I-Relocator (Music relocating)
* Starion Text Editor (Scroll Text Writing)
* Action Replay MK VI cartridge plugin (Freezer and M/C monitor usage)
* Style's Turbo Macro Pro V1.2  (Programming) 
* ECA Compactor/Linker V4S (Packing/Linking)
* Cross' Cruel Cruncher V2.5+ (Crunching)
* Loader Game Tape Master Kit V3 (On the Ultimate 64)

The cross development applications used:

* Notepad ++ (Writing code and batch files)
* 64Tass cross assembler (Compiling code)
* Style's Dir Master (Disk Mastering)
* Exomizer V3.1.0 (Packing/Linking/Crunching)

The majority of the game was developed using those applications above. However there have been cases where I had to move source to the PC and use Notepad and 64TASS, more about that later as we get along through this feature.

Preparation

In order to prepare myself for this project, I needed to use Style's DIR master utility to create blank work disks (Since that cannot be done on theC64 itself). Then I imported all of the applications to the utilities .D64 image. I also made a .CJM file to disable the accuratedisk function, and allow fullheight mode. This is because by default I set theC64's root directory to use those functions. Once ready, I ejected the USB stick and placed it into my theC64. Then I attached the Action Replay MK VI artridge plugin to theC64 via the media manager. (I also own the original physical cartridge).

The graphics

The first stage was to prepare the game graphics. I started by using the Faces Sprite Editor V1.2 to draw the game sprites. The main sprites were the helicopter, the player, splash frames, platforms, Game Over and Well Done messages. The Game Over and Well Done messages consists of the game sprites.

The second stage was preparing the main game background and game scene graphics. I chose to use Jon Well's Multi-Screen Construction Kit for this task. As there were not many screen editors that allowed me to design screens and background objects the easy way MSCK did. I designed the text character sets and screen background objects then saved to disk as charset, object and screen data and also colour data. (Note: The pic below was an earlier layout of the game's graphics. The final result is a bit different).

Next on the graphics part, I pressed the Power + Right Shift Key on my theC64 to activate the Action Replay Freeze mode. Then it was time to enter the machine monitor and type in a small routine that will grab the colour and screen data and paste it into memory. I executed it and saved the colour and screen data onto a disk. 

Making music

I cheated a little where it came to writing music for Para Lander DX. I did use DMC V4.0 (As by far it is one of my all time favourite C64 based music editors and I used it since the mid-late 1990's). You may noticed that I imported all the utilities into the D64, but what I did not mention was that I imported my Happy Blocks music into one of the work disks. After loading Happy Blocks. I cleared the old music and written all the title and game music. The result turned out great. It made me feel great also.

The Game Code

The easy stuff was all done and dusted, so now it was time to get into the hard stuff. The game code. I did a zero memory fill of the C64, using a hard reset. Then I went into the Action Replay fast load option and I loaded the desired files into memory:

* Game graphics charset = $0800
* Game music = $1000
* Game sprites = $2000
* Game screen and colour data capture = $2800

Next I loaded up Turbo Macro Pro and got programming the game from source I did when I made Para Lander Mini in December. The first part was to remove a lot of the old subroutines from the game. I used the linefeed delete option. Next I produced a routine that would display the new graphics onto the screen. This was called by reading the game screen and colour data capture from $2800-$2be8 and colour data capture $2c00-$2fe8 and place it into the screen and colour RAM ($0400-$07e8, $D800-$DBE8). Then I run the source.

Setting up the new game graphics data

Having the graphics data to display worked more or less. However while the zeppelins were being dragged across the screen (using the old source interrupt code) the colour did not move. I got back to the code and I decided to cheat a little by creating a routine that writes the character colour of the zeppelin to the whole row of the C64's colour RAM. I repeated it with the other zeppelins. Everything was working great. I saved the code again.

Scroll them like you should

The colour layout was sorted out, but the zeppelins were still dragging across the screen in a rough fashion. Just like the Cassette 50 Charity Competition entry. Something needed to be done about this. I edited IRQ code to give it some multiple interrupts. There were five in total. Then in three of the interrupts raster splits, I set the target speed stored from the hard scroll routine and stored it to the horizontal scroll position ($D016). After running the source code, the zeppelins were moving at a much smoother pace. I was very happy with the result.

Animation

The next step was to deal with the sprite animation. The helicopter, the player and the happy landing sprites all consist of 4 sprites. For the sprite animation the pointers needed to be set and so had the tables for each sprite frame. A subroutine was required to be added to make the animation happen inside a loop. Then of course the animation should be stored to the actual sprite number that was being used in the game. After a few simple routines, I got the sprite animation to how I wanted it.

The other routine that was missing was the character animation. The water was still and the reeds in the background were still. I created a subroutine that could animate the characters. The reeds had to scroll up, and the water had to scroll left. There is something I did not mention about, regarding the IRQ. The botttom IRQ background colour was set to blue to blend in with the water.

Splash down

My next task was to generate a scene that breaks a looping code, and creates a new loop that causes the player to fall to its death and splash into the water. This event takes place every time the player hits a zeppelin. Also the water splash was another scene for itself.

Yippee

There was another part in the game code where the player lands onto the launch pads, the player disappears. I wanted to do something more fun, so I created a little routine which made the player jump for joy then disappear. However I did not want the pads to disappear. Instead I wanted them to go into the water. With a little tweak of code that was done.

Great the main game play was dealt with, but what about scoring? I moved the score panel to the bottom of the screen. Just as I was about to generate a score routine. Turbo Macro Pro got messed up at the bottom. I ended up with garbage. I estimated it as running out of memory for game code. So I decided to move the code to 64TASS and use Notepad ++ to update and fix the game code. Then after adding the time routine and scoring routine. I exported the assembler file back to thec64 and re-assembled with Turbo Macro Pro. Awesome, I have a working score and clock and lives counter.

Status

Although I had a working clock, there were a couple of things mission. The Game Over and Well Done routines. I got the player to lose all lives but no GAME OVER. I got the player to complete all six pads, but no WELL DONE. Just a flashing inc $d020 jmp *-3. I created a couple of routines that awarded bonus points to the player. Then I placed two sprites Well Done on level complete and Game Over. I got those to flash and then saved everything. I was very happy with the game. It was time to save all of the code and move on to the next step. The front end.

Designing the front end

Not much had to be done here regarding front end design. I did have something missing. A logo. I loaded up Face Painter V1.0 and I got working on a logo for the game project. Like with Spider Maze and a couple of my other game projects. I created a basic logo for the title screen. I filled each character with one colour. Then I painted the characters with a few colours. The Commodore 64's multi colour bitmap mode can only allow 3 different colours and the main background colour in each cell. The result looked pretty good for someone who is not really an artist :) After finishing, I saved it as a Vidcom image (Using Action Replay's Screen Grabber).

Writing a scroll text

I loaded up Starion Text Editor and wrote down my scroll text for the title screen. Basically it was all about the credits, game instructions and also the usual scrolling messages.

Making a title screen

Having a logo may have been easy enough, however something needed to be done to it. The game was missing a front end. I loaded all the game data (as before) and then I loaded up Turbo Macro Pro V1.2 again and I started programming the front end. I wanted to make a front end which contains a scroll text and some credits. However I wanted to also include the game background graphics, and a bit of flashing text. Well, eventually that did happen. Here is the result below:

Hi Scores

Although I was nearly here, in exactly the same code I prepared a high score table. The high score table data was made by using a normal basic screen, an Action Replay freeze, and in the text editor I set up the table and noted down the values for each name and list. The high score name detection had to be changed a few times, due to a lot of problems I have been having with the zeropages. I even tried the longer method, but it left too many bugs. I decided to re-write the Shock Raid hi-score name entry routine but I used different zeropage values. It worked nicely. Next I manually linked the hi-score name entry to the game code. The name entry routine was keyboard based. This was actually the most easiest part in the name entry. Especially when the whole game project was using Kernal routines and IRQs ($01 = #$37).

Hi Score Disk Access

The final part of this task was to create a high score saver/loader routine. This part of the role had to be done in 64tass. This is because I wouldn't have known if theC64 was writing / reading the high score table. This is because theC64's accuratedisk mode has problems. So I had to rely on 64tass. I did many versions of the hi-score loading/saving code but it just didn't go very well. There were a lot of crashing going on. This had to be investigated, but I realised I used routines and zeropages I should not have used in the game, that caused it to crash. Finally this got fixed.

Compiling - Oldschool Style

Well, finally I get to compile, pack and crunch the project. All of this which I decided to do on my Ultimate 64, due to the features it has. I loaded up the ECA Compactor/Linker and packed the whole chunk of game data with this program. (And also endured the noise while doing the job). Then I set the jump address of the disk loader ($5780) and saved the packed file.

Next I loaded up the Cross Cruel Cruncher V2.5+. I typed in a 1-liner de-crunch text and set my Ultimate 64 into 48MHz mode for high speed crunching. - I set the jump address to $0810 (The jump address of the ECA Linker's de-packing routine) and then crunched the program. It only took a few seconds, whereas if it was at 1mhz mode, it would have took about 15 minutes. I saved the game to disk. I tested it and run the game. Result. I have a full working game. 

Is the game ready to release? ...   Not yet, you'll find out in the second part of this blog. The game will be released. You will just have to wait and see.

March 2021 Cruiser-X Progress Update #2

 27th March 2021

A couple of weeks ago I had left you with where I last left off. It was mainly based on the power ups based system. Now 2 weeks later, more work gets done. Last week, I finished off fixing the SEUCK Title Screen Maker disk, by fixing a bug in one of the example games (Which wasn't the fault of the title screen maker).

This session was mainly based on level setup. Of course I may not have the level graphics yet for level packing, etc. First I have to set up different sound effects for each bullet type the player carries.

I can still start on setting up the level scheme and enemy selection. Last time I managed to get all enemies to appear in order of sequence. Today I have been making a sequence for level 1 of the game. This is now based on the colour scheme table read, and also the alien selection table (based on levels).

After setting up the level routines, the enemies are able to fire bullets but the bullets do not collide into the player. So in order to fix this, a subroutine is programmed in to read the X, Y co-ordinate range of both sprites, and if inside the collision area. The player will die, unless a shield is in place. Then the player respawns.

Well, that looks good, but not really good enough. When shooting at aliens or shooting destructable background characters, The player should score points. A subroutine reads pointers for the player's score, lives and level. Then it copies it to the score panel on screen. I decided to do it this way this time round, because it is a way to prevent the player cheating by freezing the game with the Action Replay cartridge and editing the score/lives value with the screen editor. I cannot code protection routines, plus I cannot be bothered with those anyway :)

The enemy scoring should be based on the enemy sequence value that is used. I set a new table which creates the new score values for each alien, after it has been shot. The values are based as 1-5. Where 500 points is the maximum score which the player can score. Shooting background and collecting power ups also gives the player some points.So can the activation of the player's smart bomb (Which is triggered with the fire button).

The player's lives indicator also needed to be updated to decrement, and when lives have reached 00, the player will lose the game, and GAME OVER commences. Of course even if I was updating score, lives and level pointers (or restarting the game) I would need to update the score panel via a subroutine.  I am happy that it all seems to be working.

Now on to one final problem. The alien spawn sequence is set based on the chosen level, the enemy bullet can now kill the player, the score panel is working. The final problem for today - the aliens are firing too rapidly. How can that be solved? Simple, before randomly selecting the enemy to shoot a bullet. A delay pointer, and delay expiry counter should be set. Adding one of those makes the enemy fire bullets less rapidly. There is a chance I could make a table like with the scoring table, where I could base the enemy firing rate. That might be some time next weekend. We will have to wait and see. But for now, here's an updated video of my work in progress.

March 2021: Cruiser-X progress Update

 13th March 2021

Yet more activity has been taking place with Cruiser-X 79. Well, what has been going on this time round. For a start off, earlier on this week (Wednesday or Thursday evening I think), I have been working on a few features in the game. The previous week (or two) had alien groups added to the game's code. These are not yet set according to level, but this will happen next week. This week was all about the player's capabilities, and also the enemies.

First of all, I have pictured a situation, where I always used the player's bullet to morph into an explosion and transform the alien animation into a blank sprite. This has been a typical case scenario for my C64 games. However, if I were to create a power up that activated a smart bomb feature. This method of explosion seriously would not look right one bit. There is a solution to this problem. I create some macro routines and pointers in order to check whether an alien is dead or active. If the alien is dead, morph the current alien animation into an explosion and then transform it into a blank sprite. After setting up the code for this feature, the trick worked.

Now it was time for the player to get its revenge on those aliens that try and take over the galaxy. In the game's background, there are three different tiles, which the player can pick up in order to gain power ups. Those are marked as S, M and B. Earlier on last time, I had created a border change to test that the player was able to collect the power up characters. Now I needed to put the power ups feature to reality.

The first thing to is generate a subroutine which tests the player's shield properties. I have to make an indicator that will test the player whether it is carrying a shield or not. If the shield is carried, it should be activated on the player. This indicator has been made by using a colour flash table, and also a couple of pointers. The first pointer does a shield countdown. I made the counter countdown the same amount of time as I did with another game of mine (200 - 0). It is more or less the same mount of time the player has invincibility inside a SEUCK/Sideways SEUCK game (Note that Cruiser-X is not a SEUCK game). I have also placed a subroutine which checks whether the player is dead or not. This is in order to avoid the player exploding while it is still exploding. A similar routine has been made to check that the player is still carrying a shield. This is so that aliens or deadly background cannot do any harm to the player.

Now the player's shield is out the way. I need to do something about the player's bullet. Saul did a few sprites, where there are 5 different bullet types which the player can shoot. A power up table was required. I setup the table, and made some pointers in which triggers the table read each time a new power up has been picked up. The power ups grow in size, and the player can shoot faster.

Next there is one more feature I need to create on the power ups side of things. That is of course the smart bomb feature. The player can pick up the smart bomb feature, but something needs to be done to activate it. I programmed a smart little indication feature by re-designing the HUD's layout. Then I created some subroutines that check for the number of bombs the player can carry. There are 3 bomb icons on the right of the panel, when lit in blue - this indicated no bomb available. However when lit in yellow, this means the bomb is active. 

 How do I get to use the smart bomb feature in the game? Well, first of all, the player's auto-fire had to be removed. For some strange reason I could not read the space bar key by checking the value of $DC01 as #$EF no more. There must have been something in the code blocking it. Instead, I had a brain wave. Since the success of my smart bomb feature in Border Blast 3, I thought that I should give it a blast with this game. I created a hold fire pointer, and made it count up to 16. If the counter times out, the smart bomb gets activated, but how does that happen?. I cheated a little with this method by automatically making all of the enemies pointers to reset the animation to 0 for explosion and trigger the enemy is dead function.

That's the power ups. What next? Well, the player can shoot and blow aliens up with one shot. What about the aliens? They can move about, but for some reason, they cannot attempt to blast the player?. Well, I think it would be fair if they can be trigger happy as well as the player. I create a few subroutines that trigger the enemies to fire and select the enemy to fire the bullets.  Unfortunately there are a few problems. The bullet just keeps on firing from the same alien and sometimes the bullet appears before the aliens enter the screen. A solution to this problem. I set boundaries where the bullets cannot be fired. However the same aliens are still firing until out of the screen. How do I solve this? Easy, a random alien select table, and death check routine. If the alien is dead, it should not shoot, and also the same alien object should not fire. Other aliens should also. I set a few more check routines, to ensure the aliens are alive and shoot. The trick worked. No there are no problems with the alien firing.

I'm nearly done for this week on this project, but before I do, there is just one more feature I would like to add into the game, before I update the GitHub with the newer source. I want to make the background flash. Also sort out the player level complete sequence. The player should fly to the middle and move upwards out of the screen, and "Well Done" should pop on to the screen. Also the smart bomb feature should flash. I added a flash table, and linked it to the raster split that triggers the game's background colour. I linked it with the smart bomb count down timer and the feature worked.

Progress is shaping up quite nicely. I'm pleased with the result so far. Next week, I will be working on the level setup code and select the aliens and background colour schemes  for those particular levels. 

February: Progess update - Cruiser-X 79

 27th February 2021

I have been working on a couple of new games as well as this game. The first game is something secret for the Reset issue #14's Mix-I-Disk (Possibly late Spring 2021?!?!). The other project is a game I am making for the final Official C64 SEUCK Compo 2021, which will be released some time in March 2021. The game is quite funny, but will be pretty tough and challenging.  ... but what about Cruiser-X 79? ...   I can tell you that it has been shaping well quite recently. 

Over the past 2 or 3 weekends. I have been busy working on the alien movement pattern routines. There are 40 groups altogether. Some alien group patterns are for the same type of enemy. This mainly occurs with the alien ships and falling asteroids Each enemy routine was tested before I copied it as an actual alien group pattern in the lower area of the code listing.

Okay, so aliens are all done but what about calling each group? Well, that had to be done after I created all of the tables, as I wanted to test each alien wave. After the complete testing, I created a sequence table, and also a custom read table. I also needed to make some new game pointers, related to selecting the alien table that should be read and stored to the actual alien group table. The idea is that when it comes to Saul designing new levels, I select a sequence of aliens by calling a level sequence table, and then copy the value of that pointer to the table read pointer. This will then spawn the new aliens. I tested all 40 alien patterns and all turned out pretty well. There might be a bit of a tidy up with the enemy patterns before the full game is finished. However, it is fine for now..

A little progress update about Cruiser-X 79

7th February 2021

I was asked a few questions this year (and last) "When will Cruiser-X 79 be finished and released". The answer is hopefully later on this year. I had loads of problems with this project over the past few years. If that wasn't bad enough, I had a fatal HDD wipe out on my old PC. The system ws slowing down terribly, and literally made the computer unusable. I completely backed up my important files and C64 projects. I re-installed Windows which had unfortunately completely formatted the HDD . I did do backups of my important files on to cloud drives. However, when it came to restoring those backups after the re-installation. The important documents folders of my personal files, all copied and restored, but for some strange reason, the cloud drives had deleted all of my C64 assembly source code and project files. I had lost everything I worked on for so many weeks, months or even years. This really stressed me out the past two days when the misshap happened. 

A couple of days later I ended up with a new system, so now I was able to properly restore some of my stuff. Sadly I wasn't able to fully restore *everything*, but I was able to restart the game project (and another game project). It was actually a good thing that I started the project from scratch, due to the problems I had with the previous version of the project. I spent about 2 weeks on Cruiser-X 79 restoring all of the test background and sprite graphics. This was all done by going through my old email archives and loading the graphics into Charpad and Sprite Pad later versions. I took the sound and music from the game preview, and reverse-engineered the sound effects tables. Then I programmed the game from scratch. 

The processing of the code took a short while to get the background scrolling in place. Then the player sprite was placed into the code, allowing it to move about and shoot. As soon as I was happy with the player being put in place. The sprite/background collision was being worked on. Unlike the previous preview of Cruiser-X 79. The player was able to shoot at the high walls, obstacles and the player bullet disappears. The player to background collision was more accurate, compared to the playable preview. A lot of progress was made in the 2 weeks. I had the time to make a temporary score panel for the time being.

This weekend I started working on the alien movement attack patterns. First I had to create the alien objects. Then add collision to them. The player could then shoot the aliens. However I needed to think about how the aliens should move. Something of which would suit this type of game. 

You may remember seeing the alien formation group movement in the playable preview. Unfortunately it was just too much like Zap Zone and Star Toast. The majority of  alien movement patterns were made using my Alien Formation Maker V1.0+. I did not want to use the same sort of movement patterns for this game project. The alien movement patterns I had in mind were to be based on time and speed, rather than a full 256 byte X or Y sprite position table. 

Last weekend I created a test alien pattern table.Yesterday, I worked on setting up the alien movement table where the alien pattern was based on the following:

* Start position X (Aliens 1 to 5)
* Start position Y      "      "      "
* Alien frame (Low-byte)
* Alien frame (Hi-byte)
* Alien Colour
* Speed X            
* Speed Y
* Time before reading next byte

Each table was set to 8 bytes. The patterns were fully tested before being confirmed as alien group tables. I was pretty impressed with what could be done as alien patterns. It is more or less a similar method I used with StarFysh, but slightly more optimised. However I have not finished this task yet. Although 19 movement patterns were implemented. I am more or less half way with implementing alien patterns, so hopefully more of this should be done this afternoon.

I am very determined to get this game project finished some time this year. At the moment I have a lot of free time spare, especially during the weekend. The alien patterns are turning out very
nicely, but after the test patterns are complete. I will need to code a routine which will select the aliens to spawn. Then after this, get the aliens to shoot. Once all of this is in place. I will ask Saul for the graphics for the next few levels. Of course, I will need to make a digital disk loader for loading graphics. The maps are quite big and to have 16 levels planned for it. That will be quite a challenge and impossible to squeeze into a single file  ;)

2020 - The year it was

26th November 2020

You may have noticed that this year T.N.D mainly focused on small projects and a couple of PC games also popped on to my itch.io page. This is because I have been trying to learn new skills during the Covid-19 pandemic, while still in search for a light at the end of the tunnel towards a future career path.

SEUCK COMPO 2020

2020 started with the Official C64 SEUCK Compo 2020. It was a C64 community based fun competition in which you could design and develop a Commodore 64 game using the Shoot Em Up Construction Kit. You are also allowed to push SEUCK further by adding enhancements. The competition entries this year were: Guillotine - The Doom Machine (pictured), Synthia and the Cyber Crypt, Fish Pond - Robovox, Lagrangian Point 3, Spearhead and a few other compo entries. Voted as the top 3 entries were: Guillotine, Spearhead and Synthia in the Cyber Crypt, which won the competition. All three games of which got the full enhancements and presentation they deserved.

The Official C64 SEUCK Compo 2020 (including prizes)

SEUCK GAMES AND ENHANCEMENTS

Talking of SEUCK, there were a few of my own and collaboration SEUCK projects that hit the C64 scene. Mega Tank Blasta was a co-op between myself and Alf Yngve. It was a rehash of the original Tank Blasta game, which I made in 2018. However Mega Tank Blasta pushed SEUCK even more with the SEUCK Redux framework. It had power ups, a new score panel and a new oldschool front end. Arcadestation jumped in to draw a nice loading picture for the game. The second SEUCK collaboration was with Leonardo Vettori. It was Nucleo 448 (pictured below). A stunning rehash of Nucleo 447. The game had some upbeat in game music with sound effects blended together. There was also a nice presentation with the original Nucleo 447 music I did for a previous SEUCK compo. The result was absolutely great. Gamers seemed to have enjoyed this game. The final thing I did with SEUCK was a SEUCK Framework, which was done in KickAssembler. This allowed C64 SEUCK fans build new front ends and possible in game enhancements into their own game creations with aid of KickAssembler (Requires Java) combined with Exomizer.

CRAPTASTIC 4K 2020

Craptastic 2020 was a fun 4K game programming compo which I usually enter 2 compo entries a year. Since I had a very busy schedule studying online, etc. There was only one compo entry this year. Zzapped in the Butt (pictured) was a static arcade blaster where you had to defend your cities from being destroyed by incoming aliens. If all cities were destroyed or your ship got destroyed the game was over. I almost failed to submit this game due to the limitations of 4K overflowing to 5K. Exomizer had to be replaced with ALZ64 which did the trick nicely. Sadly the game didn not make it into the top 10. An enhanced full version of this game has been rumoured to be on the cards. You will have to wait and see.

theC64 CHALLENGES

In December 2019 I had a theC64 full size computer as a Christmas gift. I was intrigued to have a go at making games on it. There were three theC64 challenges I set myself this year. Two were successful, but another wasn't but the game still got finished. The first successful challenge title was Storm Chase. A simple little game in which you control a boy in a who has to save the village from being flooded by a mischievous rain cloud. The game project was programmed in turbo assembler. The second game I did on theC64 was the Forever Extending Hungry Snake (Pictured). A crazy snake style game with a difference. The final game was Killer Saucers (not yet available), which had to be ported to C64 Studio at the end - as it really took me outside my comfort zone :)

A FEW SMALL GAME PROJECTS

Some small game projects were launched. Due to Covid-19, Lockdown, and headlines about toilet paper hoarding. It gave me a fun idea for a party game. Toilet Paper Stacker. It is a simple game in which you have to stack 7 oversized toilet rolls on top of each other to thwart a virus. A second game was yet another full version of a previous 4K craptastic compo game. This time it was Toxic 2020 Edition. It was an enhanced version of the game. 4K had elements missing, so I thought it would great to add a front end, hi score table and a few of WEC's additional ideas. Granny's Teeth 2020 (pictured) was another previous Craptastic 4K game compo entry that was fully enhanced. The game features nice graphics by Saul Cross and additional levels, which I designed and setup myself. It reminded me a bit of the classic 1980's arcade games like Chuckie Egg. Finally there was Death Saw Challenge, which I wrote specially for Halloween, although the Disc Room competition was launched on itch. I decided to not enter the compo and just release the game for fun.

 

DEMO SCENE

There were only two C64 demos I did this year. I worked on some demo parts for a Blazon demo, "We Love C64". The demo parts were supposed to have been finished about a year and a half ago, but finally it got there at the end. The second and final demo in 2020 was a Commodore Format 30th Anniversary demo. There is a mini demo still under development for Blazon but it is likely that the demo will not be ready in 2020.

LEARNING NEW SKILLS

During the Summer of 2020 I have been attempting to learn new skills. I was introduced to Unity 3D and C# programming. I studied the free Unity 3D game coding course, and attempted to design develop and create my own games on my PC. I managed to make two fun titles for PC and Android phones as a free download. The first was Rockit, based on the Power Shed title. The second was Zzapped in the Butt, although it is MORE DIFFERENT compared to the C64 version.These games were made as a learning path to professional video game development. Whether or not I manage to reach this goal, we will have to wait and see.

ADVENTURING INTO 2021

2021 will be bringing some more goodies for the C64. Perhaps a couple more theC64 development challenges and also a final SEUCK Compo. Also I aim to progress more towards a future in professional video game development. However I am still a long way before reaching a light at the end of the tunnel.

Death Saw Dungeon

 23rd - 27th October 2020

During the weekend, I took a little break from the usual projects (theC64 Power Pack challenge, an upcoming C64 game for Christmas time) and I decided to work on a brand new game. The idea was to make a game for Halloween. The good news is that it is finished and will be released on Saturday 31st October 2020. Spooktactular.

Last week in the evening I was browsing on Twitter for C64 related content. I tend to have a general interest on seeing what new games are being made for the machine. I stumbled across a game jam on itch.io called the "Disc-Room Jam". A game jam in which involves an arena and flying discs. This gave me an idea. Halloween is coming closer and closer. How about a fun little game project to kill some time? Yes! Most definitely. Behold the:

DEATH SAW CHALLENGE

With the cross development software I had available for this project. I designed and developed the graphics and screen data using Char Pad V2.3.0. The sprites were created in C64Studio's sprite editor. Which both the charset and sprite graphics got exported my project folder as raw binary. Music and sound effects were made using Goat Tracker V2.72, where the instrument sounds were converted into sound data for use in the cross assembler. 

Only the main code was required. I started by linking and relocating all of the graphics and music files to the correct memory address. Then I started the main code. The first part was getting the C64/VICE to display the game graphics correctly. Once I was happy with the graphics, I added the sprites and then started programming the main game engine. The idea was simply to have a player sprite running around the arena dodging spinning saws. Only to find what the fate of the player could be :).

After I got all of the sprites in place. I added additional routines in which allowed the sprites animate move around the screen. The player was able to move via a joystick control, via a single subroutine. The death saws were able to fly around the screen, via multiple jump subroutines and macros. The final saw was to do nothing, but be based in the middle of the room. 

The main game engine was working quite well, so I decided to work on improving the game. A score routine was added and only the player is allowed to score when moving about. The saw appearance also was setup in a table. A timer was set in order to make each saw appear on screen and bounce around the screen.

After the main game engine and saw timers were in place. I added the GET READY and GAME OVER scenario. This made the presentation more interesting before playing the game. The GET READY and GAME OVER also ended up with jingles and flashing. Pressing fire allowed the player to get back into the game.

Things really shaped up. It was time for me to design the title screen. I used Charpad once again and designed the main title screen. I wanted to use the sprites for the logo, so the title screen was to be quite basic. However, just before I was going to program the new title screen. I came up with a little joke idea. That was to create a joke design team label "The Ministry of Death" just for a bit of one-off fun.

Once the design was finished. I exported the new character set and the title screen data into my C64 Studio project and then I worked on the code for it. It turned out great. The final thing I did was the hi-score saver routine (for disk version). This is because Death Saw Challenge is a fast paced high score attack game with no levels. Just score as many points as you can before you lose. Once I was happy with everything. I put the complete project through Exomizer and compiled it into a compressed executable. Prepared the TND Deathtro intro and linked it to the game. I then passed the game to my regular beta-testers who helped me test and fix issues with the game. Then the game got mastered to D64 and TAP images (With the Red Border, and Zap'N'Load tape loader game)

I will be releasing the game this Saturday 31st October 2020 approximated 11:00am GMT+0 if all goes according to plan.

The site to download the game for free is:

Death Saw Challenge [c64]

For now, please enjoy this video I have recorded from my Ultimate 64 

I will be porting this game to Unity 3D possibly winter time. If all goes to plan that is.

theC64 Challenge #3 - The CF Power Pack challenge resurrected

The Commodore Format theC64 Challenge #3 diary updates will be added throughout this project. Watch this space 

17th September 2020

The previous code challenges I did on theC64 were quite a success and had me in a sort of comfort zone with a machine code monitor and Turbo Assembler, although I did come across some pitfalls - but I managed to get out of those quite easy enough.

A demo/intro was made in 2018 on theC64 Mini (See: C64 mini weekend dev challenge #1). A couple of games were made this year, using Turbo Assembler and a few PD utilities (Storm Chase, and The Forever Extending Hungry Snake) . I have decided to do just one last theC64 full size challenge for this year. This time, this challenge will be taking me outside of my comfort zone.

Killer Saucers is going to be an 8-level, 3 lives high score attack retro-style single screen shoot 'em up tailor made as what you would imagine a reader's game for a magazine cover tape would have looked like back in those days. Of course this game is not going to be an actual Power Pack tape. Just a standalone game which you will be able to download for free from my web site. The reason for why all of the levels are going to be single screen is due to the limitations of the assembler that was featured on the Power Pack tape.  ;)

"Planet Earth is under attack by incoming flying saucers. Your mission is to guide your grounded vehicle and fire missiles at them. Beware though. the saucers can also fire missiles back towards you. You will have 1 minute to shoot as many Killer Saucers and 8 levels before they can kill you. For each level complete. The game will eventually get harder to play. After 2 levels, newer flying saucers will appear on screen. Although 8 levels. This is a high score attack challenge"

 Back to the challenge:

The purpose of this challenge is also my part of celebrating the 30th anniversary of Commodore Format magazine. The magazine started in September 1990, and ended in September 1995. The memories about this magazine lives on. The main attraction for CF were the Power Pack cover tapes. Each month, at least 1 or more full games, and a few playable demos were added to the cover tapes. Occasionally, some exclusive non-commercial/commercial or Public Domain utilities were featured on the cover tape. So, for this final theC64 challenge. I have decided to work on a new C64 game using only the utilities that featured on the cover tapes - also pick out two or 3 useful utilities for other tasks such as compression, memory code movement and music.

The following programs I have chosen for theC64 challenge are as follows:

• FROST (Format's Really Original Sprite Thingy) - Power Pack 32 & 56 (Sprites)
  
• Font Editor V3 - Power Pack 38 (Character Set)
  
• 6510+ Assembler - Power Pack 45 (Programming and compiling)
  
• Code Suck Monitor (Preparation / moving / saving of sprites)
• A chosen music editor (Excluding Soundtracker 64 from Power Pack 57 - It is tough to handle) . My choice is likely to be DMC or Voicetracker/Music Mixer.
• A couple of compression tools (Most likely to be XTC V1.0 and Fast Cruel Cruncher again).

DAY 1:

1. Frozen by FROST

I loaded up FROST on to my theC64 full size computer. This was from the original tape. I still had to wait for the clock to count down during loading. Brings back memories eh?. It started with a nice intro presentation with some Future Composer Music. Pressing Space goes directly to the editor.

I made a start with drawing the sprites with the editor. I drew a single frame for the player, for Killer Saucerz. Drawn up next was the player's bullet. I drew it like a missile with a flame at the bottom. The animation consists of 4 frames for that one. Thirdly I drew an explosion, which consists of 6 frames. Then came 4 different enemies using 4 frames. Finally was the enemy bullets. Although at the moment I class 4 aliens to be enough for such a small hi-score challenge game. There may be a chance of more alien saucer frames. This of course depends on memory free after compiling a complete game.The last 4 frames set are the saucers missiles (Basically a reversed version of the player's bullet).

 I completed all of the sprites I needed so far. I went to the save menu to save to disk. Oops, I forgot to save the files to disk and utility was trying to save to tape. theC64 has no tape save function yet, so I pressed RUN/STOP and then tried saving the sprites to disk again. (After changing the device). Also, as a just in-case scenario I selected MAKE DATA to generate a BASIC listing for all of the sprites that I made. 

The DATA MAKER went in to BASIC and generated a big list of DATA lines. I saved all of those lines to disk. Then I loaded and listed the directory. It turned out that the utility only saved a 1 block file to disk, even after selecting the start and end sprite. That could possibly a small fault with the firmware maybe? I had this sort of problem before with theC64 when accuratedisk function was enabled. I had no trouble with this on the Ultimate 64. The BASIC listing successfully saved completely. Looks as if FROST had a bug. I think the version I used might have been from CF32.

I just tested the same save method on my Ultimate 64, to see if I get the same problem as I did on theC64 (test saving a range of sprites to disk). There were no issues. Therefore FROST is not bugged.

2. Do the SPRITE thing

Because I reached a problem with saving the complete set of sprites. I needed to find an alternative solution to this problem. Scenario: I have hundreds of DATA lines in BASIC, I need to make it into a machine code generated DATA. How do I get to put the data to $2000, and how do I save it from the start to the end without an Action Replay Cartridge? A problem always has a solution. I had Code Suck Monitor installed on one of my disks. So I loaded that up. New the listing. Loaded up the sprite data lines and then created a BASIC listing to convert the data list into machine code data at $2000 - until the C64 ran out of DATA. 

A simple solution was:

1 FOR X=8192 TO 12288:READ Y:POKE X,Y:NEXT X

Of course the ?OUT OF DATA error did spit out, but I only wanted the sprite data to convert to machine code until it reached the end of data. 

I enter the Code Suck Monitor, examined the data using the M prompt until empty memory was found. The I saved the sprite data from $2000-$2500 (start of clean memory after running the BASIC listing)

3. Now Which Font?

Since I was very happy with my sprites. I decided to work on the character set for the game. I chose FONT EDITOR V3 for designing and creating the game graphics font. This is because the size of the font is pretty short, especially for 1x1 fonts. I only needed something basic for designing and creating the game's prototype background.

A few characters were drawn to form a road and also some buildings, as well as the text and numbers. Once I was happy, I saved the font ready for the next session.

 

4. Where's the Editor?

Because this is to be a theC64 challenge, and theC64 does have no Action Replay support for the reset/freezing. I didn't want to cheat by using other text/screen editors for the main graphics for this project. Instead, I am relying on coding. I loaded up the 6510+ assembler and I had to program my very own screen+colour capture routine. It first clears the screen and then runs on a BASIC input using JSR $A560. After the tap of the RETURN/ENTER key, the program stores the complete screen and colour data to $4000-$47e8. Where $4000-$43e8 is for colour data and $4400-$47e8 is for the screen data. The game and title screen hasn't been designed yet. There just wasn't enough time tonight. I decided to call it a day.

19th September 2020

DAY 2

1. The Designer's Pencil

The second day of this project. Last time on Thursday, I created my own little editor, and assembled it. I loaded up 6510+. Loaded up the character set and then I loaded up the SCRED.SRC assembly source. The file then was assembled and SYS49152 started the program. I was ready for the painstaking screen design. I have decided not to design the title screen at the moment since I will be leaving it until last. I moved the cursor around the screen, and prodded a few keys to design the game screen and colour data. Things were working out quite nicely with the screen game design. I drew the hi-res char city and street and score panel. Then I pushed Return to store the screen and colour of the game pic. I enter the machine code monitor in 6510+ and saved the game colour and screen RAM data to my virtual workdisk.

2. I like to Move It 

I am not quite ready to code yet. I need to move some things around, like sprites. Add a test music, and a few other bits. I reset theC64 full size, into CBM Basic. Then I loaded up the CodeSuckMonitor. The problem is that 6510+ Assembler's M/C monitor didn't allow me to load my data to a specific load address. I loaded in the sprite memory to $2000-$3000, game screen data to $3000-$3800 and the game character set to $3800. Then I grabbed one of my old music pieces, Plasmatic from the DMC collection and added that to $1000. I then used the Code S Monitor to save all of the game data. Reason for this is because I will need use all of the game data for the main coding.

3. Know the Code

6510+ had to be loaded again. I loaded up the assembler, and started programming the main game code. The first thing I had to do was prepare the game screen. Then after that I setup the IRQ interrupts for the game, including a synchronized timer. During each coding session I had to play around a little with the routines. Since each command was being written on a basic numbered line (Like how it used to be back in the 1980's). I saved the source and assembled it. Once assembly was successful I loaded in the game data and then typed in SYS 16384 to run the program. The game screen displayed successfully, and it also played my old piece of music Plasmatic in the background.

4. Ready Player One

Since I was doing the code a bit at a time. The next stage was to setup and test the game sprites and their animation. I created a series of pointers to give each enemy its own animation. The player ship only has a single frame, but the saucers and other sprites all use 4 or more frames. I programmed a routine that would display all 8 sprites. I placed the player at the bottom of the screen. I saved the source code and loaded in the game data and tested the animation. It was working quite smoothly. I was pretty happy with the animation. 

Now was the time to get the player setup for the project. The player was positioned at the bottom of the game screen but it could not move. That is because there was no particular code added to the player ship. So I worked on adding the code. The player should only move left or right. However it should also stop on the left and right parts of the screen. I added code that did exactly that, via a push of a joystick in port 2 (Since most games used that joystick port anyhow). I saved the code, assembled it, loaded the game data and then run it. The player moved quite smoothly.

5. Ready, Aim Fire

The player was moving pretty much well, but it could not fire at the moment. I loaded back in the code and then created a couple of routines. The first one was to check whether or not the player had already fired a bullet. The second one was whether or not the bullet was out of the screen. If the bullet was
out of the screen. The player was able to fire the bullet again. Also a routine was programmed to moved the bullet upwards. Then after the bullet leaves the screen it is positioned inside the border at the very left. If the bullet is at the very left of the screen, the player can fire the next bullet. Otherwise it has to wait for the next one. I saved the source, assembled it, loaded the game data and had a working bullet.

6. UFO sighting

After the player bullet was one more session before I called it a day. The Saucers need to be moving on screen. I programmed a subroutine that allowed to move one saucer. I got the saucer to move around the screen. I watched it move. I wasn't too happy with the saucer bouncing around the screen. I have another great idea for it, which I will be continuing with on day 3 of the project. I'll mention about it in the next day update. I saved all of the data and code that was made for the project so far, and made a backup of the project from USB to PC. It would be a shame to lose the project if a USB gets corrupt and a file becomes unrecoverable.

 DAY 3 - I like to Move it Move It

 23rd September 2020

TV was unsurprisingly rubbish and filled with soap operas as usual. So what better thing to do if you hate soaps than do a bit more coding on theC64. I made this session a slightly shorter session. This time it involved programming the enemy movements from scratch. I deleted the old movement routine for just one saucer and created a loop which reads speed X and speed Y of the enemies. This was because I had a better idea planned for this game. I wanted to use a similar mode as my loader game Mootilation originally did. The saucers can move across the screen, but if they spot the player's position, they can swoop down and try to capture the player. There is still not enough action yet, as the player cannot blast the aliens yet. Also the aliens cannot target the player yet either. More code on this on Saturday. ... stay tuned!

 DAY 4 - Fire at will

26th September 2020

Yet another short session today. I've been a little bit clumsy, but the second session should hopefully take place sometime tomorrow morning. Today I loaded up theC64 full size and 6510+ assembler and loaded and assembled what I did last time. I noticed a small fault in the game data. The enemy bullet animation was just plain garbage. It seems that I didn't manage to recover the enemy bombs during generating of the data in day 1. I decided to load up the Faces Sprite Editor V1.3 to fix this issue (As the version of FROST I used had a bug in the save sprites function. After fixing the sprite data and saving. I reset theC64 and then use Code Suck Monitor to load in the game data, update the sprite data and save the game data again 

The re-save of the game data was done. I loaded up the 6510+ assembler and loaded up the game source code. I assembled it, loaded up the game data and then SYS16384. The program did run, but there was still a glitch in the enemy bullet sprite animation. This time it was because the sprite animation table was one byte ahead. I corrected the issue, saved the code again and reassembled the source and loaded the game data and ran the program. It looked much better now. On to the next phase.

So I had the enemy saucers animate correctly, the player shooting but the enemies could not shoot. I decided to work on a subroutine that could do exactly that. Before I could do that though, I needed to check that the enemy bullet could only fire if it was out of the screen. Also I needed to pick which enemy could fire out the bullet. In order to do this I created some pointers that allowed the bullet to move down screen and once it reaches the bottom, it should go offset. A second pointer was used as the random selector. A subroutine was created in order to select the enemy that should fire the bullet. Then the enemy bullet was then positioned

on to the enemy object. Of course the bullet had to be checked to be offset first. I saved the code assembled it, loaded up the game data and then ran the program. Nice, enemies are dropping bombs.

The next stage had to be postponed because although I was doing the routine, I accidentally typed in NEW forgetting to save the source code, loaded up the game data and then run the program. The routine was a random enemy Y position for every time it reaches a certain outside position on the game screen. I will be working on this trick tomorrow. ... Stay tuned!

 Day 5

27th September 2020

CRASH!

Yesterday I successfully had enemies firing. Today I worked on the collision read routine, and setting up the level tables. Each level tables was based on the enemy type, speed and number of shots to kill it. I also added a test collision routine for the player vs enemy. I saved all of the code like normal, and assembled the program. The assembled code was going to overwrite the source code. Looks as if memory is low here. I assembled the source and overwritten the listing. Typed in NEW I loaded in the game data and then typed in SYS16384. The assembler froze. The program didn't run. it was a complete FAIL. 

So is it the end of the challenge resulting to a fail? No, because all I had to do was move the code to a different part in memory where it could not overwrite the listing and corrupt the project. I moved the assembled game code to $6000. It has not reached $7000 so that's quite good. I still have enough memory to finish the main game code. The title screen will be coded separately.

DAY 5 

4th October 2020

BOOM!

First off, I was running a bit low in memory, but I noticed I created too many data tables for levels, etc. I don't really need those at the moment. So I deleted them to make more space for some more code. 6510+ assembler is memory restricted. I continued with the sprite/sprite collision routines this time. Last week the sprite/sprite collision routines only flashed the border if the player was hit by an enemy bullet, or if the player bullet hit an enemy. The collision felt very raw.

I added some more routines that could animate the explosion frame on to the player, and also bullet objects. This should only take effect if the object hits an enemy or bullet. The enemy bullet is indestructible by the player's bullet. So in a more common sense kind of way, the bullet sprite should explode before it leaves the screen after shooting an enemy. The player should also explode, before losing a life. I also added routines that zero-positioned enemy vertical position as soon as they have been shot by the players bullet. 

I saved the source code, assembled and loaded the game data and then type in SYS $6000 to test the new source code. It seems to be working quite nicely, but I have noticed a bug in the code. The enemies were shooting their bullets, like they should have done. However when zero positioned. You could see bullets firing from the enemies that were killed. This is not how the game is supposed to work. I loaded back the code and then edited the listing so that if the enemy vertical position is 0, no bullet can be fired. I saved the source, assembled and executed the game code and then loaded in the game data. I then run the code, and it was working much better.

So now I have a fully working game engine, with full sprite animation, working collision detection and enemy bullet firing. Great.... but the project is not quite finished yet. The next stage (which will be in the next update to this blog/diary) will be something hectic and crazy. I aim to give the passing enemies some kind of crazy behaviour, when they spot the player in their sight.

Day 6

6th October 2020

Kamikaze

As mentioned on Sunday. This evening I wanted to code a feature which allows the saucers to kamikaze towards the player when detected.  Before I did that, I fixed the player's re-spawn after death animation. The last frame of the player explosion was stuck. So I needed to sort that issue out. Next I worked on the kamikaze saucers routine. This was where flying saucers charge for the player, if the saucers are in range of the player ship. The routine worked for all of the enemy flying saucers, however there was still an issue. The enemy saucers charge towards the player constantly. The routine needed a timer. I created a timer, and I had the enemies charging towards the player on position - only if the timer has elapsed and reset. This made the kamikaze saucer routine much fairer, but there are still bugs in the routine. I tried to prevent the saucers from charging towards the player when offset. Hopefully on day 7 of this little project I should be able to sort this out.

11th October 2020

Just a load of random stuff

Today's session on this project has been pretty much a very long session. The first part was basically fixing the kamikaze aliens routine. The routine required being timed before an enemy could try and detect the place and then charge for it. 

After fixing the kamikaze routine. I did a fix-up of the enemy firing routine. First of all, the enemy firing was too rapid. Not only that. There was a case where aliens could fire when at zero position. So I decided to add some code which allowed the enemy to only shoot after a wait duration timer has reached a certain point, also check whether or not the alien was on screen or not. Then the enemy should fire a bullet.

Once that was fixed it was time to spawn random enemy types, colour and speed. The random position for each sprite was also read. I had to create some more pointers and expand the table of bytes. This was so that every time an enemy leaves the screen, or is shot, or kills the player. A new enemy comes out of the screen with a new colour, frame and starting position. Once I was happy with the result it was time to update the enemy to bullet collision.

The enemy to bullet collision originally cycled the border colour to indiicate an enemy has been shot down. That was not really how the game should operate. The enemy short should add a number of points to the score. So I generated a few pointers. This is because scoring points should vary on the enemy type. There are 4 different enemy types. The scoring system should work like this:

Enemy type 1 = 100 points
Enemy type 2 = 200 points
Enemy type 3 = 300 points
Enemy type 4 = 500 points

The low byte of the enemy's animation got stored into a new pointer called scorezone and then when calling the score routine, the scorezone code checked for the enemy type low byte value and then jumps to one of the scoring subroutines that added up the correct scoring amount.

I saved the updated source code, assembled the source code, I loaded in the game data and then started the game code. The game is starting to look quite promising, despite the ugly game background graphics, and a few minor bugs. Those will be fixed in the next session. Then hopefully once those bugs have been fixed. It is time for setting up the concept, game level tables, etc. This is shaping up quite nicely.

20th October 2020

Day 7 - Sounds like another unlucky evening.

Well not too unlucky. The project has been developing slowly, but there seems to be a few issues in the game. Aliens were still doing a Kamikaze for an incorrect period of time. I managed to fix this by setting the screen range for where the aliens are. If they reach inside the border, then they cannot charge for the player when the timer is set. I also forgot to disable the Y position speed of the alien. Every time it charged for the player it carried on doing so after leaving the screen. How wrong :). 

Now the annoying bug was fixed, and the alien appearances are more accurate. I thought it would be cool to create some in game sound effects for this game using Achim's SFX Editor V3.2. It made quirky sounds which I felt would suit the game. However, after setting up the SFX and getting them imported into the game's source. A fault occurred. For some strange reason, the sound effects wouldn't play but crashed the project. The SFX had a built in player and I was sure that I did the right thing.To be sure of this, I rebooted theC64 into BASIC mode, loaded up Code Sucker Monitor and created a test routine. I loaded in the sound effects (with built in player) and it all seemed to have worked fine. I went back into 6510+ assembler and tried again. This time the SFX did not play, and crashed. It turns out 6510 assembler has routines that caused the crash.

Day 8: 30th October 2020

I checked the same code and data files on the Ultimate 64 and I had a go at assembling and running. The code and game data was working with success. I went back to theC64 to see if I did something wrong. I loaded up the game data and also the source code, and sound effects. As with day 7 I did have the same problem as before. There was an issue with theC64 and the disk version of the 6510+ assembler. I tried loading the version from Power Pack 45. I loaded in the source code, game data and sound effects. It all worked without a problem. So the project can use the sound effects after all. More on this project tomorrow or Sunday

Day 9: 4th November 2020

Some bad news I'm afraid. While trying to tweak the code to fix the enemy bullet firing sound effects. While typing in 4707 ; I received an error statement, ?Out Of Memory. Unfortunately it looks as if there wasn't enough memory space for my game project. If this is the case, then this project may have to be cancelled and this will have been my first failure of theC64 challenge. I'll check this through to see if the same problem persists on my Ultimate 64. If it does, then this project has failed.

Confirmed ... The challenge has unfortunately failed. This does not mean that the game project is finished for good. I will be working around solving this issue, and continue on theC64 challenge using Turbo / Macro Assembler, if converting of the source code over this weekend goes to plan.

Day 10: 7th November 2020

The CF Power Pack game challenge sadly has failed, but this does not mean that I have decided to give up on this project. In fact, I have managed to salvage the source code and I have changed software applications in an attempt to finish this project off in time for the festive period. So that there are 2 new small TND games, instead of one. This really depends on time.

On the plus side, I have managed to salvage my source code on the PC with Style's DIR master, and place it into CBMPRGSTUDIO. The game project will now be enhanced and developed with this using PC based application. This will give me the opportunity to improve the looks and features for this project. 

I gave up on developing this project on theC64, due to the issues I had with the 6510+ assembler and the limitations of the other C64 applications. Yesterday I converted the 6510+ assembler source into a usable source for use in CBMPRGStudio. I also imported all of the graphics and sound files into the game's source code and assembled everything and test run. The code was working. I added some more code to the project, so that there was a Level Complete, and Game Over scene. Also the saucers needed to be fixed a little. The SFX of the missiles being dropped from the aliens were constantly playing. On Wednesday evening, I tried to fix this issue, but I ended up with the ?Out Of Memory issue in 6510+.  A check routine was needed to check for the position of the killer saucers before the bomb drop SFX was able to play. This

Day 11: 8th November 2020
 

I spent most of my time with this project today. I have jazzed up the graphics using Charpad, to make them look much nicer. I still have some work to do in the main game. Levels have not been set up yet, but the game is starting to shape up quite nicely. There is still a weird Kamikaze bug in the game where after an alien is shot during the Kamikaze it constantly goes down towards the player from outside of the screen. You will also notice that at the bottom, I have added a counter. This is going to be used to give the player limited bullets during play. The idea is that the number of bullets the player has left results to the bonus points added to the player's score. 

Now was the time to go back to the game code. There was a problem with the enemy position detection routine. For some strange reason, after the saucers were killed or attacked the player by kamikaze, the random counter failed to reposition the enemies. I located the sprite movement check and created a new set of pointers. Aliens refused to continue moving their last direction. So I had to make a backup routine. What it does is backup the stored horizontal directional speed of the alien after read through. I did an on screen test check routine where characters showed whether or not the aliens were moving outside of the screen. This test helped me fix a few things.

As soon as I got the saucers repositioning at a random vertical position and enter the screen. I worked on some new sound effects using Achim/Mayday's SFX Editor V3.2. This time instead of having 6 sound effects. I ended up creating 10 retro-blasting sound effects. I tried mixing some of the wave forms to give some kind of effect. I exported the sound effects into the project folder and I carried on programming. This time I set the sound effects to play at the right time. 

After completing the sound effects. A routine was needed to count down the number of missiles the player has during play. At the start of the game, the player ends up with 99 missiles. However, I wanted to detect the amount of missiles = 00. If the missile count = 00 then engage the self-destruction mode to the player and re-store the missile count to 99. There was a minor bug in the routine where the player didn't die straight away, but that soon got fixed.

Next I worked on rewarding the player bonus points during the game. Every time a level is complete. The player should have an additional 50 points awarded for every missile that has not been shot. I created a subroutine that did a count down  of the missiles that were left and I also played sound effects during the count down. Afterwards I set the level counter to increment then jump to the game refresh code for the next level (which has not been implemented yet, but it might do later on). 

My final task for today was to do something about the static screen in the game. The stars and the laser beams were just still. Something had to be done to make this worthwhile. I updated the in game interrupt to call one subroutine that animated the star field (so that each character scrolls a pixel of each star across 4 whole characters). I also added a routine that scrolled the laser beam two ways. This was to make it look as if two of the buildings was firing a laser beam or something like that. The game is supposed to be based in the future. ;)

It has been a long day, but quite an achievement compared to Wednesday's flop on the 6510+ assembler. Ha, ha, ha, ha! :)

The next task later on this week will be to create the actual levels of this game. Then later develop a front end/title screen and then make some music for the title screen. Then the final crunching and testing of the game.

Days 12 - 15

 
You may remember that on day 11 I had trouble with 6510+ assembler, and moved the game to CBMPRGStudio by salvaging it from the 6510+ work disk. I focused on fixing the bugs that were left in the game. Then I created and generated some levels. Although each level uses the same screen and sprites. There's some kind of difficulty implemented into the game. Each level was based on table of pointers. However after sucessfully nearly finishing the main game. 

Disaster had struck. I encountered a strange bug where a large portion of the code got deleted after saving. Luckily there was a backup file, which I restored. So thankfully the code was still there. However I did fill a whole lot of listings into a whole page. So I tried splitting the project into separate source files. I tried assembling the source. Unfortunately I ended up with too many errors in the compiler window. Due to the sheer frustration with the problems I had. I decided to convert all of the source files into C64 Studio/ACME format.

I worked on doing a title screen using CharPad V2.3 and imported the screen data to the project source. Then I programmed the main title screen. The idea of the title screen was to make it look pretty basic and quite oldschool. I set the title screen to use some raster splits over the logo. Also I added some scrolling colours inside the credits and flashed the scrolling text silver. The only thing that was missing here was a title music. I loaded up Goat Tracker V2.75 and composed a disco-style tune that would suit the title screen, using my usual SID disco style. I was pleased with the result and I decided to keep it.

The final part of the game coding was to add an end screen. I didn't want to make the game end completely as it was supposed to be a hi-score attack challenge game. That meant that after level 8, the game should start back to level 1 instead of ending. I created a congratulations message with a colour washing routine. Then after pressing fire, it takes the player to the very first level. I had a final play test of the whole game and it was seems to be working okay. I compressed with Exomizer.

I wasn't done with this project yet. The game was supposed to have been a C64 Power Pack Challenge. I decided to use the Ultimate 64 for the last two parts of this challenge (As theC64 even with the latest firmware did not support tape recording). I loaded up Idea's Saracen Paint (CF Power Pack 25) and I drew a loading picture to suit the game's theme. It was basically space themed with a logo in the middle, with my signature underneath the logo. After the picture was done, a .tap was created, where the picture filename was stored for later use. Then using the built in Action Replay. I saved the bitmap image to disk in Koala Paint format (For the picture linker code). The picture got linked to the game in C64. Then everything was ready for the final mastering stage.

Doing the disk mastering was pretty much straightforward. Basically I use Style's DIR MASTER to import the game project into a digital disk image. Then I jazzed up the directory with the usual TND magic. As for preparing the digital tape version. I loaded the tape version of Killer Saucers from D64 on my Ultimate 64. Then saved the game to tape using the standard Kernal save. It took about 6-7 minutes to save to tape. I loaded up Loader Maker by Jason Finch from Power Pack 37. I selected the Saracen Paint picture digital paint file. Loaded it up. Then I mastered a digital tape image of the game with the new loader and picture. What a great result.

The game was finally finished and sent off to my regular beta testers and (hopefully) you will get to play it this Christmas Day when I upload the finished piece on to the TND web site and my itch.io page. The CF Power Pack Challenge did get completed, but sadly it did not result how I hoped it would. Next time I write something on theC64 I will perhaps stick to Turbo Assembler / Turbo Macro Pro and the new Action Replay functions but of course I will have to avoid using accuratedisk, _AD functions) :)

Sadly this will be my LAST C64 production for 2020. My other game project is also finished, and will also be released on Christmas Day at http://tnd64.unikat.sk. I shall now take a well earned rest until 2021 :).

Hope you look forward to the two games I release Christmas time.