Thursday 26 November 2020

2020 - The year it was

26th November 2020

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

SEUCK COMPO 2020

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

The Official C64 SEUCK Compo 2020 (including prizes)

SEUCK GAMES AND ENHANCEMENTS

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


CRAPTASTIC 4K 2020

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


theC64 CHALLENGES

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


A FEW SMALL GAME PROJECTS

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

 

DEMO SCENE

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

LEARNING NEW SKILLS

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

ADVENTURING INTO 2021

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

Wednesday 28 October 2020

Death Saw Dungeon

 23rd - 27th October 2020

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

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

DEATH SAW CHALLENGE

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

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

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

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


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

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


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

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

The site to download the game for free is:

Death Saw Challenge [c64]

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


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

Friday 18 September 2020

theC64 Challenge #3 - The CF Power Pack challenge resurrected

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

17th September 2020

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

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

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

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

 Back to the challenge:

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

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

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

DAY 1:

1. Frozen by FROST

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

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

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

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

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

2. Do the SPRITE thing

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

A simple solution was:

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

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

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

3. Now Which Font?

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

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

 

4. Where's the Editor?

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

19th September 2020

DAY 2

1. The Designer's Pencil

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

2. I like to Move It 

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

3. Know the Code

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

4. Ready Player One

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

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

5. Ready, Aim Fire

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

6. UFO sighting

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

 DAY 3 - I like to Move it Move It

 23rd September 2020

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

 DAY 4 - Fire at will

26th September 2020

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

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

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

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

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

 Day 5

27th September 2020

CRASH!

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

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

DAY 5 

4th October 2020

BOOM!

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

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

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




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

Day 6

6th October 2020

Kamikaze

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

11th October 2020

Just a load of random stuff

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

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

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

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

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

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

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

20th October 2020

Day 7 - Sounds like another unlucky evening.

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

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

Day 8: 30th October 2020

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

Day 9: 4th November 2020

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

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

Day 10: 7th November 2020

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

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


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

Day 11: 8th November 2020
 

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

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

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

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

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

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

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

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

Days 12 - 15

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

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

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




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

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

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



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


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

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

Tuesday 26 May 2020

Cruiser-X 79 Update

1st May - 26th May 2016

While things have looked very quiet on this project. It doesn't mean that we are not continuing with the game project. In fact, the hardest part of the game code is practically out of the way. There are 16 alien formation tables set up so far, but there's still more to go. For the time being I have decided to leave the additional alien group property tables for the time being and focus on trying to get the main game engine repaired.

The aliens were unable to shoot at the time, and I tried to re-install the alien firing. However because I had deleted a lot of the old code (as I assumed it wasn't necessary) C64Studio processed loads of errors. I looked through the code, and tried to work a way round fixing the error result. Good news is that I managed to find the result. I re-created the enemy firing routine, selected the aliens to fire at random (via a pointer and value selector). If the alien was alive, the pointer and the bullet was out of the screen.

After fixing the alien firing I decided to fiddle about with the front end a little more. I added a flashing effect to the game's title screen. Also a page flip routine was added in order to flip between the front end credits and also the high score table. The result turned out pretty good.

Next the main game. The aliens were originally spawning in sequence. However, I didn't want the alien groups to spawn in order of the values 1 -17, so I setup the level pointers and some custom sequence tables to get the aliens spawning in a chosen value for that particular level. The video below shows you how the feature results during game play.


Update 11/09/2020: I just want to let you know that this game has NOT been cancelled. At the moment, I am stuck in a loop where on the coding side, I cannot really continue until the new set of level graphics come in. This project is therefore currently frozen until further notice.

Friday 22 May 2020

theC64 Challenge 3 - The Forever Extending Snake

18th-22nd May 2020

I like theC64 full size. It gives me some great fun and challenges playing C64 games. But what if I wanted to actually MAKE a game on the full size computer? Well, first of all I am used to the cross-assembly/cross-compiling method in making a game. For many years, I written games using C64Studio, or ACME cross assembler. Sometimes on the Ultimate 64 I like to make little things like intros or demos. Some of my entries for the Intro Creation Compo 2019 were made on the Ultimate 64.

However, making a new C64 game on theC64 proved to me to be pretty much challenging. For a start, although I legally own an Action Replay cartridge. theC64 doesn't support freeze frame yet. So an alternative solution had taken place. I had fun writing Storm Chase during the winter of 2020 on the full size theC64. I fancied a challenge in making something slightly more advanced and different. I was going to do another of those typical pew, pew space shoot 'em ups, but at the end of the day. I decided to do something I had not attempted to do before. A Snake game, but with a twist.

On my PC I generated some blank D64's using Style's DIR master. Then I dug out a set of public domain utilities to compile on to an empty tool disk. The programs were as follows:

SPRITE EDITOR V1.2 by Faces
FONT EDITOR V1.3 by Faces
SCREEN EDITOR V2.0 by Small Change Software
STARTEXTER V2.0 by Starion
DEMO MUSIC CREATOR V2.0 (and separately, the music relocator) by Graffity (Although the file and intro mistakenly indicates it as V1.2)
CODE SUCKER MONITOR by Padua
TURBO ASSEMBLER by Omikron
XTC Packer V1.0 by Rockstar
FAST CRUEL V2.5 (From the Cruel Packet) by Galleon/Oneway

All of the tools above can be found at CSDB. 



During each session, I did save states of some of the development, in order to reduce the risk of losing my recently made files. After each session of creating graphics, music, etc. I save the files and eject the disk, and move on to something else. I had to do some of the same things a few times because for some strange reason, although I saved the files from the program in True Drive mode (which was automatically set by a default CJM file). I ended up with the unreadable *PRG splat files. It could perhaps be something to do with my USB - or perhaps I'm not using the computer right. I'm not sure, but I'm still on to the challenge.



Update: 23/05/2020: I can confirm there is a bug in true drive mode (accurate disk). It does write 0 "unreadable " *PRG on my computer. However if I disable that feature, it saves successfully. Good thing is, the programs I used had no software fast loader. So accurate disk wasn't really needed for this project.


Anyway, after completing all of the graphics, design, music, and other stuff. It was time for me to install the Code Suck Monitor. This was because I couldn't use freezer cartridges as they are not yet implemented in the current firmware. Each file had to be loaded into the planned addresses for the game project. They were as follows:

GAME CHARSET: $0800-$08FF
IN GAME MUSIC: $1000 - $1FFF
SPRITE GRAPHICS: $2000-$2FFF
GAME SCREEN AND COLOUR DATA: $3000-$37FF
TITLE SCREEN AND COLOUR DATA $3800-$3FFF
SCROLL TEXT: $4000-$47FF
GAME CODE: $4800-$5FFF
TITLE MUSIC (RELOCATED): $6000-$6FFF

I chose a relevant load address to set the M/C monitor specially for loading the files to their specific addresses. The Code Suck Monitor was placed at $7000. After a few saves and resets of theC64. I loaded in the M/C monitor and typed in SYS 28672. Then loaded each file manually with the M/C monitor.

L "GAMEFONT*",8,0800
L "GAMEMUSIC*",8,1000
L "GAMESPRITES*",8,2000
L "GAMESCREEN",8,3000
L "TITLESCREEN",8,3800
L "SCROLLTEXT",8,4000
L "TITLEMUSIC",8,6000

Since I didn't want to keep loading each file individually. I saved a snapshot of the saved files, then saved a complete package of the game files to work with as a single file:

S "GAMEDATA",8,0800,6EA0 

I exit the machine code monitor and load in the TURBO ASSEMBLER, used SYS 36864 to run the assembler. Then I worked on the code. First I mainly focused with the game's code, where routines should control the player's sprite, and move it around. Also the object and screen randomizer routines, which places specific objects. There was also the sprite/charset collision code. Two sets were made. The first set was, so that the snake is able eat or collide into objects as they appear, for example fruit, skulls and bombs. Fruit to give the player points, skulls and walls to kill the snake off, and bombs to clear the screen and also get points for a screen clear.



After the main body of the game code was done. I worked on the front end code. Then added the GET READY and GAME OVER sequences. I ended up with a full game. Now was the time to try and put the game together.

Putting the game together:
In order for me to put the game together. I had to assemble the finished code (saved first) to disk, and then save the target. Before I could do that, I did a save state for just in case something went horribly wrong. After saving to disk (in Turbo Assembler it is BACK ARROW and 5). To assemble and manually RUN the game without setting the target disk, is BACK ARROW and 3).

I reset the computer. Then I load in the Code Sucker Monitor. SYS28672 again and loaded the saved game data file. Then afterwards I loaded in the code object file, which was assembled to disk. Then I saved the file completely as a single file again using:



S "GAMECOMPILED",8,0800,6EA0

The game could not be run from BASIC. So I used the XTC Packer V1.0 to charpack compress and make an executable in BASIC. I reset the computer. Loaded the saved file from BASIC and RUN it. The program unpacked and run flawlessly.

Phase 1 was complete. Now for phase 2. Linking the TND intro presentation to the game. I ripped the intro from one of my previous game creations and put it on to the work disk. Then I use the M/C monitor again to load the TND intro and then load the game to $2c00. I then saved the intro from $0800-the end address of the game. Reset the computer, used XTC Packer V1.0. Then crunched the game with the Fast Cruel V2.5.




I then reset the machine. Loaded the game, then typed in RUN. The game loaded, de-compressed and then run. Resulting with the final production:





All there was to do was to prepare the disk with the code, game and other bits together. This was done on the PC using Style's DIR Master.

The game is currently under the final testing / bug fixing phase, but as soon as it is complete. The game will be released on to both of my pages:

The Forever Extending Hungry Snake

and

The New Dimension

Here's a video of the game in action:





Wednesday 6 May 2020

Lockdown and Loaded

13th March - 6th May 2020

Like many of you, I have been stuck indoors in lockdown. While this lock down has been in place I have been very busy on various C64 game projects. I managed to complete a few over the past 2 or 3 months. Since 15th March 2020. Since I suspect you probably be interested in reading about the game projects, rather than lockdown and all of this. Here is the line up.

Nucleo 448

I teamed up with Leonardo Vettori, to help him improve his game Nucleo 447, by giving it a set of in game enhancements. The game was of course renamed Nucleo 448. This game was originally an entry from last year's Official C64 SEUCK Compo 2019 compo. I helped Leonardo ramp this game up to be more playable and fun. With aid of Martin Piper's framework for SEUCK (SEUCK Redux). Nucleo 448 had a new front end presentation power ups (which allowed the player's bullet to fire faster), in game trance music and also enemy fire AI.



Toilet Paper Stacker

I launched a Lockdown fun compo 2020 on CSDB, in which people could enter the compo and submit either a game, demo or graphics. Music was ruled out of the compo, because there was already a music compo in place. Toilet Paper Stacker was one of these stacker type of games, with a funny theme based on past events. The idea of the game was to stack over sized toilet roll on to a cabinet so that it breaks and kill the virus.




Zzapped in the Butt

Craptastic 2020 was launched earlier on this year. Zzapped in the Butt (Guess where the name ZZapped came from ;)) is a retro style space shoot 'em up. A mother ship is waiting to invade planet Earth, but cannot enter the Earth's atmosphere. So instead, it sends out various aliens to help invade the planet. The ship has to defend its military cities from aliens. The mother ship also decides to attempt to zap your ship in the butt. The game consists of more than 30 levels. Everything crammed into 4K. Expect to see that appear on your C64 in June. :)


Cruiser X-79 (Still in progress)

The vertical scrolling shoot 'em up game project was delayed for some time, but now it has come back in action. New alien movement patterns have been added to the game's code. Not all of the aliens have been put in place, as there are still some more movements in operation. A lot more work has been put into the game project today. Where, I try and restore the alien sprite/sprite collision and do a bit more debugging. Hopefully some time later on this week (or perhaps next week) I should be able to try and restore the game's main game play and get those aliens happy blasting.


All of these games can be found and downloaded from THE NEW DIMENSION for your C64, Ultimate, or theC64

(Except for the latest Cruiser-X 79 preview and Zzapped in the Butt)

Monday 23 March 2020

Aliens Unleashed

23rd March 2020

Last Saturday, I mentioned about the problems I had with the alien movement patterns, where I made things a lot harder for myself. Especially the previous weekend. This weekend, I started on working on the alien movement groups. After Saturday's major change of the code and pointers. After following the Starfysh code, I finally got somewhere and I am now ready to continue with working on the alien movement groups.

Alien movement is based on time instead of position. Once the timer table has reached the end, the next group of aliens can spawn. I have a lot more groups of aliens to work on, which will take some time time to make. Or should I say, a lot of time to make. Especially when the total number of enemy sprites drawn result to 26. I have used the border cycle on screen as a clock, so I can count which byte the table is read at, and also where I should time out the aliens to stop them wrapping across the screen.

On the plus side, since the game preview was released Summer last year. The majority of the game code is still there. Although at the moment I have disabled the collision, in order to test the aliens for their movement.

The new set of tables are as follows:



enemy1framelo !byte <Frame_AlienType2 ;Store low-byte of alien frame
enemy1framehi !byte >Frame_AlienType2 ;Store hi-byte of alien frame 
enemy1colour  !byte $0a               ;Store colour of alien
enemy1startx  !byte $0c               ;Start X-Position   
enemy1starty  !byte $f0               ;Start Y-Position
enemy1score   !byte $01               ;Amount of points to score
enemy1lives   !byte $01               ;Number or hits to kill alien
enemy1time    !byte $18,$18,$18,$1c,$18,$18,$18,$18 ;Timed movement
enemy1speedx  !byte $00,$00,$00,$00,$00,$00,$00,$00 ;Speed of movement accordingly X
enemy1speedy  !byte $fe,$fe,$fe,$fe,$00,$00,$00,$00 ;"                             Y

2023 at a glance

2024 is here, and 2023 has been a really quiet year on the production front due to everything that had gone back to normality. The year has ...