18th July 2014
Over the past few weeks, I have been working on a brand new Commodore 64 space blaster called 'X-Force'. It is a horizontal scrolling shoot 'em up (SURPRISE), which will be featuring stunning graphics and level designs by Saul Cross, and also some great music, which was composed back in the 1990's by Feekzoid from a stunning Sideways SEUCK preview of Breakthrough, whereas the full game never saw the light of day. I have of course asked Jon for his kind permission if I could use Feekzoid's Breakthrough music for this game, and permission was granted by Jon, himself.
So what's this X-Force game all about then? Well, you have been held prisoner, while exploring an alien planet called 'Darx'. The aliens recaptured your X-Force fighter, and has held you prisoner in the underground world. You manage to break out of your cell, and reach for the X-Force fighter. Just as you take off to make your escape, aliens start coming after you.
The mission is to escape from the underground worlds of planet 'Darx'. Simply by using a joystick in port 2, you must guide your X-Force fighter across enemy territory, and shoot down the aliens which to to stop you. One hit at the alien, and they're gone. To be able to escape from the each underground world, you have to face an end of level guardian. It will try and stop you before it gets away. Should the boss be destroyed after enough hits, you will gain bonus points. Should you let it escape, then you get no bonus points.
The X-Force fighter can pick up podules in which will give the space craft upgraded / downgraded lasers. Depending on whether a red or green podule has been picked up. Blue ones will give the space craft a shield and the grey ones will act as mines. Touch a grey one, if not carrying a shield, and the X-Force fighter will explode. Aliens and deadly background, animated lazers will also make the player explode - unless the player's shield has been activated.
The C64 game, 'Subterrenea' by Hewson inspired me to work on this game. 'X-Force' is being produced for the Commodore Format power pack 63, which is planned to be launched some time in October 2014 and will not be release before then (Announced on Commodore Format Archive's blog). As soon as the game is finished, it should feature loads of stunning levels, to blast your way through.The game will also be available on the TND web site a week later :) Of course, the game is going to be FREE. :)
Hope to do more work on this game some time tomorrow.
WATCH THIS SPACE :)
Friday, 18 July 2014
Tuesday, 8 July 2014
Darker than Light
3rd-8th July 2014


Back in January 2014. I worked on a SEUCK game co-op with Alf Yngve
called "Dark Force". The challenge was originally to get a first release
out for new year's day. It failed and got released later on during that
month. February/March saw a re-relase of the same game, with a few
extra enhancements. Only major drawback was the SEUCK slow-down
syndrome... Eurgh!
Now today on 8th July 2014 before I set off to my work place. I am very pleased to reveal the that the final version of Dark Force. It is Dark Force - Redux. The whole game data was imported into the SEUCK Redux frame work, which Martin Piper supplied on github. I also did a lot of additional hard work programming this production the past 4 days. Including re-programming the new front end. Enhancing the background level settings. Here's the overall result.
- Black/Blue loading screen with loading picture and music (Music from the TND intro on the disk version 'Emotions from Heaven')
- New front end with Hi-Score table, as before, but logo had to be carefully downgraded to 3 colour logo mode, due to lack of memory space for bitmaps.
- Slight tweak of an instrument on the front end tune
- Different background colour schemes for each level
- Intelligent enemy fire (Fires bullets in the direction of where the player was last positioned).
- Most important of them all ... No more SEUCK slow-down syndrome
What originally was meant to have been an experiment with SEUCK, turned into a fun 'game inspired by 'Light Force' by FTL.
If you would like to try out the SEUCK Redux engine, then check out:
Martin's C64 Repository on Github
For the C64 game Dark Force, please visit:
The New Dimension - Download games page


Back in January 2014. I worked on a SEUCK game co-op with Alf Yngve
called "Dark Force". The challenge was originally to get a first release
out for new year's day. It failed and got released later on during that
month. February/March saw a re-relase of the same game, with a few
extra enhancements. Only major drawback was the SEUCK slow-down
syndrome... Eurgh!Now today on 8th July 2014 before I set off to my work place. I am very pleased to reveal the that the final version of Dark Force. It is Dark Force - Redux. The whole game data was imported into the SEUCK Redux frame work, which Martin Piper supplied on github. I also did a lot of additional hard work programming this production the past 4 days. Including re-programming the new front end. Enhancing the background level settings. Here's the overall result.
- Black/Blue loading screen with loading picture and music (Music from the TND intro on the disk version 'Emotions from Heaven')
- New front end with Hi-Score table, as before, but logo had to be carefully downgraded to 3 colour logo mode, due to lack of memory space for bitmaps.
- Slight tweak of an instrument on the front end tune
- Different background colour schemes for each level
- Intelligent enemy fire (Fires bullets in the direction of where the player was last positioned).
- Most important of them all ... No more SEUCK slow-down syndrome
What originally was meant to have been an experiment with SEUCK, turned into a fun 'game inspired by 'Light Force' by FTL.
If you would like to try out the SEUCK Redux engine, then check out:
Martin's C64 Repository on Github
For the C64 game Dark Force, please visit:
The New Dimension - Download games page
Saturday, 14 June 2014
Production slowed down, but at least something
14th June 2014
Production on Honey Bee has slowed down, as I don't know where I am in the project now, since new graphics are still being worked on this game. I still have the 1x1 chars to play around with to build various screens for the game, but this will take some time. Slotting 1x1 chars together to form detailed level screens is taxing. Steve has sent me a PM a long while ago and he has come up with a preview snapshot of the new status bar for Honey Bee. It looks very nice. :) I hope you all like it :)
Production on Honey Bee has slowed down, as I don't know where I am in the project now, since new graphics are still being worked on this game. I still have the 1x1 chars to play around with to build various screens for the game, but this will take some time. Slotting 1x1 chars together to form detailed level screens is taxing. Steve has sent me a PM a long while ago and he has come up with a preview snapshot of the new status bar for Honey Bee. It looks very nice. :) I hope you all like it :)
Thursday, 8 May 2014
A little bit of extraction (And example code)
8th May 2014
Well, well, well. Not much news on the Honey Bee front, as I am still waiting for some more updated graphics for it. Good news however is that I received some new game graphics for one of the screens. Bad news however - it was done in char pad as 1x1 tiles. However good news is that since the game consists of 1x1 tiles. The map screen size is one screen (40 chars across x 25 down).
I extracted the character set tile data, map data and attributes data and imported it into an ACME cross assembler source. Where single screens can be drawn through a map - then colour attributes get extracted according to the screen. I had some silly results at first, but after a third attempt - the overall result worked out quite nicely.
Now here's the source code which does this job ...
;--------------------------------------------------
;1x1 tile + colour Map extractor
;--------------------------------------------------
!to "extractor.prg",cbm
*=$2000 ;Import character set
!binary "hb_charset_v2.prg",,2
*=$3000 ;Import map data (the screen matrix)
!binary "hb_map_v2.prg",,2
*=$3800 ;Import tiles data
!binary "hb_tiles_v2.prg",,2
*=$3c00 ;Import attributes (colour data)
!binary "hb_attribs_v2.prg",,2
*=$c000 ;SYS49152 to execute
ldx #$00
loop0 lda $3000,x ;Read map data from $3000
sta $0400,x ;Place on screen RAM $0400 - 256 chars
lda $3100,x ;Same again for next segment
sta $0500,x
lda $3200,x ;and again
sta $0600,x
lda $32e8,x ;and again
sta $06e8,x
inx
bne loop0
ldx #$00
loop1 ldy $0400,x ;Read the map on screen
lda $3c00,y ;Read the tile colour / attributes table
sta $d800,x ;Store to the C64 hardware char Colour RAM 256 times
ldy $0500,x ;Do the same with the next 256 chars
lda $3c00,y
sta $d900,x ;Store again ...
ldy $0600,x ;and again
lda $3c00,y
sta $da00,x
ldy $06e8,x ;and again
lda $3c00,y
sta $dae8,x
inx
bne loop1
lda #$18
sta $d018
sta $d016
lda #$0e
sta $d020
sta $d021
lda #$08
sta $d022
lda #$09
sta $d023
jmp *
Well, well, well. Not much news on the Honey Bee front, as I am still waiting for some more updated graphics for it. Good news however is that I received some new game graphics for one of the screens. Bad news however - it was done in char pad as 1x1 tiles. However good news is that since the game consists of 1x1 tiles. The map screen size is one screen (40 chars across x 25 down).
I extracted the character set tile data, map data and attributes data and imported it into an ACME cross assembler source. Where single screens can be drawn through a map - then colour attributes get extracted according to the screen. I had some silly results at first, but after a third attempt - the overall result worked out quite nicely.
Now here's the source code which does this job ...
;--------------------------------------------------
;1x1 tile + colour Map extractor
;--------------------------------------------------
!to "extractor.prg",cbm
*=$2000 ;Import character set
!binary "hb_charset_v2.prg",,2
*=$3000 ;Import map data (the screen matrix)
!binary "hb_map_v2.prg",,2
*=$3800 ;Import tiles data
!binary "hb_tiles_v2.prg",,2
*=$3c00 ;Import attributes (colour data)
!binary "hb_attribs_v2.prg",,2
*=$c000 ;SYS49152 to execute
ldx #$00
loop0 lda $3000,x ;Read map data from $3000
sta $0400,x ;Place on screen RAM $0400 - 256 chars
lda $3100,x ;Same again for next segment
sta $0500,x
lda $3200,x ;and again
sta $0600,x
lda $32e8,x ;and again
sta $06e8,x
inx
bne loop0
ldx #$00
loop1 ldy $0400,x ;Read the map on screen
lda $3c00,y ;Read the tile colour / attributes table
sta $d800,x ;Store to the C64 hardware char Colour RAM 256 times
ldy $0500,x ;Do the same with the next 256 chars
lda $3c00,y
sta $d900,x ;Store again ...
ldy $0600,x ;and again
lda $3c00,y
sta $da00,x
ldy $06e8,x ;and again
lda $3c00,y
sta $dae8,x
inx
bne loop1
lda #$18
sta $d018
sta $d016
lda #$0e
sta $d020
sta $d021
lda #$08
sta $d022
lda #$09
sta $d023
jmp *
Thursday, 24 April 2014
Busy bee!
24th April 2014
It has been a bit quiet here on the production front recently due to being extremely busy. I am still awaiting new graphics for the game. Anyway, some more good news related to Honey Bee. I am back on track with programming of this C64 game.
Today I have been working on an indicator to check whether or not the bee has cleared all the pollen, before it can drop it. The indicator consists of the bee hive in the status bar. I programmed some subroutines which disables the player from using the fire button, if not enough plants were picked up. The fire button is then re-enabled if no pollen are in any of the flowers. The bee hive then flashes - to indicate the screen is clear. The player must then make its way to the hive, and drop the pollen into the entrance of the hive.
Although that is the actual goal. I came up with another idea. Since the player picks up the pollen and has to carry it all the way to the hive (once all flowers are empty). What if the player drops the pollen in the wrong place and loses it. I have a cunning plan. Actually it works. I added a routine, which will check whether or not the pollen is dropped inside the game area. If the player drops it where it should not fall. Then a FAIL message will appear on screen. The player will then have to start the whole level all over again, without losing any lives.
The idea works pretty well, still some more things to do. Although I got the lives counter working. I need to set up routines for the bonus time, and also the scoring counter. This will be done soon, but not today. Of course.
I am also awaiting the finalized versions of Ste's new background/charset graphics. I saw a preview of the ground/rocks graphics, and I really love them. They look stunning. Once the graphics are finished I will then be ready for level designs.
It has been a bit quiet here on the production front recently due to being extremely busy. I am still awaiting new graphics for the game. Anyway, some more good news related to Honey Bee. I am back on track with programming of this C64 game.
Today I have been working on an indicator to check whether or not the bee has cleared all the pollen, before it can drop it. The indicator consists of the bee hive in the status bar. I programmed some subroutines which disables the player from using the fire button, if not enough plants were picked up. The fire button is then re-enabled if no pollen are in any of the flowers. The bee hive then flashes - to indicate the screen is clear. The player must then make its way to the hive, and drop the pollen into the entrance of the hive.
Although that is the actual goal. I came up with another idea. Since the player picks up the pollen and has to carry it all the way to the hive (once all flowers are empty). What if the player drops the pollen in the wrong place and loses it. I have a cunning plan. Actually it works. I added a routine, which will check whether or not the pollen is dropped inside the game area. If the player drops it where it should not fall. Then a FAIL message will appear on screen. The player will then have to start the whole level all over again, without losing any lives.
The idea works pretty well, still some more things to do. Although I got the lives counter working. I need to set up routines for the bonus time, and also the scoring counter. This will be done soon, but not today. Of course.
I am also awaiting the finalized versions of Ste's new background/charset graphics. I saw a preview of the ground/rocks graphics, and I really love them. They look stunning. Once the graphics are finished I will then be ready for level designs.
Sunday, 9 March 2014
Into the 4th Hive
8th March 2014
After a successful backup and restore process on Thursday, and Friday when moving to Win 8.1 on my desktop PC. I was ready for yet another programming session. Last time, I managed to get 2 levels set up, now another 2 levels were to be built up.
I setup the position and enemy types for levels 3 and 4. Once they were positioned, and all pointers were setup for them. I decided to work on something completely new. When enemies moved left and right. They were facing exactly the same direction as they were moving. So a major tweak was required. Frames should change if an enemy changes direction. We don't exactly want a game in which an enemy moves forwards and backwards without flipping sprite frames. A solution to this problem was built. I programmed a few subroutines, which checked if a sprite was moving left / right if it is a worm, a bird or a hornet. If the low byte of the chosen frame was stored to the actual low pointer of the frame. The subroutine should point to the correct low / hi bytes of the frame of the enemy.
After I tested this subroutine routine, enemies moved correctly, and the frames changed correctly. No enemies look as if they are moving forwards or backwards. The all move forwards instead. I also thought about setting tables for the background colour, as I am pretty much sure that Wayne wants a different background colour according to level. Yogibear also did some sub game tunes. So I created a table that switches between two different in game tunes.
Since I now have 4 levels set for the game, I think it is time for me to tweak the background graphics slightly more. Ste86 has given me some mock screen examples of the graphics that could be used as an update to the game. His idea is to help me as a guideline - I'm not really a GFX person :) The trees look much better than mine. So after my morning walk, and my lunch, some time tomorrow afternoon will see the design process in action.
Stay tuned
Monday, 3 March 2014
Buzzing its way to Level 2
3rd March 2014
A little more work today, since I am currently on holiday (away from work) all this week, until next Tuesday, which I return. It has been hard work today working on Honey Bee, and you'll be surprised that I have gone as far as level 2. The work on this project will eventually get easier as each session progresses. :) Before I moved on with level 2, I decided to add one more enemy to the first level. So that there were three instead of two enemies. A pink little worm. Yep, this little fella is now sliding its way back and forth - although the animation which I added is still quite wrong. It looks as if the worm is doing the moon walk :) Hahahaha!
Anyway, after feeling very happy with the layout of level 1. I decided to work on fitting enemies in place for level 2. Unfortunately I had to create some more tables, as I realised I had forgotten to update starting position tables and load / store each position to default starting points, according to the level which the player was on. Good news was that it didn't take me long. After animation, behaviour and sprite start / end positions were set for Level 2. I felt there was still something missing. Background animation. So I looked up the value of the 2 characters that formed the water fall and flowing river, and animated those. The result turned out quite nicely. I was very happy with it :) The only problem I have encountered - which can be fixed later on in the project. All enemies are using one direction animation. Basically, when worms and birds are moving forwards when they should. When they change direction, the animation is still as it was before. Which makes the enemies move backwards. I do have a good trick up my sleeve anyhow later on this week.
I also came across another strange problem. When the player starts the game on level 2, it died straight away. That was not mean't to have happened. A strange bug. To ensure that didn't make a full impact on level 2. I lowered the player slightly. Problem solved. On to level 3 during my next session on this project. If I get 4 levels working. Then I'll need to design some more stages, then add more enemies to the game. :)
Good news is that unlike Up in the Air. I am enjoying working on this game project. As I had the opportunity to build the levels my own way, although Honey Bee was Wayne's general idea. I shall take a look at some more of his designed levels, to see if they will inspire me to design a similar level using my graphics, as well as his flower heads, spider webs, etc.
The duration of this game will depend on time and motivation with it. So far I have been very motivated :)
Stay tuned for more progress blogging :)
Wednesday, 26 February 2014
Let's get buzzin'
26th February 2014
NOT SEUCK THIS TIME :o)
After a few weeks back, I heard bad news about the game Honey Bee by Wayne and Prime, not getting finished. Due to a fatal computer crash. Work was destroyed, and all that remained was a playable demo with a few levels and no limit of lives. Anyway, to cut a long story short - This was almost a game which would never see the light of day after that major issue.... Until now :)
Honey Bee is under development once again, in co-op with Autumnsoft and The New Dimension. I have contacted Wayne and the other C64 people who were involved with the project and I am happy to be programming it. Of course major changes will have to be made. I discussed about this with Wayne, JSL, Wayne and Yogibear and a few others). We all agreed about making changes to the graphics, some of Wayne's sprites and graphics still can stay in the game. I made a load of major changes and created completely new graphics. The other people were happy with the result. I designed 4 stages in MSCK, and then captured the screens (for level packing in the near future).
A couple or three weeks later, I started programming the game. Erm, hold on. Before I actually started doing the graphics, I did a bit of programming, in C64Studio which had Yogibear's tune playing, and also Wayne's bee moving in a way, similar to Prime's HoneyBee. When I did the new graphics, I created a char group, and noted down the range of chars which would have no effect, collect pollen or are considered to be deadly for the bee. Also sprite animation was put in place. Then after importing the new graphics into the game's source. I displayed the very first level (unpacked).
I started programming of the main game engine last week on Thursday, during my day off work. Since the bee was moving already, and a test screen was in place. I started work on the sprite / char background collision. Unlike the previous version of Honey Bee, the killer chars were all over the place. See paragraph above regarding the new chars. The collision routine had to be read in 3 areas of the player's sprite. Top central, middle central and bottom central. I wanted to make the sprite/background collision to be much fair. I also added a routine that checks if all pollen chars have been removed from the current screen. If they have then a level complete tune plays. Otherwise nothing. I also added a routine which killed the bee if it touched any of the killer chars (background) which it cannot fly past (Rocks, trees, etc). The result looked quite good.
This week, I have been working on enemy movement for the game engine. I got a couple of enemies in place and they are moving up / down at this moment in time. I also worked on making checks on the behaviour for each enemy sprite. 4 sprites will be used for enemies that mover left / right, up / down (depending on the behaviour table) and 2 sprites are reserved for special hazards, e.g. poisonous bubbles, fireballs, etc.
There is still a lot of work to be done on this game, but all in all, it seems to be turning out quite well. Check this video out on what has been done so far.
Thursday, 16 January 2014
Darker than Light
16th January 2014
Back in 1991, when I bought issue 11 of Commodore Format magazine, I loaded in the cover tape and was hooked to a classic game called "Light Force" by Hewson. Anyway, travelling to the future, to the end of the year 2013. I remembered doing some huge enhancements for a SEUCK game by Anthony Burns called "The Huntress of Midgard". I had another idea. I set myself a challenge, in which was to write a new C64 game within one week, using the Shoot Em Up Construction Kit, and a bit of additional programming. So I could have the first ever C64 game launched in 2014. - Mission failed. Eventually I got the game finished 2 weeks LATER :)
I was thinking about which sort of game I could work on during the week's project. I decided "Light Force" was a perfect candidate for this challenge. So I used the SEUCK to design the game, graphics, Goat Tracker to write the music, but the result didn't turn out too well. The game was just too short, and the attack waves were pretty naff. I also ran out of units for the enemy sprites. Fortunately, when I showed the work to Alf Yngve, he stepped in to tweak and improve the game, which took about a week or so. The overall result last Friday was stunning. All I had to do were add the final touches to the game, including the front end and hi-score routines, a certain amount of generators detected (As the game has 2 endings, as you will see). This took about 2 or 3 days or so. The result turned out pretty well, and finally the game is finished and released:
You can check the game out for yourself at http://tnd64.unikat.sk
Saturday, 28 September 2013
The finishing touches.
28th September
Most of this morning, apart from having visitors. I have been working on the final touches of Invert. The new I drew sprites look much better. I also made the bomb throwing position more accurate. The very last touch was adding animated characters for the Get Ready and High Score name entry routine. Just the final testing to do all through this week, before I give the all clear :)
Most of this morning, apart from having visitors. I have been working on the final touches of Invert. The new I drew sprites look much better. I also made the bomb throwing position more accurate. The very last touch was adding animated characters for the Get Ready and High Score name entry routine. Just the final testing to do all through this week, before I give the all clear :)
STAY TUNED
Friday, 27 September 2013
Let's INVERT even more
25th - 27th September 2013
Yet another busy few days and MORE progress, resulting to the project estimated at 99% completion. So then what has been happening?. Last week I discovered a problem with the hi-score name entry again. The bug appeared where the player achieved a hi score as THIRD place. I entered my name, using the joystick control. Then pushed FIRE to end the name. It stored the name in FIRST PLACE position, and the HI SCORE not on screen. That was a silly bug, which was just incomplete. I forgot to add a "BNE" or "BPL" to a label in which loops the number of characters - and just moved on to another routine. Today, this has been fixed.
Apart from that what other things have been happening? Well Wednesday and yesterday I was working on building the game levels, simply by typing in BYTE values. I used the BYTE values as 2x2 map blocks, and placed them manually like you would with bricks. The levels were then stored to a temp map, which then forms the permanent map on to the screen (by reading rows and columns from the BYTE tables). Last week I did only 12 levels, some were redesigned. I worked a couple of hours or so yesterday designing and TESTING each level bit by bit, to see the possibility of completing it. Well, later levels are most definitely hard, but if you play well, it is possible to complete every level. I was happy with the final result with the level design.
After being happy with the level designs. I worked on the ending. I loaded up the Multi Screen Construction Kit, and the game charset and created some end graphics. Then used the VICE M/C monitor to capture and store the screen data. I tried the same with the colour data - but seems I forgot to save the colour data correctly. I started programming the new routines for the end sequence. I came up with an idea, which simulates the player escaping from his Puzzle prison, enters space, and ends up back in its own world. Then a surprise end. It represents something I usually do on a Thursday evening. That'll be your guess :)
After some long hours testing yesterday. I can confirm game is now 99% finished. All I need to do is a little bit of tidying up of the game sprites (Maybe redesign them, as they do look very amateurish.). Also sort out the bomb positions, to make them much fairer. The accuracy of the moving bombs isn't correct. There are a few possibilities on how to solve this problem. The final update might be next week.
Thursday, 19 September 2013
Here come the Chatters
17th-19th September 2013
I sent this game to Vinny Mainolfi to test, and come up with some more feedback. Unfortunately the main game engine needed some more things added to it. I agreed with what sort of improvements could be made to make this game more fun and playable. The general tile flipping puzzle against time idea of mine, won't really give good results for a 16KB game. The front end needed to do away with a scroll text. As I have always used that method (Logo with credits and scroll text). The changes were made to the front end. Instead of having a 1x2 scroll text, the game has a flip page. In which after a few seconds or so, the title flips from the main credits, to the high score table, then the in game characters (player, enemy, bombs).
The main game also had some major changes added to them. The game now has enemies, called Chatters. The enemies run around the playing area lobbing bombs now and then. They don't bother aiming, as they are pretty much dumb. The player now has a different challenge. Not only has it got to flip the tiles to the correct type, but also has to watch out for the Chatters' flying bombs. The player can now protect itself from the bombs, by pressing fire to activated a limited shield. At the start of the game only 5 shields are given to the player. These have to be used wisely. There are also new tiles in which will give the player a shield if the player steps on it.
As well as the enemies and their bomb throwing. I started on redesigning the level layout, to make each level of the game look more tidy. I also programmed a high score name entry routine as well (which still isn't quite finished yet - one colour bug needs fixing). Additional things I intend to do during this project are the GET READY and END SCREEN as well as finish off designing the remaining levels. I hope to draw some new game sprites for the player and the enemies, as they are quite rough looking :) Progress is looking great so far.
Saturday, 31 August 2013
Enter the Trap
29th-31st August 2013
Last time, I was working on the main game engine, hoping that everything was working. I was quite pleased with the result of the work so far. However, the colour of the tiles didn't look right on a CRT screen, so I changed the Blue+Purple tiles into Red+Purple. That looked much better. I had a great idea which was to add some kind of effect for every time the player is inverting the tiles. So I drew a sprite which creates a form of a dissolve/fade routine and added routines in the game to make this take effect. Basically, when the player hits a tile that inverts, the second sprite is used to form an animation over that particular tile. Now that I was very happy an impressed with the work done to the game so far.
I decided to move on to something else, related to the project. So I worked on a front end for the game. Unlike many of the front end title screens, where you have a static logo, credits and a scroll text. I wanted to do something completely different. I loaded in JSL's logo for the title screen. Then I converted the bitmap picture into a logo (Charset + Matrix) format. At the moment, this was just a static logo. So I decided to convert it into Swing Logo format. I downloaded Paramount's Shake It utility and converted the logo into a swinging logo format.
I decided to move on to something else, related to the project. So I worked on a front end for the game. Unlike many of the front end title screens, where you have a static logo, credits and a scroll text. I wanted to do something completely different. I loaded in JSL's logo for the title screen. Then I converted the bitmap picture into a logo (Charset + Matrix) format. At the moment, this was just a static logo. So I decided to convert it into Swing Logo format. I downloaded Paramount's Shake It utility and converted the logo into a swinging logo format.
Now I was happy with the swinging logo format. I exported the charset and swing matrix data into the project. Then I worked on the new front end. The 1x1 font was used to display the credits. I programmed in some multiple IRQ raster interrupts into the game's title screen code. Added the screen cuts. Top row of the screen has the first logo. The second row of the screen has the credits, which use the 1x1 charset, the third row has a 1x2 charset, which uses a smooth scrolling text message. Finally the bottom row has the second logo, which swings in reverse. I added some subroutines that would cycle the colour of the logo after a few seconds or so. This idea was inspired by common old-school C64 intros. The result turned out quite nice.
Now what about the game? So far I had 8 levels designed, so I decided to do some more tests on some of the newer obstacles. Unfortunately, for the blob, it stops at an incorrect position, causing the game to mess up. So to solve this problem, I added some simple checks and compared which direction the player was at. If the player was moving a longer distance, I had to trim the move distance slightly for a more accurate position. After I worked on the check subroutine for all 4 of those player directions (Up, Down, Left, Right), I worked on a few more levels, in which introduced the trap switches. If the player moves on to those either the trapdoors will remain closed, or they will all open. The T tile (correct direction) opens the trapdoors holes, and the T (upside down) represented the closing of the trapdoors. This trick worked, and some of the stages (up to level 12) are puzzling. As I positioned trap switches in various places to confuse the player.The result turned out great.
I also did some updates to the music. The in game music high notes part sounded pretty awful to the ears, so I changed the closing melody to the tune. The title screen instrument, which originally used sawtooth, was changed into a pulse ($41) and made the introduction of the tune sound much better.
The assembled program is so far 10KB and it is going pretty well, and I seem to be progressing pretty quickly with this game. It may look as in the game could be ready for submission bby the end of September this year. Considering the extra free time I have been having recently :)
Friday, 23 August 2013
Here comes the Blob
17th-23rd August 2013
I recently received an email from JSL offering me a front end logo for this game. Well, I am happy to take this, but I just hope it will be a 3 colour logo consisting of 7 or 8 chars down. There'll be no pressure either. After all, this is a hobby project - not exactly real life work :) I would like to to add one or two logo swing routines to the front end, so a 3 colour logo would ideal.For now, I shall enjoy a cup of tea. Then off to work in under an hour's time. Enjoy the game play video so far and tune in to another blog update, probably next week. Cheerio!
Last week and throughout this week, some people didn't hear from me for a while via email. Some people wondered what the heck happened to me. Well, I have been really busy on this project. As well as some classic gaming :) I also been on holiday for 2 weeks in Lydstep, Tenby as well, away from computers. There were wifi access points down there - but very limited. I wanted to get away from internet anyhow. It is too much of a distraction these days. Although the deadline isn't until 30th November to get the project finished and submitted to RGCD. I have a feeling that I will have it finished way before that particular date.
So then, what has been happening. Before I went on holiday for 2 weeks, between 27th July - 10th August. I was constructing the main game screen, using Jon Well's magnificent Multi Screen Construction Kit. This was only used to design one screen. When I checked the screen out, the size was 2 chars too small. So I expanded the grid and by adding just one more row of tiles to it. I also changed balls to blobs. The numeric counter was changed to blob symbols as well. Some different tiles were created. Those represented different obstacles, such as a normal tile, inverted tile, holes/traps, steel trapdoor, trapdoor switch, arrow pushers, and tiles that push you back to the previous tile. Then saved all of the graphics data, for just in case any adjustments or new tiles are planned. I also composed the title music for the game using Goat Tracker (See video below)
After finishing the game design grid, I captured the screen and transferred all existing screen and colour data directly to a memory location, using the T 0400 07e8 2000 (screen data), and T D800 DBE8 2400 (colour data) in VICE monitor. Then I closed down the VICE monitor and entered the Action Replay M/C monitor to save the data from $2000-$27e8 on to a .D64 image. Detatched the .D64 image and exported it to the C64 Studio project.Then I drew the sprites for the game.
The next step was to do some programming. The first thing I did was extracted all data into to the project directory, in which was called 'Invert'. I also added Exomizer to the directory as well. Compression is the key to starting a program :). I set up the main parameters inside C64 Studio to call exomizer to compress the assembled binary, and rename it to run via the decruncher, with no decrunch effect (10 SYS 2061). Then I started the main programming of the level design. I based the level design on comparing which tiles are to be in place - as the level design was to be made manually by using the !byte command, using a row of 11 and a column of 10. Each number from 0 to 9 inside the table represented the object to be placed into the game area. I created a few routines in which read from the first tile character in each row, added 2 chars to place the next tile. I did separate low/high byte pointers to start from $0452, $0453, $047a, $047b, $d852, $d853, $d87a, $d87b and created a few loops which moved to the next tile character by 2 chars. Therefore with 2x2 chars, I used $0452 for the starting point of the top left tile, $0453 as starting point of the right tile, $047a as starting point of the bottom left tile, and the $047b as the starting point of the bottom right tile. I then added a few loops / subroutines to perform the action. Then it drew the correct test map on to the screen. The $D8xx + represented the colours.
My next step was to add the main player, a bluey blob in which was to be controlled by using a joystick plugged into port 2. I added some routines in which controlled the player. Basically, if the player was moving, and the joystick direction was being read at the same time. That process gets ignored, as the player is moved using a timer. After I was happy with this. I added the sprite/background collision routines, which compared which tiles the player was currently on after stopping on that particular tile. I got the effects to occur. One of which flashed the border (just for a test) if the player was on the hole tile. I was very happy with the overall result, I moved on to something else.
Now the sprite/background collision was ready, I loaded up Sprite Pad V1.8 and drew the player's animation frames. I originally had just 1 sprite for the player at first. Each frame represented the blog expanding and deflating. I liked what was done so far. So I saved the sprite data to C64 format again and inserted into the project. The next step was to program the sprite animation, where the player expanded and deflated at a certain speed. I programmed the routine in and it turned out quite nicely.
Back to programming the main levels. This time testing whether or not all tiles were correctly inverted to how they should look. After getting the routine working. I flashed the border again to say that the level was complete. I also programmed the clock routine. What a happy chap I was with this result.
Now came the nightmare, which I had for a few days. I designed 4 test levels, but after a level was finished. The tile data from the next level was out of place. I was pretty confused about how that happened. It puzzled me until yesterday. It turned out that I had forgotten to add the low and high byte values of the starting characters, which should initialise the first character and colour RAM position for each corner of the very first row of tiles. After that was solved. I programmed some messages to show LEVEL COMPLETE, LIFE LOST and GAME OVER. Then I was in the mood for doing some music.
I loaded up Goat Tracker V2.27 and worked on the in game music. Unlike the first tune which was used for the game, I wanted to do something pretty funky and quite cheerful. So I did a sort of funky cheery jazz type of tune as in game music inspired by demo scene musicians such as PRI, JCH, Drax, Syndrom, etc. Then added a game over jingle, inspired by the game over jingle from the "Artris" demo, by Scruffy Bits/Color7, which appeared in Commodore Format's cover tape #53. The result turned out pretty good. I generated a .SID file, and tested the .SID. Great, it worked. Now I transferred the music to the game project source, as .prg. I added some more routines in the game which plays the music. Awesome. It suits the game well.
Now it was back to Sprite Pad V1.8 again, so I can add some explosions to the animation. This occur when the player loses a life, but first the blob sinks through the ground (or hole) magically. This can happen when time runs out or the player falls through a hole. I exported the new sprites to the project directory, then programmed the life lost routine, where the player gets killed. It looked quite good, but I wanted to add one more thing to the life lost routine. Shaking screen during the explosion. The pointers inside the explosion loop also read the animation table for the screen shake. Then restores the screen back afterwards. Wonderful. I love the overall result so far. So then what next? A real C64 test.
I copied the compiled .PRG to my 1541U2 and tested the game in action. Unfortunately, it looks as if I may need to adjust the correct tiles slightly as on the PAL monitor (TV) it doesn't look all that good. Still that won't really be much of a problem. Just a slight character change, and it will probably look much better. Everything else seems to be ok. More on this next week, as I am intending to get the FINAL touches done with Trance Sector Ultimate for RGCD tomorrow (Saturday) morning. Just a final bug fix for that.
I recently received an email from JSL offering me a front end logo for this game. Well, I am happy to take this, but I just hope it will be a 3 colour logo consisting of 7 or 8 chars down. There'll be no pressure either. After all, this is a hobby project - not exactly real life work :) I would like to to add one or two logo swing routines to the front end, so a 3 colour logo would ideal.For now, I shall enjoy a cup of tea. Then off to work in under an hour's time. Enjoy the game play video so far and tune in to another blog update, probably next week. Cheerio!
Subscribe to:
Posts (Atom)
Fredrik the Ball is Back: Spider Maze 2 in progress
11th January 2026 First of all, a belated Happy New Year to all C64 and retro kind. At last, a new blog update and a new C64 project is ...
-
Saturday 11th October 2014 (Work still in Progress) Poor old Wayne . He designs a new game, creates loads of graphics for it and then awa...
-
11th January 2026 First of all, a belated Happy New Year to all C64 and retro kind. At last, a new blog update and a new C64 project is ...
-
10th March 2015 My week's HOLIDAY started Sunday this week. It's going to end soon, but I have not only been out and about places ...














