The story of Shock Raid

29th August 2021

Back in December 2020, I felt like setting myself up with another game programming challenge using theC64, and its cartridge supporting firmware update. I have always owned the classic Action Replay MK VI cartridge and used it quite a lot in the 1990's - present year for saving code. Then processing it through a packer and  cruncher, which I randomly selected from my collection.

I wanted to try and code a new C64 game, but unlike some of my previous games, where they were one-screen wonders which suited the use of Turbo Assembler. I wanted to try and attempt to write a vertical scrolling laser gate space shoot 'em up called Shock Raid. I used my PC and Style's Dirmaster to setup a utility disk, and also some work disks and put them onto my USB stick I used for theC64.

I got started on working on the game project. I created all of the graphics, prepared some music and also started programming the game engine using native C64 utilities. It wasn't intended to be an advanced map scrolling game at first. It was supposed to be a simple no thrills vertical scrolling shoot 'em up. I programmed the player's movement, the player's bullet.

Next I worked on making a simple scroll engine. The first part was to manually create and design the walls and then the obstacles. I did this by creating my charset using Dunex's char editor. I saved my complete charset. Then I did a hard reset. Attached the Action Replay MK VI and used fast load to load in my charset.  Next I pressed the freeze button on the Action Replay to go into the freeze menu and I selected the Edit Screen option and I manually created some walls and other things. Then I transferred the screen objects to memory location using the Action Replay machine code monitor. I took note of the memory location and then I saved the data to disk.

Next I generated some tables in which allowed to work out what can drawn. This did take me some time. However, although the first part of the project was going quite well. - Well not 100% well. I decided to call it a day on this version of the project and attempt to make a better Shock Raid. I felt that on theC64 I just wasn't getting anywhere with this project. So I considered this challenge a fail, or perhaps a prototype. So I decided to move onto finishing the project using cross-assembly.

At the start of January 2021, I copied the graphics data and sprites to my PC and then I continued programming the project in C64Studio. I did some enemies, had them moving and also made better progress with the program. However late January 2021 - disaster struck. My PC literally ground to a halt and deemed unusable. I had to re-install the operating system. I made backups of my necessary files to cloud drives which I was fully registered with. I downloaded the operating system onto a USB Zip drive and Then I re-installed the operating system from that drive. (Which was originally used as the backup drive for my work).

Even more disaster struck ... I spent hours downloading all of the backup files, which I tried to restore onto the computer. It included all of my other C64 projects I worked on in the past, finished off and released. Although the backups were being written back to my computer, the source and binary files all disappeared. The only things that exists were the file's folders. I was very gutted and spent most of the Tuesday night trying to save my projects from disaster. Even the Cruiser-X 79 files were completely lost from there. - but that did not force me to cancel the project. I actually started from scratch.

Luckily 2 days later, I ended up with a different machine, and I tried again restoring the cloud backup files - but the same problem persists. I re-installed all of the applications and decided to continue work on Shock Raid. However, I felt that what I did with Shock Raid previously just wasn't working out. I had to start again somehow.

I ditched the old version and I worked on a brand new version. First of all I created test graphics using CharPad V2 and a test map to ensure the game map was scrolling smoothly. Then I used C64Studio to program the map scroll routine, and get the test map scrolling. I then exported the test sprites from the files from theC64 challenge to Spritepad V2 and exported them to my C64studio projects. Then I added the sprites into the game program. Next programmed the player control to get it moving and shooting. Then it was time to draw a test map. After I was happy with the test map I did for the game project. I worked on the enemy sprites, and worked on the main game engine. Then more graphics were being made.

A 4 levels were in place, and just the player sprite, but the enemies needed to be put in place. So I loaded in my Alien Formation Maker V1.0+ tool to make some custom made movements for aliens. Then I exported the data to C64Studio and processed routines and macros for the aliens to move. Then I processed alien shooting and collision. This is looking wonderful, I have a working scroll field, moving aliens, and collision. Then I programmed an end screen. I was very happy with how the game was turning out. However, I wasn't happy with my graphics. Luckily I had some kind help for this part.

Although the game was more or less complete. There were still a lot of adjustments that I felt needed to be made. For a start off the graphics didn't look how I wanted them. Thankfully, Ax!s/TND popped by and agreed in helping make graphics for the game project. This was one piece of the jigsaw puzzle that was missing. After receiving a major overhaul of the game graphics, the game looked much better. There were still some more graphics to be made for this game, but it didn't take all that long to get them.

I worked on the sound effects and music. I used the SFX Editor V3.2 by Achim when I wrote Killer Saucers and Zzapped in the Butt DX for a TND Christmas release last year. I decided to use the sound effects editor again to make the in game sound effects. Then I used Goat Tracker V2 to make the music for the production. I put everything together and had a positive result.

All the music and sound effects were in place. I needed to deal with the front end presentation. There was a hi-score table missing. Also add a hi score saver, so that if the game was being loaded from a disk or a disk image, the hi score saver can save the list to the device. If detected any other device, such as a C64 tape deck for example, hi-score saver is ignored. Talking of tape. A new TapeToolBuild loader was made specially for this game.

After finishing off the front end complete with hi score saver. I was preparing a new tape loader system for the digital tape version of Shock Raid. I always chose the black and blue stripes, like the Enigma tape loader system in the late 1980's. However I opened the borders and added something slightly different to the loader. An 8x8 zoomed scrolling message. Then I added Ax!s loading picture to the loader system, along with loading music. The result was pretty cool. I loved it. 

After doing the final mastering, we spent a few weeks beta testing the game, and doing a lot of bug hunting. After all, you don't want to play game which would crash or corrupt graphics, or anything would you? :) I sent the game to my regular testers, who really test hard on my productions. In March 2021, I submitted the game to Reset for inclusion on the Mix-I-Disk (Which it will of course), but a delay had taken place. I was given the go-ahead to release the game onto my itch.io and TND web site, before the Mix-I-Disk (Which sadly is not ready yet).

Now you can enjoy the final result, either online or as a digital download. The game, Shock Raid has 4 levels, but if I were to add more levels, it would have had to be a multi-load. However I think each level is long enough, and the game should be hard enough, unless you are really good at these type of shoot 'em ups :) I hope you have fun playing it:

Here is the video footage of the game in action:

Shock Raid is available to download free from these two web sites:

https://richard-tnd.itch.io/shock-raid-64
or
https://tnd64.unikat.sk/s.html#ShockRaid

Have fun and happy blasting.

Cruiser X-79 June Update #2

 20th June 2021

Since I have more or less run out of other C64 projects to work on, and pretty much up to date with everything. I decided to work a bit more on Cruiser-X 79. It has actually been a whole day's session. Yes, that's right, about 8 hours or so. I needed to get a lot of things done today and I had nothing else to do. Considering the weather has been rubbish today also.

The first part of today's session was working on the music and additional jingles. I loaded up Goat Tracker and I experimented a little with the music to come up with some suitable in game music. I ended up doing 3 different tunes. The initial  plan is for the game to have only 4 different in game tunes. All of the tunes turned out more upbeat, and the well done and game over jingles sound familiar to the level 1 jingle. 

The next part was slightly more painful. The easiest part was to setup the filename properties. The second part actually gave me a real headache to work on. The disk access multi-load system. I tried compressing the test level graphics, character set and map as well as the music for the game. Unfortunately, however the de-crunch routine was crashing all the time. 

I discovered that the music memory is at $1000, and I cannot unpack a music file at $1000 when it loads to that address with Exomizer. I also had issues with memory management. I had no spare memory to place packed data. So I decided to leave out the Exomizer level compression for the time-being and load the test files as unpacked data. The program worked, but loading time takes a bit longer. 

I might need to find some alternative to the mem -l packing in Exomizer. If there is a load and decrunch on the fly method, then I might consider using that method. Otherwise I might have to do the level packing the more slower way, using a Level Squeezer and unpack from the level unpacker code. We will have to wait and see.

Update 21/06/2021 - I scanned through the memory area using the Action Replay Machine Code Monitor, after testing the game and found there was plenty of memory where I could load the packed data and de-crunch the data with the Exodecrunch wrap.s. Since the size of each packed file was less than 4K, and there was just over 4K memory free. I used the memory nearest to the last $100 bytes at the end of the game memory for loading and de-crunching the data. Everything seems to be working fine, although bugs in the title screen and the game still remain - but they should not be a problem to fix.

 

Cruiser-X 79 - June Update: 1

 10th June 2021

Over the past few months. I mainly worked on a few small game / demo / intro projects. There have been times where I have been doing more on my game project. I noticed that it has been a few months since I last did some more Cruiser-X 79. This was because I was literally unsure what to do next after the alien movement patterns. The main game engine is more or less finished (except for the bugs that are still left in the game). The only thing that is missing for the main game code are the level graphics. That is up to Saul :). 

Okay, so if I cannot code any more on the game, what shall I do now. I decided to work on the front end for the project. The title screen graphics are still there. So it wasn't much of a problem to import them into the game project. I also did a mock-hi score table. The front end is not 100% complete yet, but it does look quite nice (and erm - green, ha, ha.). The title screen also uses the same music as I used in the playable preview. Since the music was made for the title screen anyhow.

The title screen appears to look nice, but it does need some kind of action in the scene to make it look less boring. The game is supposed to be a space shoot 'em up so I might add some kind of star field like I did with Zzapped in the Butt DX. There are characters free for this cool effect.

Another thing I need to add, which I decided to do this hot and sticky afternoon is add a disk loader system to load the main game. This is only for testing purpose, as no level packing has been done yet. The game currently loads through the SFX de-crunch routine from Exomizer. Eventually changes will take place in this project because I will need to make alternative plans.

 

I took note of all of the memory which current data from the title screen and the game used. I need to do this in order to  allow the loader system to load the data to a range in memory in the game, where it cannot overwrite important data or code. Then the data can unpack from that area to the target memory at range. The game loader will need to be split into 4 different files. They are as follows:

- In game graphics charset
- In game graphics tile set
- In game graphics map
- In game music

Each of these files (once received) will be fed to the Exomizer using the mem -l  prefix. The Exomizer de-crunch source (which I used on Starfysh Remix) will be used to unpack each file respectively to the correct memory bank of where the original charset, tile set, map and music lies. 

More on this next time I get onto it :)

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

 16th April 2021

This is the final chapter. So what happened then? Well, in part 2. I assumed the game was perhaps ready, but there had to be a couple of adjustments made to the game. Here is what happened:

Levels - now what happened?

I had a test of the game and it appeared that the level counter wasn't working. I had forgotten to increment the level pointer to read the next level. Thankfully it worked. There was also a suggestion that I removed the two digit counter from the screen. This level counter was indeed meant to be for testing that each level was working and should have been deleted after the levels were working. I removed the digit counter.

Unreadable character found

The letter "Q" in the text on the title screen / hi score looked too much like the letter "D". Rather than use theC64 and Multi-Screen Construction Kit just to fix up a character set. I decided to export the character set to my PC and re-import it into Charpad V2.7 then I re-imported the charset into the game code in 64tass as a raw file. The letter looked much better.

Flashing status looked a bit off

The Well Done and Game Over sprites looked off with the grey pixels around them, so I set the colour for each flash as just a single colour. Like with the Charset, I imported the sprites into Sprite Pad to do a fix up of the sprites. Although the "well done" and "game over" text were still displayed as multi colour sprites, they both looked much better and more readable.

The count down was unfair

Para Lander DX had scenes where the player was jumping for joy, but it appears to be unfair for the player. This is because the clock was still ticking down while the player was jumping for joy. The problem was solved by stopping the timer.

I wanted to be oldschool, but I felt had to use Exomizer

With the test build of "Para Lander DX" I had to put up with having to link, pack and crunch several times while using ECA Compactor V4S and Cruel Cruncher V2.5. The oldschool packing and crunching was a lengthy process. I decided at the end to just use Exomizer and disguise the de-cruncher as some of the old favourite crunchers from back in the 1980's. I went for disguising the Exomizer depacker as the Matcham Speed Packer V1.2 (pictured). Considering that I used Future Composer V4.1 to do the intro music (Or ripped it from my previous intro for Ray Fish) ;). I thought it should have an 1980's feel to it :)

Finally the game is finished and mastering is done. I will be releasing the game next week. For now, here is a video of the final production. This is the digital tape version:

The game is intended to be released next week on 23/04/2021 at The New Dimension or Para Lander DX page

Cruiser-X 79 - April Update #1

14th April 2021  

Previous update was deleted along with the Para Lander DX blog entry. This entry from 3rd April  is what has been remembered from that day.

3rd April 2021

Last time I was dealing with alien patterns. The next task was to put these into levels. I also was setting up the colour settings for each level table. Of course, last time all aliens were put into order of sequence and were being tested.

That week (for this part in the development) I mainly focused on the level alien attack patterns. Instead of all aliens being in sequence 0-40. I setup alien selection tables for each level. The idea was to ensure that each table has a specific level of difficulty. There are 40 different alien tables (some of which are duplicated enemies doing different things). The idea is that the harder faster enemies get used after a few levels. There are 16 levels in total.

Now that all the alien patterns are in place for each level. There is not really much I can do to the game right now. Although I will need to work on doing different tunes for each level of the game. 16 different tunes might be too many to compose, so maybe I do a few tunes and then create a table to load specific music files. Still, that will do for now :)

 

 

theC64 Challenege #6 Para Lander DX - Part 2/3

 1st April - 13th April 2021 (Continued)

Last time in my blog I mentioned about the Para Lander Mini, and also how I thought the game was finished. Things did not really go according to plan. In this next part, this is where I decided to stick to 64tass instead of using Turbo Macro Pro. 

 

Last time

I prepared, designed and developed an enhanced edition of Para Lander DX on theC64 with aid of an Action Replay cartridge plugin, some C64 applications, including Turbo Macro Pro. I worked my socks off on the game project and finally came out with a working game. However things did not turn out how I expected. Although I had a fully working title screen, hi-score table and game. There were some elements missing in the game. So here is what happened.

A new intro - Nice

Friday last week I ended up with a new picture for a TND intro by Hugues. I worked on programming it, added a Future Composer soundtrack, and the result turned out great. I then packed and crunched the game with the Sledge Hammer II and Cruel Cruncher V2.5+ to continue with the old-school theme. Then I wrote the game documentation. Unfortunately however the game was still not ready to release. So it was back to the game code once more.

Random situation

The game was working out quite well, but the main problem was the game play. The zeppelins were moving slow across the screen but the game was just too easy to play. I decided to create a random table of speed and I set random speed timers and pointers to the zeppelins. Unfortunately however I was unable to continue using Turbo Macro Pro as once again, the bottom area of the screen messed up and this time it crashed. This de-motivated me more from using Turbo Macro Pro for this game. I must have used all the memory perhaps?

As a drastic measure I decided to from now with the project use the 64tass on my PC. I created the random tables, generated them and compiled the game (and crunched it with Exomizer) and run the game in VICE. It was working quite nicely. After I completed the first round, Zeppelins randomly changed their speed. I came across another issue. The zeppelins were going past too fast. 

This resulted to only setting the speed of the zeppelin to the slowest speed, and play with the drag rates, between 0 and 3. After compiling and sharing the build with Hugues and another tester. They felt that the game would be better off using levels. So ...

Rank up

I felt there was something missing in the hi-score display. The title and game have music, but the hi-score display re-uses the title music. I felt that there should be at least one more tune for the game. For this, I decided to browse through the HVSC under my name, and I found a tune I feel that would have been great for the high score table. Feel Great. As a bonus this tune was also composed in DMC V4.0. I relocated the music to $8000, and placed it into the game project c64 folder and re-built the source. It worked. Excellent.

Level up

Random zeppelins in the game code didn't really work out, so it was time to make levels. Actually that was pretty much simple. I deleted all of the random tables and I entered the drag speed value for each level. The table for each zeppelin's drag rate was 16 bytes. The drag rate was still set between 0-3. Although setting the drag rate of 3 to 2 sort of looks as if the zeppelins are moving at the same speed, but in fact the speed is actually set to faster. After setting up the last level the game should loop. I then re-linked the game to the TND intro and prepared for a release candidate on my Ultimate 64. Yet again I used the native C64 tools to pack and crunch the game, like it would have been back in the 1990's. I then sent the game to testers. Some bad news - there were still bugs.

Stop bugging me

I decided at the end that I'll just stick to using 64TASS and Exomizer for all the packing and linking of this project, but I can disguise it to look like some of the old memorable packers . This saves me having to mess about all the time using old packers and crunchers just for the sake of old-school - then finding out something else gone wrong with this project.

The bugs in the game were that the hi score name entry routine allowed unwanted characters, which made a mess in the name entry. This was supposed to allow alpha-numeric characters, delete, space bar and return keys only It turned out I had set an incorrect range value (perhaps a typo) that read from number 0 and all the PETSCII character code before shift+A. Pah!

The second bug was that the total number of levels = 15 instead of 16 before looping back to 01. I set an incorrect value in the level compare code. It should have read 17 as the max value instead of 16, otherwise it would have been 15 levels. I re-compiled the source and fed the project through Exomizer, and after a few seconds, the game was working. The game has now been sent to the testers. Hopefully this could be a better result. We'll have to wait and see.

Update: Still not ready yet, but nearly there. Fingers crossed ;)

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  ;)