Friday, 5 August 2022

Cruiser-X 79: The Final Battle

 Just a short entry today. It is about level 16 of Cruiser-X 79. I decided to re-use the one of the earlier level designs as a rough design (I think it may have been level 10). The design of level 16 is supposed to be the alien pirate base. There are loads of flying over deadly background tricks to be achieved in this final battle stage. Luckily there are shields to collect - but response needs to be quick before the shield runs out. At the end of level 16, I made a HQ base (the home base for the player ship) . As for the music, I have gone for a moody military style tune (no trance this time). 

There is an ending intended for the game. However this will NOT be revealed in this blog.

Well that is it. All of my rough level designs finished. I will be awaiting Saul's magic touch to the game. However it is not the end of the game project yet. I have some code tweaking to do.

Wednesday, 3 August 2022

Cruiser-X 79: More bubbles

 Because I liked level 4 so much, and the bubbles scene. I decided that level 15 should feature the bubbles once more, but this time much inside a much harder level. There are some more barriers in which the ship should avoid crashing into, but as usual shields should be easy enough for the player to pick up. The shield allows the player to fly over deadly background for a temporary amount of time. 

On the music front, it is another fast paced tune, but not trance. The music sort of feels very oldschool like something you may have heard in the late 1980s or early 1990s. The idea for the music for this level was intended to sound a bit like Maniacs of Noise, but the tune plays too fast. I had to make the music fast due to the level finishing before the music loops back. The result is pretty good.

I exported Level 15 graphics into the game source. Re-configured and compiled the game to put everything in place. Then I set the game code to play level 15 after loading from disk and played the game with infinite lives. This rough level design has turned out quite well. I am really pleased with how it has turned out.

There is only one more level to design this week, before I go full on into the game code next week fixing the game bugs and adding additional elements like 'continue game', 'hi score/name entry', etc. There is one thing I am most certain about. That is completing the project in time for a Christmas release. There is still plenty of time for improvement and finishing everything off. - Unless of course circumstances beyond my control holds things back, which I hope will not be the case. :)

Sunday, 31 July 2022

Cruiser-X 79: A touch of glass

I am back in action working on Cruiser-X 79. The next level is once again based in space. I wanted to make another ice-themed level for this game. I loaded up level 6's map in Charpad V2, and created a brand new map from it before adjusting the character sets to make a rough design.

Well, Level 14 is still ice themed, but this time round, it is based in space, rather than inside the original base. I wanted to make some glass windows for the base, so that it looks as if it is some kind of glass-ice base. Also I adjusted some of the background charsets to make the base look slightly different. Yet again some more deadly obstacles with an incentive have been added. This time the obstacles/full blockade is a further distance than the shield. It is up to the player to pick up the shield and try to fly over the blockade otherwise the player will die.

After completing my rough design of the game map and altered the character graphics. I went onto working some music. This time, I decided to do a spacey themed tune. It is still up-tempo, but quite moody. In some parts of the tune, there is one part which reminds me of the theme tune to the 1980s TV show, Street Hawk. But of course the music in the game is definitely not that.

After finishing the music I exported all of the charset, tiles and map data into the project source code, and then compiled and run a new D64 with level 14 added. I am very pleased with how the music turned out during play of the game build. As for the game graphics, it is just temporary until they have been given the magic touch by Saul.

There are only 2 more levels for me to design before I go back to the game code and make some minor improvements. The project is shaping up really well. I am confident that this game will be finished and released some time this year.

Friday, 15 July 2022

Cruiser-X 79 vs Spore

 Well then, another week nearly over, and the rough graphics designs and maps I have been making are close to completion. Today I focused the mid morning - afternoon developing level 13 for Cruiser-X 79. The idea this time is based inside another base, which contains spore. The spore will not be deadly for the player ship, but there are to be quite a lot of obstacles for the player to watch out for, such as the usual high walls.

There isn't really much I can talk about, where it comes to this level. Except for that things look a bit messy at the moment. However S.C should hopefully be able to tidy things up with my rough level map design.

More music has been done for this game, and yet again another up tempo soundtrack, but this time more moody, but still trance like. 

Thursday, 14 July 2022

Cruiser-X 79 - Ultra Violet

 Wow, there has been quite a delay since I last did my last level design on Cruiser-X 79. Well, it was due to working between other game projects. I had the PONG jam, also Alf Yngve's Captain Ishtar project (Which is nearing to completion). Finally a secret game project I was working on for an upcoming covermount for Zzap! 64. Unfortunately the game project has been very problematic so close to the deadline. 

Anyway, moving on forward to Cruiser-X 79. This time it is level 12. It is also the return of the vegetation zone, but this time, I called it "Ultra Violet". This is because the game uses an ultra violet blue scheme instead of green. The idea sounds quite weird but the colour scheme has actually turned out quite good. Also yet again, the music for the game is trance music, similar to the style of level 5. I have added less walls for this level, as the enemies for this stage are getting quite harder and faster.

Sunday, 26 June 2022

Cruiser-X 79 - Mosaics

The blog entries for this project are going to be shorter now. 

My rough design for Level 11 of Cruiser-X 79 was done this weekend. The design currently uses level 4's original graphics design, but I altered some of the game chars to make the base look different, and possibly quite smart as well. Level 11 is to (later on) contain some nice square+L shaped mosaic tiles patterns around it painted by Saul. I replaced the bubbles characters with stars and asteroids The screen shot below is my rough design for the level. 

Next I worked on the in game music. It is less trance like, compared to some of the older levels. The music is pretty moody, and has a good punch to it. Very industrial in fact.

Well, that's this level out the way. More updates to come next week, with level 12.

Friday, 17 June 2022

Cruiser-X 79: Enter the Block

 A hot sunny week, plenty of walks, except for today due to excessive heat. What better to do but relax and work on a new level for Cruiser-X 79. That is exactly what has happened on Thursday and Friday this week. I wanted to come up with a new idea for level 10 onwards for Cruiser-X 79. It is quite a deadly plot of mine. You'll see as you read on a little bit more. :)

I load up Charpad V2 and then load up level 1's graphics data. Then I save it as level 10. I saved it as Level_10-JaggedBase.ctm, which later gets renamed by myself as Level_10-BlockyBase.ctm. You will see the reason why I did this later on in this entry. The next paragraph in fact. As usual I filled the whole screen with the space background data. I then set the colour settings to a crystal blue, purple and light grey. It looks pretty nice.

The next step was to construct and design the base for level 10. I went down further to level 1's tiles and edited the base which had the jagged edges (Which were used for Level 3). The characters that form the jagged edges were transformed into nice brick like mosaics. This looks perfect for the edges. The scrolling void inside the enemy base is filled with black and blue waves. It looks really nice. Now what about the new feature in the game? Basically it is a deadly new feature, which requires skill. Some bases on level 10 (which will also feature on the remaining five levels to be done) feature a long wall across the whole base. The only way to get over that structure is by collecting a temporary shield and fly over them as quickly as you possibly can. The alternative solution will be to lose a life. There is a helpful clue in level 10 however. A skull with an up arrow warning there is danger ahead. - This will feature on another one or two levels, but the last set of levels it will not be used. It will be a test of memory.

After completing my map and scanning through the whole base inside level 10 I was very pleased with how the level looks and how it has turned out. I think with the extra touch Saul makes to the level, it will look even more marvellous. I must confess that there isn't much to be done for the charsets of level 10. They look good as they are already :)

Next I load up Goat Tracker Ultra V1.2.0 to compose some music for level 10. I decided to make this tune very upbeat and quite enjoyable. Although it is my typical style, I think it would fit very well in a space shoot 'em up. After composing the music, I tested everything on SIDPlay and then exported the music file to the binary folder in the project.

Finally I went back to Charpad and exported level 10's charset, tiles and map data into the game project. The source code gets edited to set the correct table value for the colour of the map. Also I altered the level counter routines so that the status panel can display the correct panel for each level loaded, according to the level pointer. I compile everything and test the level, and here's the result.

This is my very last WIP video for the main game as I honestly do not wish to give too much away.

I will be taking a look at the memory available inside the main game code, and see if it is possible to add a fast disk loader system into the game project, where no data gets overwritten by Exomizer's level memory packed data or other code. The disk loader I aim to use is Lasse's Covertbitops Fast Loader system, which I used for my brand new Reset Mix I Disk Menu, reserved for issue #15 of Reset. I tested the fast loader to see what would happen if I tried to load a program in VICE without true drive emulation. The loader worked nicely without fail.

Stay tuned next week.

Saturday, 28 May 2022

Cruiser-X 79: Let's Rock !!!

Wow, am I really on to level 9 already? You betcha :). After completing level 8 last week. I worked on with designing level 9 on Thursday. I thought that for level 9, it would be nice to add a some new theme to the game. So an idea had come into my mind. The first half of the levels have been quite simple and involved shooting aliens and flying through bases, and hoping to avoid the enemy bases highest points.

Well, level 9's idea is similar to the first few levels, but I came up with an idea to implement even more deadly background. So that the player can easily crash into deadly terrain like rocks or similar - unless the player is carrying a protective shield (simply by hovering over the 'S' tiles). I started the level where there power ups are in place at the start of the game. Then I designed some of the background to make it look a bit like rocky terrain. It sort of uses some of the base's background character sets, and the deadly high building. I painted the blocks a little to make the deadly terrain look a bit like rocks. 

Although the graphics data that was being used for level 9 was based on level 4's Bubble World. This time round, I didn't want the bases to be bubbles based. I also didn't want the space background to become bubbles either. Instead, I chose to edit those character sets and turn those into steel saw disks. The colour scheme for the level are red, grey and light grey. The shoot-able blocks and other bits got transformed into different charset objects. After finishing the map and the design layout of level 9. I packed up everything ready for the next day.

The next day came, but sadly nothing happened that Friday. I was going to do some more work on the project on Friday, which was to work on some game music for the project. Sadly I felt unwell to be productive. Maybe tomorrow.

Saturday came by, I loaded up GoatTracker Ultra V1.2.0 to first work on some more in game music for Alf Yngve's Captain Ishtar project. Then I worked on level 9's music. It is sort of a dark, moody and industrial tune, which I felt would suit Level 9 of Cruiser-X 79. The tune is not trance this time (unlike levels 5, 7 and 8). I edited my instruments to make it sound right, then I exported the tune as SID and tested the tune. 

Once I was happy with the music, I exported it to PRG format into the game project's source code. Then I loaded up Charpad, and exported my Level 9 graphics and crunched them with Exomizer. I loaded up the source code, edited the settings and then compiled and built the project and tested the game in cheat mode. It looks pretty good. However, after Saul's magic touch to the graphics, it will look even better.

I am now going to take a short break on the level development of Cruiser-X 79. It is set to continue in about 2-3 week's time, unless theC64 challenge for Retro Programmers Inside's PONG challenge is finished and submitted to the compo. Stay tuned!!

To find out more about my progress with theC64 challenge #7 PONG 50th Anniversary game, please check out the link below:

Wednesday, 25 May 2022

Cruiser-X 79: Lava hard work

 Last weekend I have been working on level 8, which is yet again based in space. However, I wanted to give the game a sort of a hot feeling. That's right. Level 8 is a lava base. I loaded up Charpad. I loaded up the graphics from Level 2. Then I cleared the whole screen and re-drawn the space background. Afterwards I placed in the tiles that formed the enemy base.

The next thing for me to do was to make sure that the level did not look too much like Level 2. So I edited the charset graphics and replaced some of those as new charsets. I tried experimenting with different looks for the enemy base. I decided to try and give it some hot look. I turned a few of the unused chars into plain chars, so that I could create a checkerboard effect. Also I altered the two scrolling charsets to represent the lava, which should parallax scroll with the game scene. A floor mosaic of an invader (with two high pillars) were implemented for the eyes. 

After completing my base, I worked on some music. This time, using the GoatTracker Ultra V1.2.0. Like with level 5, I thought it would be good to do an atmospheric fast thumping trance style tune for that level. I went for a traditional exotic mood inside the sound track. 

After finishing the music I exported all of the graphics data, and also imported the music into the game project source. I loaded up C64Studio and edited the level table and set the colour to match the level. The D64 building batch file got edited Then I compiled the project once more and run it to only load that level (I says level 1 on the status panel, but this is only test mode). The level loaded nicely, and the map turned out quite well.

Like with level 7, I have passed the graphics file to Saul to alter to make it look even more improved. I am very pleased with how things have turned out so far, and there is another level of Cruiser-X 79 (Level 9) I have in mind. It will be slightly easier on the game front, but there are harder aliens to come.

Saturday, 21 May 2022

theC64 Challenge #7: Celebrating the 50th anniversary of the all time classic PONG (95% theC64, 5% 64TASS, Exomizer)

 This year does not only mark the 40th anniversary of the Commodore 64, but it also marks the 50th anniversary of the cult classic two player arcade game PONG (The screenshot below is a PONG V1.0 by TND contributor Matteo Angelini. Quite recently, Retro Programmers Inside launched a programming challenge on their Facebook page in which is to make a PONG style game to celebrate the 50th anniversary. 

To mark the celebration of the 50th anniversary of PONG (and ironically celebrating the 20th anniversary of POING). I will be doing a lucky 7th theC64 challenge on my theC64 full size computer, with aid of an Action Replay plugin and a few utilities. This type of game should be suitable enough to create and design on RGLs computer, unlike a couple of games I had failed on, due to memory issues.  After project is finished, I will also be including the source code.

I remember back in 2002 I wrote a C64 game called POING, which ironically had a second sequel. To celebrate the 50th anniversary of PONG and also my 20th anniversary of POING, there is going to be just one more POING. I remember someone contacting me a few years back suggesting I should re-master Matteo Angelini's game to give it background effects, and stuff like that. I didn't quite get round to doing that. However, as I'm not all that familiar with CC65, and don't like scripting languages like C, C# and Java. I have decided to just make my own version instead.

I do remember POING being written back in 2002 completely in Turbo Assembler, and Action Replay, but the game had many bugs left inside. After I released the game, it crashed at times. So a second version was released.

Three years later, I created a sequel, which was called MEGA POING. (Renamed from Poing 2). The game graphics design was slightly improved but felt too much the same as the original POING.  There was also a 1 player mode, which only had the player moving up/down constantly. There was no AI programming involved in this version of the game. The game had no sound effects, and had only music. There were also 4 different screens, but the size of the game field was way too small. The same problem was with the original POING.

Moving on to 2022, I have decided to make at least one more sequel to POING, but with the more better skills I have in C64 game development, compared to back in the early 2000s. I am aiming to make POING 3 look more modern. It will feature a colourful presentation, and also (as suggested years ago by another C64 coder) will feature full animated background and some up-tempo music (unless sound effects has been selected). The only difference is that the project will be developed with a modern look on my theC64, without use of PC cross development tools for graphics design, sound, and programming. I will be doing all this on theC64. Then the finished production will be mastered to a digital tape image using "Tape Master Pro V4.0" via my 1541 Ultimate (Since VICE in current theC64 firmware doesn't support tape writing support).

I have already picked out a selection of utilities from the Public Domain C64 scene. The CSDB has so many scene-related utilities, but I have only picked out my favourite tools for this project. They are as follows:

Multi-Screen Construction Kit V2 by Jon Wells (previously commercial, owned)
Char Machine char size converter by Sub Zero (public domain)
Sprite Editor V1.3 by Faces (public domain)
Face Painter by Faces (public domain)

Sound and music:
DMC V4.0 (Demo Music Creator) by Graffity (public domain) 
All Round Relocator (for just incase I need to move music) by the Syndrom (public domain)

Programming and development:
Action Replay MK VI by Datel (previously commercial, owned)
Retro Replay V3.8Q by Cyberpunx  (Public domain)

Programming, compression and linking
Turbo Assembler by Omikron (public domain) 
64TASS (Cross-development compiler by Singular)
Exomizer (I don't want to spend ages packing and crunching, unlike what I used to do back in the 1990s-very early 2000s :)
TND branded Presentation intro by Richard/TND
Tape Master Pro V4.0 by Martin Piper and Richard/TND

I have until 20th June 2022 to develop and produce this game project, but with all the free time I currently have at the moment in the evenings during poor quality TV shows (Let us put it this way, prime time on a weekday is over-run by extended news programmes and soap operas.

It is most likely my project is to be completed before that specific date unless things change. Of course, I will also be continuing with my Reset 64 mix-i-disk game project and also Cruiser-X 79. Which a new blog will be posted about the project next week. Wish me good luck :)

Please note: screen shots featured in this blog are screenshots taken from VICE - although the game project is *officially* being programmed on theC64 full size. 

Sunday 22nd May 2022
The in game graphics scene

It was quite an easy task for the first part of this challenge. During Sunday night, I booted up theC64 and loaded up the Multi Screen Construction Kit and I drew out the game graphics scene. If you look at the screenshot below. You can see that the game screen has been designed like a traditional PONG court, but there is a bit of modern design implemented into the graphics. 

I didn't want the game to look very basic like the traditional PONG, but instead I wanted to make something more colourful and quite attractive. There could be a possibility that later on the background graphics might be tidied up a little more. We'll have to wait and see how time goes with this. Then again, my text charset has always looked the same, but that will of course be for the title screen (along with a nifty bitmap logo). I take a look at the value of each charset, and take notes of which chars represent the scoring number chars, also the lasers and blue tiles. These have been noted on paper for a good purpose. I need to keep those as reference for when I am actually coding the game.

Although the game screen has been designed and stored and saved to a finished library. For the main game project I will not be using the finished library file. This is because for a game simple as this, the library file is too big, and perhaps not compatible with the Turbo Assembler when loaded. I tried this a few times, when I created Balloonacy and a few older games back in the very early 2000s. There were plenty of pitfalls.

Instead, I push the freeze button on the Action Replay and then I code a subroutine which extracts the screen and colour RAM and place it into memory, where I can just save it out as a whole chunk of data. The routine then jumps to $FCE2 which soft resets the C64. However the charset, object and object colour files all have to be saved first before I can add the routine and perform the action. At the end of the day, I don't want to lose everything if it all goes wrong. I can be a clumsy coder at times. The routine used was this:

Monday 23rd May 2022
The sprites

The next task was to draw some sprites for the game. I wanted only a few sprites (for now). I loaded up the Sprite Editor V1.3 and setup some colours to test the look of the sprites. I chose brown, white and cyan. Unlike some sprite editors, the changeable sprite multi-colour stays that same colour all the way through. Of course, when I work on coding the game, the sprite colours will be different. The ball intends to be silver, player 1 intends to be light blue, and player 2 intends to be light red. We'll have to wait and see. 

I drew the bat (a single sprite, but this can change later on in the project), using 3 colours, also I drew the ball and also an explosion animation. The explosion animation should more or less cater for the size of the bat, to give a good effect. To be honest, I am not all that happy with my explosion animation frames, and feel that something could be changed. I can do that later on in the project. There is plenty of time - and I currently have it at the moment. 

Sprite 00: Bat
Sprite 01: Ball
Sprite 02-06: Explosion
(Will be improved later in the project!!!)

Coding - Session #1

Now it is time to code the main game. No title screen, yet. The main game will be the most important aspect of coding. First the Action Replay cartridge has to be set and completely initialise all of the data in memory. Pressing F1 (Configure memory) usually does the trick. Next, a soft reset to the Action Replay menu and into fastload. As I don't need accurate disk (_AD ) for the software which I am using for my theC64 game development challenge.

The next task is to load the graphics data, and other work data. I also extracted an old tune from a note writer to use as a test soundtrack for the game project. I will be doing music and sound effects in DMC V4.0 later on during the project.  I chose the layout for where to put everything so far in the project:

$0800-$0fff - Game screen and colour data
$1000-$1xxx - Game music and sound effects
$2000-$2400 - Game sprite data (There only needs to be a small number of sprites AFAIK)
$2800-$2fff  - Game character set data
$3000+ - Game code

I load up the Turbo Assembler and then enter SYS26880 (This version of TASS used was shortened and modified by Samar and has $9600 as the jump address in order to make more memory for code listings). Then I did another soft reset on theC64 and type OFF in the fastload option. F8 is then pressed to enter the machine code monitor. I load the game graphics, test music, sprites, and charset data into the chosen locations, and then I save the whole set of data as a big chunk. 

Next I enter G 9600 to enter the Turbo Assembler and I got started with coding. The first part was to get the game screen onto to the main screen. Then after I successfully got that on display, I got to play some music in the background, via an IRQ raster interrupt. The music player has not yet been used to play in PAL/NTSC speed. That could be done in my next coding session. The main idea is to get the game graphics to display on screen, and ensure that my IRQ raster interrupts are working. Brilliant.

You may remember earlier on when I designed the blue tiles inside the game arena, and I also added some lasers. Well, these I don't want to be just static, I want all of those to be able to scroll. The laser beam on the left should scroll upwards, and the laser on the right should scroll downwards. Before I am able to get those to scroll. Pointers (worth single bytes) must be entered to time the speed of the scroll. Also I need a pointer to the synchronize with raster interrupts. Also to scroll the lasers I have to set the scroll time to a delay value. Then reset the delay value, and then scroll laser characters. character 40  represented the laser up, and character 41 represented the laser down character.

How do I scroll the characters? Well a whole character consists of 8 bytes in memory. To scroll a character upwards, I would have to grab the very first byte of the character, store it to a pointer or zeropage, and then call a loop that pulls the remaining characters back. After that is performed, I simply load and store the zeropage into the last bit value of the character. Scrolling lasers downwards is a reverse operation. I prefer to use zeropages or pointers to collect and store the bytes instead of using the pha and pla command in order to avoid confusion. 

An example for scrolling chars upwards:

lda charset+(40*8)
sta chartemp1
ldx #$00
lda charset+(40*8)+1,x
sta  charset+(40*8),x
cpx #7
bne scrollchar
lda chartemp1
sta charset+(40*8)+7

Also char scrolling backwards

lda charset+(41*8)+7
sta chartemp2
ldx #$06
lda charset+(41*8),x
sta charset+(41*8)+1,x
bpl scrollchar2
lda chartemp2
sta charset+(41*8)

After assembling the source code done so far, the screen displayed, music plays and also the left and right lasers are scrolling perfectly.

The next thing I want to do is make the blue tiles scroll in eight different directions via a timer. A new routine has been programmed to perform this operation. After assembly and running the program, the tile scrolling routine worked, but for some strange reason there was a big split/tearing in one of the bytes between the characters. I think I will have to re-program that scrolling routine. I am sure I did the code correctly, but perhaps there is something else interfering with it. I'll see what I can do tomorrow.

Tuesday 24th May 2022
Coding Session #2

Yesterday, I came across the problem with the moving grid inside the game screen, where a row of the charset was chopped away. Today I decided to forget about this feature and delete the routine, in Turbo Assembler and just keep the lasers (for now). Today's session has been cut short, because I only had some small things to do today.

After deleting the moving grid code (it will be implemented later on in the project, so I haven't axed it completely). My main goal for today is to get the sprites positioned on screen and moving. I place a nice shiny blue bat at the left of the screen, and I also put a pink (light red) bat on the right of the screen. A ball is then placed in the middle. I assemble the source and run the code. It looks much nicer, but wouldn't be much better if the sprites could actually move?

The next part is to have the ball moving. However the ball needs to move according to the direction of the X / Y axis. A couple of pointers have been made to make in order to process the X / Y direction the ball should move. Also boundaries have been set to ensure that the ball does not leave the screen. I tried to make it possible for the ball to hit the laser chars without using any sprite to charset collision routines. The trick seems to work nicely. 

Now that the ball is bouncing happily around the screen. I must get the correct player to score  points, as the ball hits the goal behind the opponent. Well, how do I work this out? First I freeze the game screen using the Action Replay freezer. Then I go into the text editor, and note down the screen character area where the scoring characters are. I note these into my notebook, and then get back into the game and into the Turbo Assembler. Some variables are added at the start of the code, then some scoring routines are added. The scoring routines are slightly more complex compared to how I am usually used to doing those. This is because I used custom characters that form the numbers. A set table was made yesterday. So I will need to read the table and store those characters to the screen. It is a bit like putting a jigsaw together. After a few minutes adding some more code to the source. It is time to test the result. Superb, it is working nicely.

My next step is now to both players working via joystick control. Player 1 (the blue bat) should be controlled with a joystick in port 2, and Player 2 (the pink bat) should be controlled with a joystick in port 1. Normally to code routines for a two player game it is easier to write macros and link those to each player. Sadly Turbo Assembler V5.F does not support macro commands, unlike cross-assemblers. So I just have to re-type the same routines again for player 2. 

Now both players are now moving quite nicely. There is only one more thing for me to do today. This time it is maximum scoring detection. When I make the title screen (Which is highly likely to fit complete with the game code source), I will want to add some in game options where a maximum number of points is set in order to win the game. So I create two maximum score pointers where one represents tens and and the other as units. Then I do a comparison of the player score and whether it has reached the maximum score set for that game. I added a border flash to test player 1 winning and a background flash to test player 2 winning. Brilliant, Result, it all works !!! 

It is now time for me to call it a day for today. However the bats cannot hit the ball. There is no sprite/sprite collision detection or animation. That will have to wait until my next session.

Wednesday 25th May 2022
Coding session #3

I don't have any more screen shots to show you at the moment, but there is some good progress. Yesterday I left the project where the players are able to score points when the ball hits the laser. Now what about allowing the bat to hit the ball? Today this is my task for the day, along with a couple of tasks. 

First the speed of both ball and bats are a bit too fast. The speed value has been reduced and now the player bats and the ball moves just about right. There needs to be a collision detection between the ball and the two bats. I made a one size fits all sprites collision detection, which appears to work quite nicely in the game. Also the ball can rebound from the bat as well as the two lasers. 

I am very happy with the sprite to sprite collision detection. It seems to be working quite nicely on my theC64. Now it is time to try add a bit of AI code into player 2 (should the player select to play against the computer by choosing 1 player mode). I want to make the computer as smart as possible to be able to hit the ball and make it harder for the player to score a goal, unless it is possible. In AI mode, the value of player 2's vertical position is set to match the ball's vertical position. However the ball is faster. I test run the code and the bat in AI mode is hitting the ball quite nicely. There might need to be some more work to be done in this feature. Perhaps when I next get back onto it this weekend.

You may remember a couple of days ago, I mentioned about the scrolling tiles having an issue. That issue of course was where there was some tearing around the charsets. It turns out that I was close to being correct with the moving tile effect, but I grabbed the chars too and stored the chars too late. Today this issue has been solved.

Well that is enough for today. My next session with this project is most likely to be on Saturday (the project continues on Sunday instead), where I move both players closer to the laser beams, and also try and improve the graphics, sprites and perhaps implement some power ups/features to enhance game play. Tomorrow night and Friday night have been reserved for Captain Ishtar and Cruiser-X 79 level 9.

Sunday 29th May 2022
Coding session #4:

This continues from the last coding session of this game. The player is active, and also AI control has been added as well, but the AI just keeps on following the ball and appears to be rough. I might have to solve this issue later on in the project, since I haven't done AI programming before. It is slightly harder than I thought. It has also made the game a lot harder. 

Today I load in the source code and then work on the explosion. The explosion should take effect whenever the the ball leaves the opponent's goal. Then a point should be scored. The first thing to do is to locate the code that jumps to the scoring, then add a jump subroutine that calls a loop to read an exploding sprites table, and make the player explode - then restore the player's sprite after the exploding routine has finished. Perfect, the explosion work but I still don't like the explosion sprites very much. 

Next I notice how the bat and ball collision detection is quite clumsy at times. The ball is bouncing around the bat too often. The collision register is just too big and the co-ordinates need to be reduced in order to fit the bat. After a test the ball bounces back. There is still another problem, which I shall deal with. The ball's X direction rebounds correctly, but the ball's Y direction appears to stick to the same direction after the bat hits it. The Y direction of the ball only rebounds after it has hit the minimum or maximum vertical position set on screen. 

To solve the issue with the ball rebound, I can add a new pointer, which detects whether  or not player 1 or player 2 can bounce  the ball upwards or downwards after hitting the ball. Basically, if the player shifts up, the ball will bounce up, if the player shifts down, the ball will bounce that direction. If the ball stays idle, then the last Y position read from the joystick is automatically stored to the ball and it will rebound that direction.

Problem solved, now to make things harder and quite funnier, the bats can hit the ball, and the ball bounces against the walls. This makes it pretty much too easy and boring to play. However I have come up with a cunning plan. Wouldn't it be more fun, and crazy to have the ball increasing the speed after a specific number of rebounds? I have now placed in a rebound counter and set it to 10 rebounds. After 10 rebounds have expired, the ball will bounce faster, and make the game slightly more frantic than before. This affects both the X and the Y speed of the ball. After testing, this is looking much better. I shall now save the game code to my work disk image on USB (plugged into theC64), and do a backup of it on my dev system, ready for my next task. More graphics.

I can take a little break from the code and now work a bit more on the graphics. There's going to be an improved explosion for the bat and some new sprites. I have some ideas what those could be. Still  no screenshots to show you, but hopefully the next session should have one or two more.

One more thing to add. The game will not be called "POING 3", I have renamed it as POING Ultra instead. The deadline for the PONG compo is coming closer. About 3 weeks in fact, so I'd better get my skates on !!!

Tuesday 31st May 2022
More game graphics and a tiny bit of code.

I am mainly focussed doing some more game graphics today. I will be doing the game sprites, then afterwards I will be improving the in game character set graphics slightly, so that the game looks much better. Okay, I shall start with loading up theC64 and setting everything up. Action Replay cartridge... ready ... PD Utilities disk image ... ready ... Sprite editor ... ready ... previous sprites ... ready.

I think you have worked out what I am making right now. That's right, the game sprites. Using the cursor keys and the * key on theC64, I removed all of the frames that built the explosion effect. The reason for that was because I wasn't very happy with it. I then draw some new explosion sprite frames. They look much better. I'm happy with that. 

POING Ultra shouldn't just be all about player 1 and player 2 in court, bashing the ball and attempting to reach their opponent's goal. I want to add some kind of fun additional features to the game. The court needs an alien. That's right, a ball and power up spawning alien. The alien can consist of 4 frames for animation. It will cycle the existing colours inside it, and also animate lasers above and beside it. Afterwards I will draw the power ups. They are slow ball (ball with two chevrons pointing to the left), fast ball (ball with two chevrons pointing to the right), freeze bat (bat in ice), speed bat (bat with two chevrons pointing to the right), slow bat (bat with two chevrons pointing to the left), reverse bat (bat with a double-sided arrow underneath), lose 2 points (warning sign with -2 underneath) and instant death (skull and crossbones). 

The power up sprites are finished, I'm very happy with those, so now it is just draw 1 UP WINS and 2 UP WINS sprites and I'm done with the game sprites. Brilliant, I am very happy with the result and the sprites are all done. I'm running out of space on workdisk 001, so I have moved onto workdisk 002 to save the sprites. Below is a video (recorded from VICE) of all of the game sprites I have made for POING Ultra. There are not many sprites there, but I think that there is enough of those for this game anyway. Also I have to keep my memory well managed.

You may remember that a few days I worked on the game graphics. I was pleased with how they looked, but I felt that something really needs to be done with the scoring objects. I now load up the Multi Screen Construction Kit and insert disk 001, to load in the charset graphics, object and screen data and colour data. Then the charsets get edited. The letter characters have been reduced a little, and the scoring characters have been tweaked to look a bit like a digital clock. No colour has been changed because there was no need for me to do that. I adjust the characters that form the blue tiles, and they look a lot better. I attach work disk 002 and save the graphics to that disk image.

Next it is time to tweak the main program. I load up Turbo Assembler, then I zero fill memory $0800-$95ff. Then I load in the old game graphics data file from disk 001. Disk 002 then gets attached and I load the new sprites and charset data. Then the complete data file gets saved as gamedata2. Next I go into the Turbo Assembler, and load in the game code from Disk 001. I do a test run. The new explosion sprites were sort of working, but were missing some sprites. So I expanded the explosion sprite frame table, and then saved everything to Disk 002. One more test and great, the new sprites and graphics are working fine. Here's a second video in today's featuring the new game graphics.

Wednesday 1st June 2022
Coding #5 and a bit of a change

Last night I watched Phaze101's stream announcing the PONG 50th Anniversary and the Towel Day feature. Sadly I could not watch the whole of the stream due to it getting late. I also learned that there is one specific feature that is missing in my game. Basically two major flaws I did with the original POING and POING 2 was that the player could only whack the ball diagonally and only the X-Axis of the ball was altered. Although POING ULTRA has a diagonal change in direction when the bat is moving up or down. When moving idle, the ball should move horizontally. 

It is time for me to load up the Turbo Assembler and work on some code to fix the problem with the ball angle changes. It is easily solved. When I was programming a routine 3 or 4 days ago of the player moving. I added a labelled pointer known as player1dir (or was it bat1dir?), and player2dir (or was it bat2dir?). If the value of the player direction = 0, it means the ball's Y-Axis goes up, if however the player direction = 1 the Y-Axis of the ball goes down. What if the bat is still. Previously there were only two directions for the ball. Now if I add a values of 2 to the player1dir and player2dir, and add a check where no joystick control takes place. It should work. ... It does.

Now my next task is to add the power ups and the power up spawning alien (Sprite 3). First I add the code to place it in the middle centre of the screen. That's good it's there, and it is green. Next, I shall animate the sprite to use its four frames. That looks even better. Now let's colour cycle it with a blue/purple pulsating colour. Nice, it fits perfectly. There is just one more trick to do to animate the sprite. I need the alien to move up and down. After a label pointer for the spawn direction, and a bit of code, it works nicely. At the moment the ball spawns from out of nowhere. I want it to spawn out of the power up spawning alien. The value of the X, Y position of the ball sprite is now stored onto the X, Y position of the spawning alien. A quick test, and YES! It is working great. The ball spawns out of the alien every time the game starts, or the ball moves out of the screen.

The spawning alien spawns the balls no problem, but I now have to work on the random power ups generation. Each power up should generate after a set time period, and also the direction selected should also be chosen at random. I create a label pointer for the spawn direction. Then I call a routine to test the directional movement of the power up sprite (Sprite 4). First the routine is tested with the pointer set to 0 (left). Great, the sprite is moving to the left. Next a routine is tested with the pointer set to 1 (right). Yes, that also works nicely. Now it is time to create a pointer of the power up, and then call a subroutine which selects one of eight different power ups at random, then store it to the power up pointer. The code listing gets saved, and I test the game code. The bats are hitting the balls, the balls are working how they should, and the alien is spitting out power ups. Brilliant I'm happy with that.

Before I call it a day, there is at least one more thing I want to do today. That is to add a sprite to sprite collision detection routine for the players and the power up. Unfortunately that did not go according to plan, as the version of Turbo Assembler I chose for this project didn't allow me to type in any more code. It spat out a label overflow error message. I might have to find another assembler. I don't want to fail my challenge like I did with the past 3. All was going really well with this game project until I encountered this problem.

I loaded one of my old PD disks, which had an older version of Turbo Assembler (V5.2 improved by The Beast/The Ancient Temple), and I loaded the sequential file containing my source code. Although it has less memory for long listings, the program I was writing did not exceed its limitations. I am now able to finish off the collision test subroutine. Great, the collision routine works, and the test is complete. Now I can save the file and then tomorrow, I shall add the actual power up routines and put them in to action. 

I shall now call it for the day and continue with the project some time tomorrow. Then hopefully on Saturday, I could be ready to make sound effects and music for the game. I'm still well on track for the submission deadline for RPI's PONG 50th Anniversary game jam.

Thursday 2nd June 2022
Coding #6

You may have read that yesterday's session of POING Ultra had power ups added to the game code, but no effects were taking place, due to time. Today I have decided to put the power ups into action. First of all some labels are created to make the value of the sprite frames that form the power ups. Then at the bottom of the code, the numbered bytes are renamed into the sprite frame labels. We could actually call those variables.

Next I edit the game code player to power up collision routine so that instead of changing the colour of the player, the  power up gives some kind of effect. The routines check the frame value of the hardware sprite type 4. If the value of the sprite = the sprite frame read from the table (selected at random) the effect should take place on the player who collects it. Of course I have to alter some of the player's code so that some of the power ups take affect. For example the bat in ice should freeze the player permanently and ignores control (or computer AI mode) until a ball reaches the goal. Also the $DC00 and $DC01 values have to be swapped if the player collects the bat icon with an arrow pointing both directions. Also the bat should use fastest or slowest speed during game play until the ball passes it. There is also a power up which sets the speed of the ball, subtract 2 points from the player who collects the power up and also a power up, which just jumps to the player's death subroutine. I assemble the game and test the power ups in action. Great!!! they are working. 

There is just one more thing I will need to do now. A week ago, players were able to score points and after a maximum score has reached. Player 1 winning called a loop that flashed the border, and player 2  winning called a loop that flashed. A couple of days ago I drew a single sprite to represent which player has won the match. All I need to do is add those correct sprites in place, and a copy of the synchronized timer loop, with expanded sprites msb and background animation. Job done. I assemble test the game once more. I give it a play. Well, I have to admit it is looking good. The only downside is that it is lacking music and sound effects and a title screen with in game options. Not to worry, this will be next on my list. This weekend in fact. Anyway, enjoy this little video of the work done so far. 

Oh, okay, I spotted a bug in the ball speed reduction. I'll fix that this weekend before I code the sound effects and then work on the game music.

Saturday 4th June 2022
Coding #7 

I will be programming in game sound effects today. First, I will create some pointers for PAL/NTSC video detection. Next, I will make some tables to make my very own in game sound effects. I will need to create a sound option point. Then create some tables to represent the sound effects. Unfortunately now, I can't add anymore code or bytes, because the Turbo Assembler has thrown a wobbly at me on theC64. I received another "LABEL OVERLOAD". Just as I thought the main game was close to completion, a problem like this happens. I write the code to the work disk as a sequential file and I will continue with the code later on. I honestly want to finish this project on theC64 full size. Unfortunately the version of Turbo Assembler blocked me from producing any more code. My last hope will be the Turbo Action ROM by Dekadence. 

Sunday 5th June 2022
Bitmap graphics and music #1

After yesterday's major disappointment and Turbo Assembler blocking me from adding any more labels/pointers (which I dearly need to include in the project). I have decided to relax and work on making some music and also some graphics. First I load up DMC V4.0 and compose the title music. Hmm, yes, the music is very upbeat - and feels like one of those Happy Hardcore soundtracks. I like the composition. I will include it in the title screen. The music will need to be relocated. Next I compose the in game music. The music is slightly less happy hardcore, but more like early 90s techno or something like that. That tune doesn't need to be relocated. 

Next I load Face Painter into my theC64 and draw some graphics. I am drawing a colourful logo for the title screen. This actually took more time than I expected because of not being very happy with the design of my previous logos and  scrapping the ideas. Now this logo (Pictured below) looks ever so nice. I may be no graphics artist, but I am really happy with this logo. 

Next I start a loading bitmap for the game. It should be based on the actual game. The picture should have two lasers, two bats, a ball, and possibly a few other things. The picture is not yet finished, but I have been enjoying working on Face Painter. It is likely that in the future I could be drawing more logos on the C64 - mainly for stuff like intros, game projects, and of course Scene World. This is actually quite an achievement. Tomorrow, I shall search for a better Turbo Assembler, and pop it onto theC64. I'm thinking about SounDemon's TASM/CODENET,which I enhanced a whole SEUCK game (Rocket and Roll) with. If the cartridge image works on theC64.

Monday 6th June 2022
More coding #8 and headaches

During the weekend I came across some very awkward programming pitfalls. Turbo Assembler blocking me from adding any more code, etc. I was unable to finish the sound effects off for the game code. That was until I had some helpful advice from Robin, regarding the Turbo Assembler. It is best to save the code to a sequential file and the load it up into the assembler once more. I tried a few versions of Turbo Assembler. The trick did work, but I thought I try TASM/CODENET first. Unfortunately, I made a bad choice. This is because the assembler was operating very slow on theC64 (it also lags in VICE, so not recommended unless using on the Ultimate64 or a stock C64 with 1541Ultimate 2). I even tried it on my Ultimate 64. Nah, Turbo Action Replay by Dekadence keyboard input lags too much. 

I decided to change the cartridge image, and tried Cyberpunx's Retro Replay V3.8Q. It also has a built in Turbo Assembler. I load up the sequential file that was saved. It loads up, and I continue with the sound effects tables. After setting up sound effects table and implementing it into the SFX player (and setting values to the SFX). I get really good results. The sounds are all working perfectly. 

The game is working out really well, there are sound effects in place. I just need to add one more trick to the game code. The alien that spawns the balls and power ups. It would be interesting to add a rebound X whenever the ball hits the spawning alien. So if the player hits the ball, and it hits the alien, the ball's vertical position should reflect towards the player's goal. Of course, that was a quick and easy fix. I test the game once more and watch everything in action. Absolutely brilliant. All is working nicely.

Before I start working on the title screen (game options), I load up the new in game music and try it out in the game. Also I move the screen and colour data $0800-$0fff to $4800-$4cff as $0800-$0fff is now replaced by the 2x2 character set which I have made for the scroll text. I save all of the new game data, and then I start coding the title screen. 

First I switch off all of the IRQ raster interrupts and switch the screen off in order to initialise the routines. I prepare the logo data and copy from estimated Koalapaint colour RAM and video RAM memory and paste it to BANK 2 screen RAM ($4400-$45b8) and the colour RAM data goes directily to the $D800-$D5B8 memory. Drawing of each colour and video RAM data uses 40 columns and 9 rows. Then I set up three IRQ raster interrupts, where the top raster represents a a bitmap logo, the second IRQ represents the 1x1 character set text and the last IRQ represents the smooth 2x2 scroll text, synchronized timer value of 1, and PAL/NTSC music player. Of course I code the PAL/NTSC music speed player and run it. Hmm, yes, it looks okay, but a bit messy. The logo isn't loaded in place yet, but I can leave it as that.

Next I go to the Retro Replay fast load BASIC and then I edit the text to add names of all of the in game objects. Including the bat, ball, spawning alien and power ups. Then I capture the text lines using the Machine Code monitor's Transfer subroutine. Afterwards, I edit the game options menu text for the front end. I grab the text and put that into place. Finally I write a scroll text inside the machine code monitor, where free space is available. Then I save everything as GAMEDATA5.

Back to the Turbo Assembler, I first code the sprite displayer and text underneath to represent the sprite. The text displayer is controlled by a simple delay subroutine, which will count 256 cycles before it switches to the next text in line. I test run the title screen. Nice, it is working. Next I work on the 2x2 scroll text. I test the title code. Good, the scroll is working, but I must store the pointer value to $D016 to have it move more smoothly. I did that. Great. It is all working. I still have more to do on this, but I'll do that tomorrow. I save the text to disk ready for the next session.

Tuesday 7th June 2022
Coding #8 and extra headaches

I continue programming the title screen. All has been going really well, until "LABEL OVERFLOW" constantly popped by on the screen. I made several attempts at saving the source code using the -W function and re-loading everything, but the problem still occurred. I was so close, close to the coding side end of the game project. I will have to cheat the very last part of the coding phase. The source code sequential file is exported to PC assembler format, for use in 64TASS. I also create a separate folder to put all the program files in  place. - After finishing the code for the title screen. Hopefully, I can re-convert to Turbo Assembler, and then edit the last bit of code. Sadly it cannot be today. 

Wednesday 8th June 2022
Coding #9 and I'm nearly there. 

I have been finishing off the title screen code today in 64TASS also I have made some new scrolling voids and colour table. I tried to convert the complete source code to Turbo Assembler. Unfortunately I have produced too much code and the Turbo Assembler has crashed. The reason for this problem is because I also included the title code as the same file as the game code and hoped that I would get away with it. WRONG MOVE!!! 

Now, the code is going to be split into two separate source files. One for the title screen and one game options, and the other for the game. I think that is more or less a sensible choice. Of course I will have to check where the pointers are for the game menu settings.

I also had a go at converting the 64TASS code back to Turbo Assembler for the final production. Unfortunately things did not go according to plan. I used Holy Moses' 64TASS to Turbo Assembler converter which converted 64TASS code into Turbo Assembler. I load up the title screen assembly source and edited it to work in Turbo Assembler source. However when it came to editing the game source code to work in Turbo Assembler - a lot of labels and stuff had gone missing. It looks as if 64TASS to Turbo Assembler is limited with its file size.

Thursday 9th June 2022
Tweaking and fixing

I have been tweaking the graphics for the main title screen. The character sets to be honest. They looked too much like the character set you would have seen in the SEUCK menu. Instead, I decided to make a minor adjustment to my character set and make it look more chunky and fun. I have used Cunieform to edit the chars. Next I load up Sprite Pad. The game sprites look pretty messy and ugly. Especially the power up spawning alien, and the power ups. I make some tidier sprites, then assemble and run the game. Great, it looks so much better. Check out the new front end :)

Now there is still one thing that bugs me in the main game. There is a case where the player spawns straight away and picks up a power up, it goes into effect. That is not really a fair way on the player to collect something like a frozen player power up or instant death. So I have decided to add one more feature to the game. A short term shield every time the player spawns into the game field. The power ups can sail past the player while it is in shield mode. I fixed these in place and finally the game is finished. Well, not quite - I have the final loader picture to finish off, and also a loading tune. That will take place tomorrow.

I know this is a lengthy blog entry, but you will be pleased to hear that you have nearly reached the end of it.

Friday 10th June + Saturday 11th June 2022
A bit of drawing, more music, tweaking and final mastering

Finally this is my very last entry to this very lengthy blog. I start this weekend's session by typing a longer scroll text, as I found memory to fit a larger one on Thursday. After doing that, I transfer the new scroll to the source code and compile the code in 64TASS. It fits nicely. 

The next thing for me to do is to finish off the loading picture. I load up Face Painter and draw more stuff onto the screen. Those included score and the ball and power up spawning alien. The picture looks quite funny, but I am really happy with how I progressed drawing the picture. I am no artist, but it was good fun. 

After finishing off the loading bitmap, I needed to have something for it. A loading tune. I load up the DMC V4.0 and compose a tune. Unfortunately my loader tune didn't really suit the theme for the game, and I saved the tune for a future production. So I worked on something more happy, like with the rest of the game. It was 90s techno/trance/happy hardcore, you name it :) 

The tune is finished, I now have to port all the data to my 64TASS and generate a picture linker, before I do the last bit of the project, the disk and digital tape mastering. After building the raw versions of the game project and the picture linker. I built everything with 64TASS and crunched all of the necessary files with the Exomizer, with no decrunch effect option.

Next I prepare the files for the tape mastering stage. I load up my fun Tape Master Pro V4.0, edit the loading scroll text, and then made a tape mastering D64 (just in case people want to make their own free physical copies of the game onto a tape or something like that). I then prepare the tape master. My master tape for recording on threw red border load errors. Mind you, it is a very old C90 tape, which I used many times. As an alternative I used the "capture save to tape" option instead. The loader worked.

Finally the game production is finished and ready to be submitted to Retro Programmer's Inside. The game will be publicly available after the deadline of the PONG 50th Anniversary challenge, on 20th June 2022.The web site is

Saturday, 14 May 2022

Cruiser-X 79 - Shackled with Chains

 So far 6 levels were created and developed during this project. Now it was time for me to work on level 7 - Branded with Chains. Before watching some TV, I started on working on level 7 of Cruiser-X 79. Since the previous two levels were mainly based inside enemy bases/worlds. I decided to set this level back into space. Also I wanted to add some cool effect to the level as well.

The first thing I did for level 7. I loaded up level 2's data. Then I completely cleared the map (and saved it as level 7, just in case I saved the file incorrectly as level 2). I then set the colour scheme and set up the stars and planets (Which after Saul's update, I hope to be spiral galaxies). The project got saved again and it was time to watch some TV. 

The next day I loaded up the project, and I worked on making level 7's graphics. While doing this, I was listening to some music on Deepsid throughout. I designed the base layout, and constructed some large and also small chains. The large chains have been set to be static, and the small chains have been set at the scrolling chars. This is to give a good visual, when the lower chains are inside a shaft or between the two large chains. I also added a bit of branding to the game as well. That's right 'TND' has been embedded on some of the bases. I saved all the work.

Next I loaded up Goat Tracker and I worked on the in game music. Although the game consists of chains and things like that. I wanted to so something like a moderate speed up-tempo soundtrack to suit the game's level. After listening to tunes from Fairlight demos during developing the graphics. I thought that type of style of music might be ideal for the game. I worked on the sound tracks for a couple of hours or so, and came out with a masterpiece. I saved the piece of music.

I went back to Charpad to export the map, charset and tiles data to my C64 Studio project. Then I loaded up C64 Studio and edited the level colour table to match my Charpad file. Then built the batch file, so that level 7's music and graphics data gets compressed. Then test run the level. It looked great. Everything unpacked fine and at the correct colour. The music blended in well with the game, but I think I made the tune too long. It didn't finish when near to the end of the level. I think the intro of the tune could be tool long, so I might just remove the intro when I come back to the music perhaps next week. Still, I am pretty pleased with the result of Level 7.

Saturday, 30 April 2022

Cruiser-X 79: Fear the Freeze

 First of all, a quick note to let you know that during may, this project will be paused for a short period of time to make way for my 4K game for the Craptastic 2022 game development competition. It is unknown how long it will take me to write my 4K game. I'm hoping about 2 or 3 weeks or so.

Secondly some fantastic news about my levels. Saul has been working on updating my level designs, and they have been turning out pretty well. I am really pleased with the overall result from levels 2-5 (As level 1 needed nothing updated). Out of all of the levels so far, "Level 5" is my personal favourite.

On Thursday and Friday, I started with designing Level 6 and yesterday I did some more updates to the level and finished making the map. Level 6 is a freezing cold stage in which contains plenty of ice. I used Level 3's graphics data, as there was a nice cube in the space background, which looks pretty good for this level. The colour scheme uses cyan, light blue and white. However, Saul might decide on some different colours. The player ship is cyan, but it still can be seen (thankfully). I wanted to make level 6 harder than level 5, so more deadly background was added.

Today I worked on adding the music and putting the test level together. The music which I have chosen for level 6 is a rendition of one of my trance tracks, Ice Dream, which I originally did for Scene World about 2 years ago. I did a PC remix of the same tune (See: Nucleo448 - Trance Remix) and also in Nucleo 448 as in game music. I liked this composition a lot, so I decided to do another version for Cruiser-X 79. 

The level data got exported as character set, tiles, map and music data. Then crunched through the Exomizer V3.1.1 (in V2 mode). The level table got modified once more. I compiled and run the game into VICE, and played all the way to level 6. Argh, I think I have made the level too difficult with all those big walls, which the player has to avoid. However, I will give those a tweak next time I go back into the game project, and of course before I work on level 7 (unless of cource Saul has done it already). However, I do like the ice-blue theme in that level and the wonderful in game music. 

That's it for now with Cruiser-X 79. The project is now paused for a short term until after my 4K Craptastic Compo 2022 entry is finished and submitted. Then I'll be back onto it.

Friday, 15 April 2022

Cruiser-X 79: Having green fingers

 This week was almost a week that wasn't for Cruiser-X 79. I was using the weekend to make a V1.2 of the SEUCK Title Screen Maker. However, I wanted to improve the utility and created a V1.3. Basically SEUCK Title Screen Maker is a utility that allows you to create a brand new front with a nice logo, with optional hi score table and music in the background without needing to code. Then replaces the old SEUCK title screen with something more colourful. After I thought I was done with V1.2, I replaced it with V1.3 by fixing the music player bug, and SFX missing channel bug. Everything else was working and I was very pleased that it was final.

If you fancy trying out the SEUCK Title Screen Maker V1.3 please check this link below:

Anyway, this blog entry is NOT supposed to be about the SEUCK Title Maker. Instead it is about “Cruiser-X 79” and its progress. I had a week's break from it last week, as I felt a bit unwell with a heavy cold. It is more or less the Easter holiday, and I thought I should work on level 5 for the game. I have been thinking about it for some time. So far I had a level based in space, a level inside an enemy base, a diamond world, and also a bubble world. What was in store for level 5? … Vegetation.

Yes, that's right. I wanted to make an inner alien base, which also contains vegetation. Due to the limited number of collision characters. I did not want the vegetation to become a deadly background. Instead, they are background. I also created some brown zig-zags as the main background, rather than space. This is because I want that part of the background to have a static effect while the rest of the background was scrolling over it.

The design of level 5's base is based on the very first level. However there are to be some form of vegetation/plants bordering some parts of the background. The enemy base is also a mixture of green, brown and grey. I also wanted to add some boundaries, in which the player should avoid crashing into. Loads of them in fact. After I scanned through the whole map in Charpad. It took me about a couple of hours, if not more to carefully construct the level. Unlike level 4, the boundaries which the player can crash into are thicker and nastier.

After feeling very happy with the level design. I saved the background graphics and then exported the character set, tile and map data as a raw binary file for compiling and testing in the game. Before I compile and test everything, I decided to work on the music. I loaded up Goat Tracker V2.76 (enhanced version) and I worked on the main in game music. It is a thumping in game trance soundtrack. You can hear the whole tune (without the sound effects) in the video below. I think it fits into the level of this game quite nicely. The music was then imported into the game project source.

I modified the build parameters of the game code and the build batch file. Then I compiled and executed the project and gave the game a test run. The result turned out great.

If level 5 is cool. Wait until I work on Level 6. It's going be a cold themed level that is for sure. For now, enjoy the game play video of level 5 and also the music uninterrupted by SFX.

Cruiser-X 79: The Final Battle

 Just a short entry today. It is about level 16 of Cruiser-X 79. I decided to re-use the one of the earlier level designs as a rough design ...