Cruiser X-79 - Migrating to another base

2nd-3rd June 2019

Sunday, I came home and was wondering what I should do. I decided on doing some more work on Cruiser-X 79. I decided to carefully look at the code, and copy/paste it it from CBMPRGStudio to Endurion's C64Studio. I created a new C64Studio project and called it CruiserX79_2019 and copied and pasted the necessary files. Then afterwards, the hard work was to be done. I had to rename commands to match the ACME syntax. This took about an hour of my time. Then there was the correcting of syntax errors. The labels were mixed case. So I had to relabel those. The errors were then fixed. I compiled, compressed (with Exomizer) and then run the program. The game title screen was running perfectly, but when it come to starting the game. It crashed. I investigated the problem. The culprit was - an incorrect music file was copied. So I corrected this by copying the correct in-game music file and placed it into the bin folder. The game now worked.

While I was testing the migrated build of Cruiser-X 79. I had come across a nasty bug, which I came across a long while ago. The bug was pretty much unknown to me at the time. The issue was where after the player had lost a life. When the shield had run out, the player exploded straight away, without even hitting an enemy, bullet or deadly background. I investigating further into this bug and I found the main culprit that caused it. That was the player death and shield code. After the player was killed by an enemy a pointer PlayerIsDead is set as 1, indicating that the player explodes. All I needed to do was initialize the PlayerIsDead to zero. So that every time the player's shield is activated, the player should not be dead. That is of course until an alien or deadly background hits the player.

I'm happy very happy to present you with the result and show you a video of the game in action, with a vertical scrolling test map, with all collision working in place. I deliberately set the game into cheat mode, so that you can see that I have indeed fixed the nasty bug. Although there are still one or two minor bugs inside the game preview. Nothing too serious though. Enjoy!

Cruising for a Bruising

20th January 2019 

Well, 2018 sure has been a bit of a roller coaster of a ride, where C64 productivity and time was concerned. I mainly have been busy on SEUCK projects, but finally I have got time to do what I want. I will be on an Assemble It tutorial game project later on this week, but today I decided to concentrate a bit more on Cruiser-X 79. 

So then, what has been done today?. Before launching the playable preview, I have been doing a little more design to the test game map, which Saul originally did. This was mainly because the map looked pretty much plain space after about a quarter of the game map was drawn. So I decided to add some more tiles into the game's map and I tried to make it look as cool as I could. As soon as I finished with the map, it was time for me to export it to the game project.

Next was to load up the CBM PRG Studio and tweak some of the game code. There were some bugs inside the game, where sprites could be visible in the black lines between the game screen and the score panel. I simply fixed this issue by moving a subroutine which masked blank sprites into that particular screen area. After re-compiling the game, I could see my trick was working.

The next trick to was deal with the main game engine. I found that while playing this game, the player ship was just moving way too fast. The player was able to crash into the aliens or the deadly background too quickly. So I reduced the X, and Y speed of the player, so that it was moving at the slowest X speed and the Y speed is near enough to the correct X speed of the player.

Following that, I wanted to tweak the power ups slightly. There are 3 different tiles, marked B, M and S. The B tile is the smart bomb, M is the missile upgrade, and S is the shield. I wanted to make some alterations to the smart bomb and the missile. I started with the missile. The player's missile did work, but shouldn't the player have to pay the penalty for a cost of a life?. I altered the life lost code, so that then the player's missile was set to default - every time the player dies and fires the next bullet when spawned again.

The Smart Bomb feature was the next for me to enhance. Last time (originally) the smart bomb had a bug in the code, in which while a batch of aliens were being destroyed. Half a batch visible may have destroyed, but other alien sprites of the same group appeared. This just didn't look good for me. So I decided to do something about it. I added a trick which was to explode all of the aliens in one go. This was done simply by setting the code to enable all aliens, and make them dead straight away.

While still working on the Smart Bomb feature. I felt that the smart bomb code should be changed. So I altered the feature by adding some flashing background, to indicate the explosion. Also the feature was better off not being automatic, but manual. So I added a new subroutine and pointer where the player checks for the bomb carried. If carried, the Space Bar key activates the smart bomb feature, which destroys all or spawning aliens and awards the player 500 points.

The player has a penalty feature. If the smart bomb is carried, and the player loses a life, it loses the smart bomb power up, as well as the bullet power up.

I was going to launch a playable preview of this game on to the TND web site today, but I have decided to postpone it, due to a weird collision bug that is in place in the main game's code. The sprite/sprite collision code needs to be re-written from scratch, and some of the code needs to be inside macros. Once this has been dealt with, a playable demo of the game will be launched on to TND. Watch this space.