The end is near - Can we me make it? ...

18th + 19th December 2015

Wow. Some more free time at last. Well, more work on Vortex Crystals then. Before any more programming had taken place in the game project. I asked Alf if he'd like flashing lights animation added to the background. After he suggested that it was a great idea. I worked on mapping the values of the char colours for the flashing lights. After compiling the code, the animation turned out quite nice. I sent the new build to Alf and he liked it.

The next step was to work on the end screen (since the whole game engine is finished right now) . A couple of months back, I designed the end screen using the example background, and crunched it - but didn't actually test it until yesterday. The result turned out pretty well. So I worked on the animation scenes. It involves the player attempting to make an escape from the V-Tex complex (After completing room 16). What happens next, I will not tell you, but the ending turned out GREAT. I even had ENOUGH memory to fit the ending into the code and compile a 16KB cartridge.

After finishing the end screen, I worked on doing a phase of bug fixing. I felt the player was jumping too high in the game, so I halved the jump duration on the player. Unfortunately that didn't work out that well. The jumping height was too little. It made things more impossible for the player to be able to jump high enough on to some platforms and conveyor belts. So I increased the jump height by a quarter. It looked and felt much better.

I wanted to add some bonus scoring to the game code, so that the player gains a bonus number of points, according to the number of bullets the player carries. Of course if the player dies - default bullet amount will be 40. Only at the start of each level, the player starts with 50 bullets. I also had enough space to add a flashing text routine. After finishing with the project (for today) and email Alf the latest build. I ported the game on to my USB dongle, and play tested it on my C64, via the 1541Ultimate 2. Really happy with the result so far. ... but is the game finished yet? ...

Not quite. Although I can say it is probably  99% finished, it needs a little bit more bug fixing, a pause+quit game function, and then pass it over to one of my C64 scene buddies to NTSC fix it before the final compiling and submission. :)

After the compo - I intend to extend the code a bit more, to give out more frames for the in game animation. Add additional in game options, a better looking front end presentation, hi-score table, etc. Apart from those - the main game stays the same.

Alien Invasion

13th November 2015

Just to let you know that progress for Vortex Crystals is still under development. However, on Friday 13th November. Disaster struck on my HDD. When I tried to load the assembly source file of the Vortex Crystals, I ended up with a blank file as the main file. This happened after an update was installed, and the PC HDD was undergoing repairs by the Op System boot up. I tried copying the file from the backup drive, and sadly it was the older source file and incorrect. Damn, all is lost ... Well not exactly, here's what happened.

When I'm working physically, and feel tired, I can get myself lost in places, and the same with file organisation. I spent most of my time searching for the correct backup source of the missing code on that day. Thankfully, it got found, and I was able to continue doing more levels for the game. (grin). 7 levels were already complete, so I worked on levels 8 and 9. Level 9 introduces 'I-Droid', the eye type of alien.

16th November 2015

More progress with the level setup, but I came across a small problem with level 10. Alf forgot to add a door on to the stage. So in order to resolve this problem. I decided to disguise one of the alien spawn gates as an exit. Therefore making this level more challenging. Then I started on doing level 11. This level introduces two new and harder aliens, which are the Squidroid (10 hits to kill) and Robot (8 hits to kill). These later levels are planned to frustrate the player more, as the player only has a limited amount of ammo to fire. Shooting 3 aliens will give the player 10 extra ammo, if the power up box is picked up straight away. Later levels are also intending to get even more frustrating, when the simple aliens (from levels 1 - 10) will not be appearing on the later levels. :)


The deadline is about 2 months and a half away for this game to be entered to the compo, and I'm quite confident that it will be finished in time. :)

Stay tuned ...

Level it up

25th - 31st October 2015

Another week has flown past, and yet more progress on the project 'Vortex Crystals' has risen. Alf Yngve has mailed me seven brand new levels, and another 3 aliens for me to play around with. Most of the hard work was done today (Since I have been doing more SEUDS 4 work in between).  Last time I got the player to be able to pick up objects that was spawned from aliens. What now? Well, a bit on level setup and some sprite/character collision.

Last night I captured each level screen from the SEUCK workfile in VICE, and compressed each level separately using Exomizer V2.09. I also imported Alf's new sprites into the game sprite data as well (These will start to appear on levels 5-16, but I have 7 levels at the moment and Alf hopes to finish those over the weekend.).

First of all today, I imported the new game sprites into the source, and also setup some more subroutines to form three new enemies, which I have called:

Squidroid: The Squidroid is a robotic squid like alien, which will be able to move left/right, up/down at a 2x the original enemy speed. It will also be a hard alien to battle, since it will have 10 lives. The airborne enemy will appear in later levels.

I-Droid: An alien droid, which is armed with an eye camera. This alien will be moving at 2x the original enemy speed, but will have 5 lives to kill it.

Robot: The robot is ground based, and will walk left/right at 2x the enemy speed. It will have 8 lives to kill it. The enemy will appear in later levels.

I was very happy with the result of the first level and the framework, in general, so now it is time to setup some more levels. Before I did that, I added a Level Complete tune and well done text on to the central panel. Then called for the next level to increment one byte and jump straight back to the main game loop code (Which sets up the level data and decompresses the next screen).

Most of today I have been working on some byte tables to setup each sprite type, sprite position, colour, background colour settings and low + high bytes of addresses where to de-compress the level data. Then I programmed a simple timer loop, which will setup the current table position, and setup the actual level. Unfortunately not all levels displayed correctly. I was scratching my head to find out what may have caused this. Each screen did de-crunch, but the display for each EVEN level was exactly the same as the previous ODD level. I carried out a little investigation to find out why this happened when running the game maps workfile, saved as Sideways SEUCK 'Finished Game State'. It turned out that double-buffering was used. So I recaptured each screen in VICE, exported the colour + screen data and then compressed the level screen data again. Then I imported the data into the game's source code folder. Assembled, compiled, and executed the game project again ... It worked much better.

Now the level screens were correct it was time for me to add a little more code to the conveyor belt chars. If the player moves (or jumps) on to a conveyor belt. It should travel. So I added a subroutine which pulled the player backwards or forwards on the belt. ROR + ROL charset animation was also added to the conveyor-belt chars to give the same sort of effect, pushing/pulling the player as it tries to move.

Finally, I played around with the level tables, for levels 1 - 3, I setup the enemy sprite type, re-spawn position, background+multicolour and a few other things. Now I have 3 working levels, and the result is quite pleasing :)

I still have other levels to setup, but that can be done from Monday - next week. Stay tuned to hear more progress with this platform Shoot 'Em Up.

Blast those aliens

22nd October 2015

After yesterday's infestation of aliens. I have been working on more of Vortex Crystals this morning, and later in the afternoon. Well, I am still on my holiday leave until this weekend - so what should you expect? ... Yesterday, I worked on positioning the aliens and getting them to move around. Today is a completely different task.

Since the game allowed the player to shoot bullets, let the aliens walk about and the player move around the game area. I thought I was done with this stage. Not yet ... I received an email from Alf Yngve, indicating that the last WIP preview I showed him had a major restriction with the player's jumping on the very top platform. So I decided to alter the interrupts routine and open the top and bottom borders - but NOT allow any sprites to display at the very bottom or the very top of the border. The trick worked.

Now came the fun part of the game's framework. We have already had the running and jumping phase, so now it is the 'shooting' phase. The player can shoot already, but there was no specific collision set where a bullet hits an alien. A few routines were programmed so that according to each alien, a collision detection routine gets called. The first test was to allow the player to fire the bullet and detect the collision. Simply by flashing the border (inc $d020). After I tested the bullet on each alien, it was time to make an alien explosion.

To make the alien explosion, I could choose two different methods. The longest method is to create a morph alien sprite to explosion animation for each alien sprite. Or the alternative method is to stop the bullet sprite from moving, offset the alien sprite and then morph it into an explosion. I took the second option, as it saved me time - and since there's under 3 months to get the compo entry finished, it probably is a brave move.

After testing the alien explosion routine, to see how well it works. I was very happy with the result, and decided to add lives to each alien. This will give the aliens a certain number of hits from the player's bullet, before they explode. After generating the code, and having a little play around with the source to get things right. The program worked a treat - but there is still one more thing before I close down the project for the day.

The next was to get the aliens to re-spawn after a period of time. This should occur after a few seconds the alien last died. When the timer had reached its position per alien, the alien sprite re-appeared on the platform and it was able to move its usual movement afterwards.

My final task before I closed the project down for the day (and backup my work) was to add a score to the player. I made it that only 100 points are scored for draining an amount of lives for the aliens, and 500 points for destroying one. I am pretty pleased with the result of the game's framework so far, and look forward to finishing it in the near future as well :)

The next task will be to add power ups, which might be some time this weekend.

Dare you enter the Vortex

18th October 2015

After the success of Blap 'n Bash. Another new C64 game is in the works. This time, by the way of 'Vortex Crystals' or for short 'V-Tex'. I actually started working on this project back in August 2015. Now this game is going to become a co-op with Alf Yngve, who is using the Sideways Shoot Em Up Construction Kit for designing each level screen. I'll be doing the hard work to capture each screen, and then level pack each screen using the level cruncher method in Exomizer.

So then, what is Vortex Crystals going to be all about?. Well, it is going to be a non-commercial platform game, which I hope to enter for this year's 16KB Cartridge Game Compo, run by RGCD. Each level is a static screen, which will contain mechanical aliens, such as walkers and floaters.

You have been assigned to enter a the Vortex Complex, in which you are required to pick up all of the crystals. In order to pick up the crystals, the use of UP via the joystick, will need to be read. After all of the crystals have been picked up. A key card will need to be picked up to open the exit. Unfortunately you won't be all alone in each complex. A series of aliens will be guarding the premises, by moving up/down or back and forth. The aliens can be shot dead with a number of hits- if you have enough ammo. If all crystals have been taken from each room of the complex, an alien will need to be killed, in order to retain a pass to open the security doors.

At the moment the aliens are in 3 different forms, which are as follows:




Rotora - Only moves in the air




Zorbot - A satelite robot which will move on ground




Walker - These mech aliens move on ground via bionic legs.

After destroying an alien,  after a short period of time, it will re-spawn.

Capturing the levels

I first started on the level design to build a simple template for Alf Yngve to tidy up and design more. Different background objects should use different a form of behavior. Most of it of course is static background/decoration, but there are some obstacle chars set in the background. We chosen the Shoot Em Up Construction Kit for designing the each level. Alf constructed 3 test levels. Graphics were much more improved and the obstacles looked even better. Obstacles planned for the game are as follows:

Upper platform - Player can walk or jump from this
Lower platform - If player is jumping and hits this , it should fall
Ladder - Jump should be disabled, when the player is climbing up/down a ladder
Spikes - If the player hits this, the spikes should kill it.
Conveyor belt - These will move either left or right, and move the player along
Crystals - Stored in a storage base on the wall, these should disappear after the player touches them when jumping up to grab them.

The actual game is planned to NOT be a SEUCK creation. So I used VICE M/C monitor to capture the screen and colour RAM data, and transferred it to another screen area, and then I saved each capture of the screen separately. The original background charset also got saved from SEUCK for use in the game code as well. Once I finished capturing 3 screens. I level packed each screen and colour data, using Exomizer V2.09. Then I got into programming the main game framework and composing the music.

Composing the Music

Composing the music was quite easy - and the most fun task. Last week I loaded up an old tune, in Goat Tracker V2.7 which I started to compose. It was originally called "Gilmore", as the tune was inspired by Gizmo's tunes from the Zzeppelin Games era (Psi Droid, Ninja Commando, you name it). I worked quite hard on composing music using a similar style for the game. However, I wanted to try something more uptempo and quite bassy, with drums, but not trance (You'll be pleased to hear about). Then I composed some jingles. The tunes turned out quite well, and Alf Yngve seems to like the in game music, which I did for the game.

Coding the game

Programming the main part of this game was quite simple. I created routines which can move aliens about, and also the player when controlled with Joystick port 2. However I came across a snag in the game's code. I needed to create a logic for a different  effect on the player. If the player was in air and not jumping, I had to set the logic where the player will fall. If on a platform, but not on a ladder. The player can jump. However when the player reaches the top of the ladder. It cannot advance on to the next platform. I did a little experiment to search for a solution to this problem. If that wasn't bad, then when the player descends down the ladder, it stops and ducks down at the wrong platform char.   The  good news is that I found a solution to this problem.

I froze the framework with Action Replay and played around with the screen editor. It seems that an extra char above the ladder solves the problem of not being able to walk on to a platform. Also removal of the 3 ladder chars in the bottom row also stopped the player from going to the wrong chars at the very bottom of the platform. So now each block which Alf created, will need to be re-designed adding 1 row of chars for the top of the ladder, and the bottom row with a fake ladder, or something else. So that the code can allow the player sprite walk across the platform.

The deadline for the game entry is 31st January, which gives me about 3 months to finish this game. Although I have a very busy 2 months real life ahead of me. I feel pretty confident to get this project finished in time for the compo deadline. More about my progress of this game in the near future.

... TO BE CONTINUED