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 dataHaving 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.