Sunday, 25 November 2012

Back on track again ...

25th November 2012 (Some good news about Amazon Tales)

Yesterday I was stuck on the enemy shooting and felt that there was no way I would be able to get out of the mess. I also thought that I could end up withdrawing my entry for the 2012 16KB Cartridge Competition. Later on before I went out. I came across an idea ... Why have a huge list of tables where you can easily get yourself lost - and simplify programming the shooting routine - To check whether or not the enemy object is a Pygmy, Monkey or anything else that was supposed to shoot.

Well, I put my theory to the test, and tried programming a small routine for each enemy (Can easily be expanded) to check whether the enemy sprites are the objects hoping to be placed in the game, and I also set the firing direction of the chosen enemies. Guess what happened then? It worked :). I was over the moon that the tasks I made were successful today. Now that part of the shooting phase was out of the way, I worked on a few more in game routines. The first one of which will display Get Ready and Game Over sprites for the levels. When I played the game with the enemies shooting - it was hard to play. So it was time for me to simplify things a little.

I programmed a little routine in which allowed the player to have protection for a short period of time. This occurs at the start of a level - or after a life has been lost. It was also to minimize the chance of a multiple loss of lives after one enemy or bullet kills the player and the player gets re-spawned in exactly the same position it died.

Now that was a good result :) Here's a video (with a crappy temporary title screen) of the game in action with the new features.


Since things are now looking quite positive. A submission of Amazon Tales is highly likely for RGCD's 16KB cartridge game compo, this Thursday.

Saturday, 24 November 2012

A week of disaster

20th - 24th November 2012

Over the week or so. The enemy movement patterns were being worked on. I thought that things were looking pretty good for this part of the project. Unfortunately I ended up getting myself completely lost with the enemy tables, and their behavior. I programmed a routine to allow certain enemies to shoot, according to their behavior table. The shooting turned into a big disaster. Wrong enemies were shooting, and on level 3 the enemy tables didn't work right. Perhaps I missed entering one or two of the values of the element for one of the enemies. Because of this fault the entire enemy table turned into a complete disaster.

I was hoping to get a 16KB cartridge version of the game finished this week in time for RGCD's 16KB cartridge competition. Unfortunately the overall result turned sour. Therefore, due to lack of time - because of work. I have made a decision that I shall withdraw my entry from the competition I am aware that it is very easy to fix, but it unfortunately takes a long time to process. The enemy tables will have to be restarted from scratch. That will probably take another 2 weeks. I am still determined to get this game finished, but sadly not in time for the RGCD cartridge compo.

Update 25/11/2012
After the success of fixing the problem with the enemy shooting, and nearly past the half way mark with this project. There is a positive side that there could actually be an RGCD 2012 entry of this game. I think it is possible that some of the elements will have to be ignored for the game, until after the competition entry has been submitted. Additional elements such as a high score table, a decent ending, etc. will have to wait longer. 

Monday, 19 November 2012

You Cheeky Monkey

15th-19th November 2012

Despite having less free time last week, I've gained more free time this week in the mornings, before my 12-8 shifts (Friday 10-6). I still have Thursday and Saturday free. Last week through to today I have been working really hard on setting the enemy movement pattern for the game.Mainly by creating byte tables to represent the enemy object type, start position (X and Y), movement speed, direction and their proposed behavior patterns. 

So far I have gone as far as the beginning of level 2 - but other levels seem to be somewhat shorter to play - but those will be a lot harder. Especially when I add the mean deadly spiders into that stage. So hopefully as soon as all enemies are in place, I can start getting them to shoot and have more of a proper game by next week.

Today, I added a new enemy to the second level. Take a guess what that one is? ... That's right it's a cheeky monkey. My target is to get all enemies in place by Friday, (I have all day Thursday and Saturday this week). I can work on the shooting tactics for the enemies, and also add some additional game play and a quick front end. Sadly it looks as if the game will not be 100% finished for the RGCD game compo, but who knows what could happen next week?

Sunday, 11 November 2012


10th - 11th November 2012

With the deadline coming closer, and closer. A lot of work is required to be done for Amazon Tales. I'm not too sure whether or not I will meet the deadline for the 16KB cart compo, due to extended hours at work - through to Christmas (Reducing my free time even more). I will try my best to get Amazon Tales ready in time for 30th November, but cannot really promise anything spectacular.

Yesterday I have been working on some additional routines and also behaviour tables for each of the enemies. Each byte in the behaviour table has a different type of behaviour for the enemies. They vary from moving up and down at the bottom part of the screen, or the top part of the screen. Or shoot a bullet at a certain direction. I didn't get round to getting the enemies to shoot yet, as I wanted to concentrate more on the attack movement speed, and position. I got myself lost with this attack wave thing yesterday, so I had to rewrite the position and speed tables to how they were beforehand.

Today I have been working on getting level 1's enemies positioned. At the start of the game we originally had four enemies moving across the screen (Two going a different direction). To make things easier for the first level, I updated the tables, where at the start, you have 2 enemies to attack, then the number gradually increases it. I also got the great big tigers to move up and down via the behaviour patterns. This worked quite nicely :)

On Wednesday/Thursday, I shall be working on adding enemies to level 2 (The dark forest), which will include the monkeys at a certain height. Introduce another new enemy, then as the week progresses, work on the remaining four levels. 

Tuesday, 6 November 2012

The Player Dies at the End

6th November 2012

Don't mistake yourself with Alf Yngve's latest Sideways SEUCK masterpiece, which I released on the TND web site on Wednesday last week. Nope. This is basically a blog update about what I have been doing this morning. Well, yesterday, I got the enemies to die when the player throws an object at them. Now today I did the opposite.

The Player Dies at the End by Alf Yngve
A few days ago, I got the collision registers programmed in (The usual box collision register). Yesterday was the bullet/enemy sprite. Today was the enemy/player sprite. I first added subroutines to check whether or not each enemy hits the player and test flash the player - if a collision was spotted. The routine sort of worked, but I thought about making a loop for all deadly objects to collide in any area to the player's sprite's X-Y axis. :) That was much shorter, compared to repetitive comparing values for each sprite. It worked quite nicely as well.

Now that I got the player's sprite to change colour when an enemy collides into it. I worked on building a routine that will check for the player, to see if it was already dead. Followed by adding a routine to do the actual death animation. All worked fine, and the player can die.

The player lies dead, after being bitten by a jungle snake
There were just two more things to be added to the shooting and death routines. Which were to add points to an enemy killed, and also a lives subtraction counter. I got those to work fine. Next came playing the GAME OVER jingle after a life has been lost. I was going to get the player to have a short term protection (flash) but I with the short amount of time I had, I didn't get round to it. So Thursday is a possibility. I might be taking a little break from programming tomorrow. We'll have to wait and see.

The game's engine seems to quite positive, but I can be sure that things WILL eventually turn much better when this Thursday or Saturday, I will be adding some more extra routines to enable some of the enemies to shoot - according to what object they are. Followed by additional behaviour of enemies. Some will walk across the screen in a straight line. Some will move up and down while slowly moving across. Some will shoot, and some will have interesting and quite impressive features.) More about it when I get round to doing exactly that.

Monday, 5 November 2012

Give it some POW

5th November 2012

As I said yesterday, from now through to the deadline. I am going to committing my free time available in the mornings (before work) to get this project finished. Mainly because the deadline for the 16KB cartridge compo is getting closer and closer.

Yesterday, I got the player to shoot at the enemies, and kill the enemies. Now today, I did some more to the shooting routine. The player shoots bullets but the enemies had no death animation whatsoever. Alf also didn't supply me with a proper death animation for the enemies. So I drew a POW style explosion sprite, consisting of 2 frames. Then I created a subroutine which will animate the explosion sprite on the player bullet, if an enemy is killed.

Well, that routine was quite effective. However, I noticed a small bug in which turned the player's bullet pink an displayed that for a short time while flashing the explosion. To resolve this problem, I altered the sprite settings so that the bullet sprite is NOT available until after the explosion has finished and the bullet sprite has been homed.

Wammo - Take that you dangerous creature!

The last thing I did today (since time was pressing on) was correct the settings for the sprites. (Big tigers) so that they are linked together correctly, and also the player can only shoot if the fire button is pressed, and not held.

My next task will be to get the scoring to work, enable the enemy/player collision and then get the player to die and lose lives.But that can wait until tomorrow morning. As I have to get ready and go and work 12pm-8pm soon.

Hopefully on Thursday, during my day off work  I can get the enemies ready for all of the levels. Then work on enemy shooting (As I want monkeys throwing stuff at the player, the pygmy's firing darts and spear throwing guards as well.

I think although the free time I have is too short (due to 12-8 shifts in a busy warehouse) I am feeling quite positive that I can reach the deadline for this a 16KB version of this game project.

Sunday, 4 November 2012

Let me at 'em!

4th November 2012

It's been a small session on Amazon Tales today, but the game engine's getting around quite well although pretty slowly. I feel I should commit a lot of free time on this during the upcoming 3 weeks or so, due to the deadline for the RGCD 16KB cartridge game competition, which is looming closer, and closer. Since last week's major problems. 

So then what was done today? You may ask. Well, for a start off, now that I am aware of the correct table settings I decided to do two things today. Well, actually 3 things. First of all, I wanted to make the game feel pretty fair - regarding the enemies, when they are on screen. I wanted to check to see whether or not a sprite had left the screen. If it did then it is classed as an offset. I created a few pointers to check whether any enemies are not offset. If not all enemies are offset, then they can move. However, if all enemies are offset, the next group of enemies come on screen. Basically, I check to see if the X position (even when enemies are inside the border) equal the end area - they are classed as being offset. I also had to update the enemy movement routine by stripping out the small loop, and expanding the code. Mainly for setting the offset values per enemy's X-position.

Purple rainforest - Getting darker as your progress

Finally, we wanted to get more of a game feeling to this project, so I worked on the sprite/sprite collision settings. For now, I used the usual box collision routine (as I don't know the pixel perfect collision very well). I typed in the collision routine for each enemy (as this will be expanded later on for scoring points). Where if a bullet hits an enemy object, that enemy will be off the screen. Also for now, I repositioned the bullet as well. So nothing special is happening at the moment. Hopefully when the death animation is set some time later on this week. We'll have more of a game. :)

Thursday, 1 November 2012

Table of Errors!

1st November 2012

What a day! A stupid one in fact for Amazon Tales. Last week I spent hours setting up the low byte and high byte pointers of the data tables. Unfortunately when I was doing more programming to get the routines to work. It was just a plain waste of time. After completing the routines to set the low and high byte of the level table to read. The enemy sprites were all over the place, and enemies had their mind of their own. I tried different methods, and was totally fed up and decided to have my lunch. Looks like I'm really going to be stuck on this problem. 

After fuelling myself with some ham sarnies and a cup of tea, I was still concerned about the problem in the program. I went back upstairs to find out if I could solve this issue. I looked at the code, and thought carefully to myself. THIS IS BOGUS - THIS CODE DOESN'T WORK AND THERE IS NO NEED FOR THAT ROUTINE. DOH!. There has to be a more simpler way to get the sprites working according to level. Well, a solution came up. I should have done that in the first place. How embarrassing ;o). I solved the problem, simply by removing the low byte/hi byte tables for each level, and just reproduced the same level table for level 1 - it also saved a bit of memory as well. I also set the enemy pointer values to read 126 bytes from each table. It is now up to me to put new sprite pointers/objects into different tables. (21 bytes x 6 levels per table).

When I progress further adding more varied enemies to the game this Saturday, I might be able to snip the table down even more. Hopefully next week I should be ready to add sprite/sprite collision, and also a small routine that will not cycle through the the next batch of enemies. Until all enemy sprites are offset. :)

Thursday, 18 October 2012

Enter the tiger

18th October 2012

Today's session on Amazon Tales took a while to work on - especially for the first level. But things are starting to shape up quite nicely. I worked on creating more enemy tables for varying the different types of enemies on screen. Although the result still doesn't look correct and the movements are too plain, I have a few tricks up my sleeve this coming Saturday. I also added a new enemy (which consists of sprites), which are the big tigers. :)

It took me a few hours to think about and work on the new extended tables for the sprite animations, start position, movement, etc but so far a not bad result. Check out our latest video showing the progress of the game so far :)


Thursday, 11 October 2012

Amazon Tales - Level proceedure

11th October 2012

Last week on Amazon Tales, I got the enemies moving via tables. Although the tables are incomplete, I shall be returning to those on Saturday. Today I programmed some routines in which can detect where the end of each level lies in the map. Alf Yngve's maps had a column of blank blocks. This, I'm assuming represents the end of each level. So I wanted to make it so that when the timer spots the black blocks - it will blank the screen (Later during the project, I'll be adding Get Ready and Well Done sprites to the screen) ... I programmed a loop in which can check for the game scrolling time before switching to the next level.

The Sacred Temple

Secondly, to enhance things a little, I worked on writing some music for Amazon Tales. I loaded up Goat Tracker, composed some new instruments and then worked on composing the tune for the title screen, get ready/well done and game over jingles. Followed by the in game music. I imported the tune into the source code of the game, and got the Get Ready/Well Done jingle to play after every screen blanking interval. Then when the game was ready to start, the music changes to the in game music. Seems to have worked a treat.

More work on this on Saturday.

Thursday, 4 October 2012

Here come the critters

October 4th 2012

Still working on Amazon Tales, and so far although it is the early stages. It feels quite promising. Today I worked on ways to animated the enemies and also change their animation per every object offset. I created a small table to test for EIGHT alterations of the enemy object per reset. Result turned out pretty good. After an enemy left the screen, it appeared as a different object. More work to be done this Saturday. Here's a video of the result so far :)


Monday, 1 October 2012

Enter the natives

30th September 2012

More productivity at work today, but before I go on my 12-8 shift, I decided to spend this morning (Since 8:45pm) working a bit more on the Amazon Tales project. The deadline is looming closer, but I still manage to spare some of my free time on C64 activities. So what's been happening today? First of all last week, I got the player on screen, move around and shoot. Now it's time to insert some enemies, in which the player will have to shoot at.

First of all, I wanted to test the game sprites to ensure that they all appear on the screen okay, without any movement. I built a test in which shows four natives a dart (which the natives will shoot, and also an aztec coin). Nothing on the enemy front is supposed to move anywhere on screen. Well, it worked out pretty well. Pretty much happy with this so far.

My next job was to get those enemies moving across the screen (or downwards). The plan for the coins will be for those to drop down on to the ground, prompting the player to pick them up. The coins purpose will be to give the player a better ability to shoot at the baddies or move faster - but that will be revealed later on in the blog. If a life gets lost, he loses all abilities. The bullet sprite will be indestructible. More on that later in the blog, when I get round to working on collision.

I got the enemy and bullet sprites moving in a straight line at the same speed - but that wasn't the end of it. I need to add speed table pointers. This is so that the enemies can move at various different speed values. So I added value X + Y tables, according to the speed and direction of the enemy's movement. I also put that into a loop as well. It worked out quite nicely.

Not much time for any more work on this, so I'll be doing more on this game project later on this week.

Saturday, 29 September 2012

Into the Amazon

29th September 2012

Finally the scroll engine has been updated a couple of weeks ago, with thanks to Achim's technical support. Now I have been working on the game's animation engine. Last week I got round to preparing the animation tables, but didn't get round to implementing them into a routine. So today I did exactly that. I animated the player so that it looks as if it is running.

I also added a routine in which the player shoots bullets. For some odd reason, the bullet sprite looked out of place. The player was shooting the bullet out of its head :) With a quick adjustment with Sprite Pad, I got the player to shoot the bullet at the correct height.


More work will be done on it later on this week or possibly some time next week - where I start adding the enemies in to the game.

Saturday, 15 September 2012

On today's menu - Trance Sector

15th September 2012

After sending BETA V3 to the BETA testers, no problems seemed to have occurred. So now BETA testing has passed. It's time for me to add the final touches to the disk version, while Daniel Kahlin's working on the finishing touches for the tape version.

During this week I have been working on a TS music demo, which goes with the Trance Sector game, and today I have been working on the disk menu system, and final linking to the intro. The menu is really colourful and quite attractive. The worst part to programming the menu was the raster timing. When I created the colour bars they were all over the place. After playing around with the raster bar timing tables the overall result showed perfect looking raster colour bars. I was pleased with the final result.

Once the disk menu was finished, I implemented Martin Piper's IRQ loader system (and the TS loading picture) to the menu, and set disk drive initialise at the correct point so there wasn't a pause during the IRQ loader part - and so that the music will continue playing as well. I used the tape loader tune for the disk menu system / disk loader, as I thought it would be really cool for it.

I put all the files together on to the disk, altered the load addresses of each PRG file (So that the loader can load the game to a specific address). Now the disk version of Trance Sector is finally ready for release to Psytronik Software.

All I have to do now is get the raw versions of Trance Sector and Challenger's Edition for Daniel Kahlin, and finally I shall release both DISK and TAPE versions to Psytronik Software.

Monday, 10 September 2012

A bit of polish and a few balls as well.

9th-10th September 2012

The BETA Testing of Trance Sector took place over the weekend. The game felt really good, but sadly the game required polishing. The good news is that not much work is required for the game. In fact, only a tiny bit of work was required - I actually got started on the polishing of the game this morning, two hours before I set off to work 12pm-8pm. So what were the problems that were pointed out:

First of all, one job was done yesterday. My beta testers spotted a minor bug with the high score name entry routine. The first problem was that after pressing fire on the game over screen a letter 'A' was already stored on the name for the first character. This was because of the Game Over routine forgetting to 'refresh' the fire button routine. Using fire button detection without refreshing the values to zero can make the control very sensitive. Secondly was the name entry itself. I forgot to reset the last character with the first character and vice-versa, depending on which character was detected. I quickly fixed both of those routines and tested it to ensure it worked right.

More improvements were being made today. Both BETA testers pointed out that the game can be off putting to the audience. If on each level the player lost a life, they would have to start the game all over again. I was quite reluctant to not have the player start all over again. Considering last week when I was testing the levels in cheat mode - I was really frustrated trying to complete some of the levels, although found it to be possible at the end. Since both Frank and Vinny pointed out the same issue, I updated the code to make sure the game screen didn't reset after a life was lost. It didn't require much code one bit. A simple reposition and re-spawn of all sprites per life lost. I also had to update levels 7,9 and 24 - repacked them all and - success.

I wanted to improve something else in the code, which I just had time to do. So I dug out the game character set in Cuniform and I drew 5 1x2 ball characters, with EXTRA inside each ball. Then I stripped the charset size and imported it into the game source. Then I altered the EXTRA routine so that the balls were dark blue (rather than green), but they are still white after one of the letters get picked up from the bonus ball object.

Now it was time to go to work - and maybe work on polishing the explosion sprite positions for the ending screen. Then hopefully final BETA testing this coming weekend.

Thursday, 6 September 2012

Enter the Sector

1st-6th September 2012

Over this week I have been working on preparing and building the 32 levels for Trance Sector - fixing some additional bugs, building improvements for the game and programming the intro presentation for it. Now finally, the hard work is nearly done, it is on with the BETA test phase, which I hope will get great feedback.

I tested the new levels myself, and I'm not that good a gamer to be honest. I struggled on some of the levels in Trance Sector in cheat mode, but found that every single level in the game is most definitely possible to complete. I feel that this could be a real addictive game as well. If there's no major issues in the game for the beta testers, I can send the final masterpiece to Daniel Kahlin for tape mastering (As he's been doing a mega cool high speed tape loader system exclusively for Trance Sector. I shall be keeping my fingers crossed. :)

My next C64 project WILL be Amazon Tales, a co-op production by Alf Yngve for RGCD's 16KB cartridge game competition - and it won't be a SEUCK game this time round ;)

Saturday, 25 August 2012

Out with a bang

24th + 25th August 2012

Yesterday and today I have been working more on the Trance Sector C64 game project. This time the end screen (As level designs will be the next phase :)). I spent most of today and yesterday programming the ending. I started off programming a routine in which displayed the screen background. A timer was added before the next scene had taken place.

After a slight pause, the explosions around the factory take place. A little man appears on screen. I added another pause before the next scenario, in which he runs to the space ship. Then yet another pause followed by the movement of the ship. Another pause, and something really cool happens - which you have to wait and see when you play the game.

I added an upward scrolling routine and added a subroutine that would do line spacing for the end text - so that it was much easier to read. I decided NOT to have just a plain black screen with nothing else happening and just a scroll text. So I decided to add some action behind the scroll text. I won't tell you what it is, you will have to wait and see when the game gets release.

I am very happy with the final result of the game's ending. It looks quite good, and hopefully it should get some good marks from C64 endings as well ;). I worked really hard on this ending, the way I wanted it to be in the first place.

Now all there is to do is work on all of the levels, make a few tweaks, beta testing and final phase fixing. Then hopefully this game should be ready in time for 29th September 2012. Stay tuned.

Monday, 20 August 2012

Into space we go

Monday 20th August 2012.

Missed us? Oh, I bet you did. I was on holiday for 2 weeks. Anyway this weekend I got started on working on the end screen for Trance Sector. Nothing has yet been programmed, but I am aiming to start on the main programming of the game ending hopefully tomorrow. So then what has been happening this time round? Well simply graphics, graphics, graphics. I came up with an idea in which was to get an apocalyptic ending for the game.

On Saturday I loaded up the Multi Screen Construction Kit on my 1541 Ultimate 2 device (Yep, I received that Monday last week and it has been a MAJOR distraction to me. Hahaha. Great piece of kit.) I loaded up the MSCK to draw the end screen (Oh I already said that), but I had to use the existing charset and I still had chars free for this exciting finale for the game. I drew a few stars then I drew a green ground using a single char (Nothing else was required). Then a factory was drawn. It took me a while to work on the factory itself. I added a little detail to the top of the factory, simply by giving it some pylons, and wires.I put the whole screen together and it looked great.

What about today? Well, I have been drawing a few more sprites, in which I felt would suit the end screen. I drew a few sprites which consist of a little man. The general idea for the little man is to simply appear from one of the doors of the factory. Then jump into a space craft and get the heck out of there, while the factory's exploding. I drew a few frames of the player's space ship which was difficult for me to draw. I took a look at a screen shot of Armalyte to give me inspiration. The space ship looks quite similar, but isn't the same as the commercial game. I didn't even rip the sprite out - that'd be bad. I added some flame animations to the sprite.

A second scenario has been planned, which has the player's ship going into deep space and escaped the planet. Then throws a mega bomb onto the hostile planet to destroy it. Since I didn't have enough chars in MSCK to draw the planet. I used 4 sprites for drawing the planet for the finale. Also a few frames for the game sprites. Starting to look quite good - I haven't even programmed the end sequence in yet - but I will start on this tomorrow. :)

Saturday, 14 July 2012

Reach the top score

13th + 14th July 2012

Now that the main game engine, has been finished. I have been busy working on enhancing the front end last week. This week I have been working on the high score name entry routine. First the player's score had to be checked after game was over. Then I had to compare values to the final score. If the score was higher than any of the top 10 scores. The player could enter their name for the high score table. If however no high score has been detected the routine jumped straight to the front end. The easiest part was programming and testing the name entry routine. Obviously most games tend to use a simple joystick option in which up/down increments / decrements a character. Pressing fire takes the player to the next column, unless a certain character has been detected. I did exactly that for this game as well if an arrow pointing left was detected, it would rub a character from the name entry. If an up arrow was detected, I used it to represent 'finished' name entry.

The hardest part was to get 10 high scores checked, and moving the names to the CORRECT ranks. I used probably one of the most easiest, but longest approaches of them all, which was repeating each routine checking the player's score per high score. Then jump to a subroutine to allow the player to enter his/her name for the high score table. I found a green high score name entry to be pretty boring, so I jazzed things up and flashed the character sets of the well done message (and the character being used to enter the player's name). Then moved the names and scores down a row so that the player's name and score is in the correct position.

The front end required a lot of tweaking, so I fixed the sprites that were covering the last row of characters of upward scroll, so that the upwards scroll masked correctly. I also worked on a new help screen. Captured the screen in MSCK then I imported it directly into the project source code, and did a little more programming. So that the front end will flip to the next page and then after a short period of time, it switches back to the main page again.

The front end's virtually finished now. I think an end sequence will be the next on my list - then redesign all of the game levels.

Sunday, 8 July 2012

Onward and upwards.

8th July 2012
It took me a few hours just for me to try and figure out how I could get the upward scrolling correct for the front end. I came up with a few experiments, which sadly didn't work. Then I tried changing the AND value to #$06. The upscroll moved upwards smoothly. I created a fake multiplexor for the sprite scroll and also to mask the top part of the upward scrolling message - which thankfully did the trick nicely. A couple of things I need to add to the front end, are routines to change interrupts and display the help screen for a short period of time. Then back to the up scroll interrupts again. There's also the high score name entry to work on (carefully) as well.


Saturday, 7 July 2012

Push it up

7th July 2012
Now the main game engine seems to be out of the way (I hope). It was time for me to do some more work on the front end. Well for a start off, I could do with recreating the raster interrupts by making some more. Now I updated the rough delayed up scroll to move upwards in a smooth scroll. For some strange reason, the up scroll seems to jitter a lot. I tried many times today to try and get that blighter working, but it seems as if the upwards scroll still won't work properly. Troubleshooting time :)

Friday, 6 July 2012

It's time to grab that ball.

6th July 2012
I have been doing more work on the bonus ball today. Nothing too big. It has been suggested that I should allow the player to collect the bonus ball while it is bouncing around the screen. So I changed the routine to allow the player to collect it. I also noticed that the smart bomb feature (last item in the ball cycle) wasn't available. So I altered the code so that it can cycle to the last object before de-spawning again.

There were some issues with the E-X-T-R-A highlighting routine. It seems I had missed out some important operators to allow the player to highlight ONE of the above. Where before when the player collected the 'T' on its own. The bug displayed T-R-A in white, when it shouldn't have. I fixed this issue by updating the code slightly. I also made the E-X-T-R-A (after highlighting) reward the player an extra life.

While playing the game in cheat mode, I also discovered a silly tile bug, where a tile appeared in the incorrect place after the player moves on to it. This was only taking effect on the Panic Switches. I should have made the switch tiles turn to standard tiles - before any other operations/subroutines were called, otherwise some strange effect happened. After moving the subroutines, the panic switch worked 100%. I was pleased with the result so far.

I think literally the main game code's finished, my next task (possibly tomorrow) will be to do a high score/name entry routine. Then update the title screen slightly, followed by ending, followed by redesigning all 64 levels using Delight by Color7.

Here's a test video I made to ensure everything was working how I hoped it would, after the modifications to parts of the game code :)


Saturday, 30 June 2012

Lucky strike

30th June 2012

Slightly late than never :). Today more work has been done to the Trance Sector bouncing bonus ball. A few days ago, I got the ball to bounce around the screen. Today I did some more work on it. I created some subroutines which sets the counter of the ball to appear. Then it spawns in. After a full cycle of some of the features, I made it spawn out again. 

As well as this feature, I added a subroutine to test the collision of a rocket and the bouncing ball. If the rocket hit the ball (depending on what the ball has) the player gets rewarded either 100 points, 200 points, 500 points, Lighting of letters E,X,T,R,A (To indicate and extra life) or a smart bomb, which will destroy all rockets on screen. I also made it that if a rocket hits the ball, the ball disappears and the rockets explode. Here's a video of the work done so far. I still have the E,X,T,R,A  routine to bug fix - and award extra lives properly. That can wait some other time later on this week ;)


Thursday, 28 June 2012

... And the bonus ball is ...

27th June 2012
I only had 2 hours spare, which gave me some time to work a little more on Trance Sector, since finishing Escape from Zaphod  using the 3D construction kit last week (Hard work).. I took a look at the sprite data to work out what the ball's value should be, and created a frame table in which would indicate the colour for the particular bonus object. I created a few values to check the direction of which direction the ball should be bouncing. A few subroutines were also programmed in to get that ball moving according to direction. Yep, it bounced around the screen how I hoped, but was a bit too fast. So I slowed it down by adding a speed delay to it. I also created a sub routine that could cycle the colour of the bonus ball. The same was done for the frame type. Since I didn't want the ball colour and frame cycle to go too fast, I just had to sort something out to stop this. So I created a delay. Now the objects and colours are cycling to how I hoped they would. 

... and here's the result so far. :)


As you can see, I have a ball bouncing around the screen, but what use is it where there's no way of being able to touch the object to destroy it? Well, because of being short of time I had because of work. This will be resolved hopefully some time this Friday, if I don't get called or text into work that is :) The plan in general will be to get the bouncing ball to disappear if one of the seekers/missiles hits the ball. Whatever frame the ball last had will result 100 points, 200 points, 500 points, an automatic bomb to destroy all seekers or a lit up E-X-T-R-A (In which, when fully lit will award the player an extra life). I better work on the collision and checks for what's resulted from the ball.

Monday, 11 June 2012

Let's make some noise

11th June 2012

I don't tend to get much free time on a weekday, but I got up early to make up the free time, because of working a 12pm-8pm work shift at a 24 hour Distribution Centre. Anyway, glad to have found time to get sound effects in action. On Saturday, I was thinking about using the Sub Hunter unused in game sound effects for this game. The sound effects were originally created by me using the Maniacs of Noise SFX Editor by Roland Hermans. On Saturday I had problems getting the sounds to work correctly, and yesterday I almost reprogrammed sound effects - but was fed up and gave up at the end.

Anyway this morning I got back to the source code, to work out why (on Saturday) the SFX was playing with buzzing noises in the background. It turned out to be the case that in game music was also trying to play as well. So to fix this problem, I created a little switch routine, to switch between music and sound effects. If the music option = 0 then the music could play, otherwise if it was = 1 then play only sfx until after a level's complete. This trick worked quite well. After testing the SFX, they worked out pretty well. Love the explosion sounds of the seekers, and also the player collect sound works quite well. So far so good.

Just one more thing to do quickly before I had to set off and catch the bus to work. This was a small thing to do. I drew two extra sprites - one for the music (a music note icon was drawn for that one) and also a sprite for sfx (a speaker with waves coming out). I imported the sprites into the source code and also added a pointer which can detect whether music or sfx is selected, according to whether the player pushes left or right on the joystick in port 2. 

Here's a video of the game with Sound Effects for you ;)


Sunday, 3 June 2012

A disappearing act

3rd June 2012

I thought I'd be losing some free time today, but I have one way or another. Today I felt like doing more work on Trance Sector, as last week I sort of missed out on it, for some reason. So then, what has happened today then? Well, let's continue yakking away ;)

First of all, I loaded up the SpritePad editor, because my next task is to do a spawn and disappearance of all game sprites. So I drew another 4 frames for the sprites. Then I worked on some sound effects to make a similar sound to Bulldog (Where the player appears and disappears). It worked out quite well, and I was pretty much pleased with it. I also made a sound for another idea I had (level complete explosion effect). Then I imported both updated sounds and sprites into the source code. I had to relocate the game sprites to $3000 and change the value of the animation / sprite type values. This was because of the sound effects/music taking over the memory at $2000. I also had to alter the variables that were pointed to $3xxx and make them point to $2xxx instead.

Now I programmed a few additional routines. The first of which was to spawn all of the sprites on to the game screen. I made them appear by using an expanding '+' type of sprite. I set the frames and pointers for the animation, and added the 'ding' style sound to make the player appear. Well, it turned out quite well. Then in the Level Complete routine, I got all of the sprites to disappear by using the same '+' sprite, but disappearing in reverse.

Next I wanted to add some effect to the level screen. So I decided to make the level's background multicolour colours, use the panic colours in high speed mode. I added a sound effect to this as well. Then I added a simple exploding screen and used the player's death sound for the quick explosion. Then the main Level Complete message + jingle comes on. Feels quite great. Check out the video:


Sunday, 20 May 2012

Engage Shield, Panic Stations

19th May 2012

Well, this is where the fun begins :). I worked on a 1 screen test level (To get the tiles working) and imported the test level library from the Multi Screen Construction Kit. Then I started working on some more programming aspects to the game engine.

There were two new tiles for the game. One which was a temporary shield, and the other which was the switch. I loaded up VICE and the game's graphics work files to work out which character indicated the shield, the switch (on) and also the switch (off). Then I added more to the sprite/background collision register routine. Some of the routines check for the value of the character. If it was the shield tile then to test this was working I added INC $D020 to increment the border colour (test). Then I did exactly the same thing for the panic switch, but DEC $D020 to decrement the border colour (test 2) instead. I also got the tiles to change. The shield tile turns into a standard tile (Shield disappears). The switch on tile turns into the switch off tile. I assembled and executed the new code and tested the test level. The increment/decrement of the border worked. Now it was time to add some more routines to make the code work how it should have.

Some more variables and timers were added for the shield routine. The idea was to create a timer that will give the player a temporary invincibility mode. I also created a table which should flash the player (silver/grey flash scheme). A routine to time the shield counter was also added. I also created a routine to check whether the timer equals 0, indicating that the shield has been disabled. Otherwise the sprite/sprite collision would be bypassed. After I assembled and tested the routine. I had the player flashing for some time (after collecting the shield) which was perfect. Especially for the harder stages of the game, where there will be tiles with panic buttons surrounding the pods.

Now the invincibility mode was sorted out. It was time to add some interesting features into the panic switch routine. I decided to make it look as if the alarms were going off - and the seekers speed up during a short period of time as well. This was to make game play more frustrating and fun. Like with the shield routine, I created a timer and also two colour tables for the background multicolour. Yes that's right, the background multi colours flash on panic mode. The effect turned out nicely, and also the background restores to its normal colours after the panic alarm's switched off (automatically).  :)

20th May 2012 More level designs ... and the master of disaster strikes ...

I have been doing some more levels using Multi Screen Construction Kit today, and have 25 working levels done so far, but the bad news is that after level 26 was stored to the MSCK library and I wanted to view all of the levels through MSCK, the program crashed (CPU JAM at $C107). It was very complicated to look at the code. So I'm not sure whether or not it will be possible for me to recover the level. If it is not recoverable, I will have to redesign the same levels using a different utility (I might try Delight by Color7 productions), but it will be a longer process in designing all of my levels (Using 2x2 tiles). Here's a snapshot of what Level 26 could have looked like (if I'm accurate enough).

It looks as if there will be no more work on Trance Sector until the end of this week because my week's holiday finished on Friday. Unfortunately now I'll have less free time to do what I enjoy doing the most (C64 activities), due to working 12pm-8pm shifts again. I can put my mind off this game for a few days or so, until Friday/Saturday morning. :)

Friday, 18 May 2012

Scroll it the hard way

18th May 2012

Something more interesting to be added to Trance Sector. A 4-directional scrolling field. Well, that's what I have spent most of today's Trance Sector session with. I wanted to get the scrolling movement to move according to the direction the player uses with the joystick. I created a new counter which can check which value will indicate the direction for scrolling background field. Then I stored values of 0 - 3 into the scroll counter. Where 0 = Up, 1 = Down, 2 = Left, 3 = Right, then I added a routine that could check for what value the counter is and added subroutines, which would scroll the characters that formed the background field, according to direction. This took quite a lot of programming to get implemented into the game, but I still have plenty of memory of additional code, since sacrificing the logo to build a new title screen. (The logo will be used for the intro instead). My next task (Possibly tomorrow) will be to activate the shield for the player, for any time it hits a shield tile. (On later levels), then hyperspace (Warping) to a different area on the same level screen.

Tuesday, 15 May 2012

Trance Sector - Continues

15th May 2012 

This week I decided to work more on the game graphics for Trance Sector I wasn't too sure what to draw the game levels with as I didn't want to experience another crash with MSCK. Funnily enough, I found that Charpad was unsuitable to build the levels, because putting the level objects (as single screens) was more difficult. Plus the type of tiles would have been too limited. So instead, I worked on MSCK V2.0 and hoping this time the program won't crash. I managed to rebuild the objects, opened my mind, and built 20 levels. That was Yesterday of course.I even did a new title screen, according to what was written on my little note pad, when I attended RetroVision 2012 Saturday, last week.

Today I worked on installing the new game graphics library into the game's source code, and updated the amount of pods for the player to collect. I even tested the whole game, hoping the library source wouldn't crash. Thankfully it didn't crash. After the 20 levels were fitted in to the code, nicely (Apart from some shield tiles which haven't been programmed yet) I tested through the whole game and found no problems. After I was happy with this, I worked on an ending tune using GoatTracker. Then I ported the music data to the game again. I tried to do some in game sound effects for Trance Sector using GoatTracker, but there were delays before a sound effect played. I think I should program my own sound effects instead, like I did with Sub Hunter and Sheepoid instead. It might be more helpful ;)

The last part of the day was programming the new title screen for the game. In which looks completely different to how I normally program a front end. I usually program a front end using a plain black screen with a logo on the top of the screen, with flashing text, and a scroll text at the bottom. That's nothing unusual. Instead, I decided to work on a more epic title screen, in which displays 1x1 char bricks forming the name Trance Sector on the screen, an upward scrolling ticker tape routine (Like Monty on the Run) inside the window, and also a sprite scrolling message at the bottom of the screen. I was unable to open the borders because for some reason, it kept flickering and delaying when the sprite was there ... So I left it out for the time being. The new title screen looks retro and hopefully the gamers will like it as well. :) 

More work on the game tomorrow or Wednesday. Well I have another 44 levels to build up, and probably add some brand new tiles as well, such as seeker switches. Also to get the shield working as well  ;)

Sunday, 29 April 2012

Trance Sector Preview :)

29th April 2012
Well finally I have a playable preview of Trance Sector for the Commodore 64. Last Friday evening and Saturday morning, I updated several routines so that the player's background collision was more accurate. I didn't even need a char row/column table for the new sprite/background collision routine. Also got the player to be trapped in a prison for a short period of time. The prison turns into a normal tile after the player steps on it, which was intended. I also got the player to move along the magnetic conveyor belts. Finally I added (for the first time ever with my game projects) a keyboard option. This is so that if a player hasn't got a joystick to plug into port 2, they can use Q (Up), A (Down), O (Left), P (Right), Spacebar (Fire).

I sent a build of the preview to a few of my C64 fans/friends and they were pretty much impressed with the work that was done so far. Alas, I had bugs reported which were silly ones. One of which I forgot to restart the game on the very first level after the game was over, and also the playable demo crashed after completing it. Also the player moved automatically after being released by the prison tiles.

Today I worked on making some vast improvements and amendments to the game. First of all I fixed the major bugs/issues which were spotty last night. I also made some graphical updates to the game sprites. I could not resist programming a little objects display routine, so the gamers know what the objects are - before moving on to the front end. I also added a pause/unpause and quit game function. Then sent the final build (I hope it is the final build of the preview) of the game to my C64 friends/fans to test the preview. So far it seems to be working great. I am really looking forward to showing this preview at RetroVision 2012's retrogaming, beer drinking meeting. :)

Friday, 13 April 2012

Unlucky for some

13th April 2012

13 is an unlucky number. Not really :) Trance Sector's progressing pretty well, as I have had spent time working on it during my 2 hour spare time in the morning. I got the collision with the blockers to work correctly, and also got the score in action. The only problem I seem to get is where the player hits the conveyor belt chars. If the player hits the belt, the belt routine pushes the player the direction it moves ... Good ... BUT, the full sprite is not moving on the actual belt chars ... BAD. The new sprite/background collision routine's even LESS complex compared to the one I used to keep using.

While I am still trying to find a solution to this problem, I got all background animated, and also I built 8 levels for a playable preview of the game, which seems to be working okay - except for the game is really difficult. Oh well, tweaking this weekend I guess :)

Monday, 9 April 2012


9th April 2012

Quite a lucky day today. I had a little trick up my sleeve, which worked a treat. On Saturday I was struggling to get the whole set of lights go out in TranceSector, where the player could switch off the lights, but when moving across the screen. The lights are all switched on (Oh dear). . However, I came up with a clever little trick to solve this problem. I had 3 sprites spare, so I decided to use one as a ghost sprite (Trivia: A ghost sprite is a sprite which is being used, but is not visible in the game.).The ghost sprite was set at exactly the same position of the player's ship, but the Y-axis of the ghost sprite was positioned 8 sprites above the player's sprite. This was used to make it look as if the player is extinguishing all of the lights wherever it gets positions. Next. I copied and pasted the sprite/background collision routine to get the ghost sprite correcting the mistakes that were left to the player. Tested everything. It seems to working pretty good now.

Well, I got all of the lights to eliminate, but there is something missing. The concept of this game is simply to eliminate all of the lights in each level, without getting hit by the rockets that zoom towards you when you're spotted. There seems to be no detection of all lights being eliminated. So I added a routine that will check the whole game screen for any lights visible. At first it didn't work, but I found out why :). I made a silly mistake. After correcting it, I got the routine to work. Here's a little video of the game WIP 2 :)


I will be making some changes for the additional objects. :)

Blockers - They can destroy the player if the player crashes into those.
Compactors - These shall be converted into temporary forcefield prison cells. If the player touches the cell. It will be stuck there for a short period of time until it has been released again
Conveyor belt's ... Erm, well, they will be moving the player, although the player will be able to move over those.

Sunday, 8 April 2012

Lights out please

7th April 2012

Back to TranceSector. Well then what has been happening this time round? Well I worked much harder on the game. In fact I spent most of my afternoon getting the game get some more action. Last week you may have remembered that I got those rockets moving left and right. Well, this time I programmed some AI routines in which will give rockets more of a bad behaviour. I added a routine where a rocket is in direct of the player, the rocket will sweep up/down or across the screen towards its target. This will cause the player to want to move out the way. As soon as I was happy with this, I added an extra routine in which makes the rockets explode after they hit the wall in AI mode :)

Although I worked on the rockets behaviour patterns, and explosion animation (Which still requires tweaking). I started working on the Sprite/Background collision. I programmed the routine like how I usually did, but I come across a slight snag (As this pic below shows). Instead

of the player switching off the lights as it moves on to them. The player going up/down switches all of the lights off, where as moving across switches half of the lights off. This isn't really suppose to happen, so I'm going to need to think of a solution to solving this problem. If nobody gets back to me, then I'll have to have think of an extra trick up my sleeve. :)

Saturday, 31 March 2012

Let's Move to the Music

31st March 2012
This week I had even less spare time to do any C64 programming activities - because I have been working longer day (10am-8pm) shifts. Anyway, the good news is that today I have been doing a lot more on Trance Sector. I suppose on Tuesday, I did some work on starting the programming phase, in which was to display the game screen and also the sprites. Today I got to do more.

It was time to move those sprites. So I programmed some routines and subroutines to get the rockets moving up/down, left/right - depending on where they are situated on the game screen. I found that their speed was a bit too fast, so I altered the speed to the slowest speed for all 4 rockets.

Now that I am happy with the enemy movement. I decided to work on the player's movement. Unlike many of my TND game productions, where I use a routine which will move the sprite during every tap of the joystick. I wanted to make a more accurate movement pattern for this game. Mainly because I wanted the player to be able to cover every 2x2 block on screen. So I generated a timer to make the player move a reasonable amount of pixels and stop accurately on to the next 2x2 block.

Once I was happy with the player's movement. The next thing I did was worked on the animation for the rockets. I used 4 frames like I usually do, because I'm not too sure how much memory would be used in the whole game overall. The sprites are not really final either. So it doesn't really worry me much.

After I done the animation, I booted up GoatTracker and did some music for the game. It is surprisingly is a C64 techno/trance style tune I written specially for this game. After I finished doing the first tune, I imported it into the game's source code and got everything working. I even added a status panel to the test screen.

In a couple of days time / or maybe a bit longer. I will be working on the AI (Artificial intelligence) for each rocket, so that if the player gets detected on sight - the rocket swoops across the screen, trying to destroy the player. Then I'll be working on the game collision/logic. Other things to do are animate the background. Such as the void background and traps, etc. Then get the scoring/lives working.

Saturday, 24 March 2012

TranceSector's under development

24th March 2012

RV is just around the corner (In about 6/7 weeks time) and I have started working on a new C64 game for the event. If you remember the classic 'Transector' by Argus Press Software's 30 games compilation. I have decided to a bigger remake of the game. Reason for this: TS was

too difficult to play with so much colour clashing (to the scroll) going on. Enter TranceSector.
What was Transector all about? Basically, it is a game in which you moved a little space ship around the game area collecting all of the pods, and avoiding getting zapped by the
trigger happy cannons. The game would have been good, if there was no colour cycling in the scrolling chars.

My version's planned to be completely different. The concept will vaguely be the same as Transector, apart from the player will be a 2x2 sprite having to pick up the pods, avoiding to get hit by heat seekers. I'm also planning to make the game more puzzling, in which after a few levels a new feature's added. The new features planned for my game project have also been drawn and put together as objects. They are:

- Blocker (Steel brick style object, forcing the player to bump into it)
- Conveyor belts (Move the player if it is on those)
- Trick switch (If pods still exist, the trick switches will bring all pods back on screen, making the game more trickier and confusing :))
- Trap (You will get stuck and the heat seekers will get you
- Hole (Don't fall in there, whatever you do).

So far I only worked on the character sets and started building the in game screens using the Multi Screen Construction Kit and so far have 6 levels designed and mapped. Due to less spare time I had this week, I only gone as far as level 6's design. I will be doing more this week, but here's a couple of screen shots to tease you :)

Sunday, 11 March 2012

Enter the Huntress

4th March - 11th March 2012

I have been enhancing too many SEUCK games, but I just can't really help myself when a good looking SEUCK arrives, I can't resist to touch it. Yet again, I have done it again. I really should have done more to Up in the Air this week, but this SEUCK really surprised me :)

Anthony Burns created a new game using the Sideways SEUCK mod called "The Huntress of Midgard", and the concept of the game was inspired by the nineties classic game, Shadow of the Beast, a classic arcade adventure which was by Ocean software and Psygnosis. So then what's the game all about? Well it is a continuation of Magess of Midgard. The villages of Midgard are in trouble by new forces of evil. The creatures of Morrigan. They are searching for the missing pieces of the holy talisman, so that they can run Midgard under their power. The Queen, Malexia sends in the Huntress of Midgard. She's out on a quest in which is to collect all three pieces of the holy talisman and bring peace back to Midgard. This is just a brief story as Anthony made a large story in the instructions file.

After taking a look at Anthony's game I was very impressed with the idea which he came up with. So the first thing that I did was composing some music for the game.

After I loaded the game in I noticed a trick not used in a SEUCK game before (Wondering if this was possible). The main player was split into 2 players, but you had to use both joysticks to move the object. To improve this situation in the game, I added a POKE into the M/C monitor to set up the correct stop positions for both player 1 and player 2, then bolted them both together using another POKE. Both player 1 and player 2 sprites could move about at the same time. I programmed some additional in game routines, in which would allow the player die (both players at the same time). How was this trick done? Well, I searched for the player getting hit routine, added a subroutine that would detect it and also added a routine where the collision with character 0 would kill the player instantly (Then disabled that after respawn.) The trick worked quite well, but I still had a problem with the player's starting positions. The legs were out of place at times. To solve this problem, I added a routine that would scan the death position of the player (Like I did with Action Def) and reposition the player sprites at exactly the same place where they were killed. This trick worked :).

Other programming that was implemented into the game was the removal of one of the scores. I programmed my own mock scoring system, which then gets stored on to the SEUCK scoring system. Also I added a routine in which the player could pick up bottles of potion or a piece of the talisman and award 1000 points. If 4 bottles were picked up, I made the side borders turn grey, prompting the player to use the smart bomb trick. Then I added a routine which detects the RETURN/ENTER key to activate the smart bomb trick (Which Jon Wells helped me with last year when I was working on SEUDS 2). To give the effect, I added a flashing border as well. I also added a routine that would fix the raster position, to iron out the top screen flicker, but it caused problems for the sprite positions. It moved the pixels up by one. So I left the raster position hack out.

The game has a brand new front end, get ready/game over/well done/end sequences, but for part 2 a correct pass code would need to be entered to see Anthony's excellent end sequence. Now for the final mastering. :) DONE!

Huntress of Midgard is available to download to you C64 at: The New Dimension

Friday, 10 February 2012

The sheep invasion starts - THIS WEEKEND!

Friday 10th February 2012

Believe it or not, we have finally finished the final full version of Woolly Jumper. It's quite a miracle that this game's finished and I will be taking a break from 6502 programming for a week or two before I work more on the Up in the Air project, and also a secret game to spring a surprise on folk for RetroVision 2012 on 5th+6th May 2012.

Anyway, I am pretty much relieved that Woolly Jumper has finally finished. The game has took a few months to produce. We had excellent graphics, I came across various problems with the game, which Shaun pointed out to me. We both worked really hard on this production rather throughout December 2011, January 2012 and the beginning of this month and finally we have made it.

So then what improvements have been made for Woolly Jumper, compared to the RGCD
cartridge version. Well for a start off the game consists of an extra 8 levels, in which Pepito the sheep's nightmare is even bigger and wilder. We have also added some additional in game features which improved the look of the game. I have Achim Volkers to thank for the ROL scrolling char routine support :). We also have added high score table, with name entry routine, new in game music for various levels. There is even a much better ending compared to the 16K version of the game. There's also a power up which will give the player a shield for a temporary time.

Shaun and I have been working really hard to bring a quality game production, although the size of each level's very short (But more difficult and challenging) but that couldn't really be helped. The idea was that each of the 16 levels were 32x blocks long, but the last level was one or two blocks less (but still hard enough). We have added as much challenging game play into the game as much as we can.

I feel that WJ feels like a game in which may have been commercially sold back in the late 1980's early 1990's. Budget quality wise :) First of all the upward scrolling intro, which gives a brief background story, game instructions and playing tips. Then on to the main title screen in which looks completely different compared to the 16KB version. I wanted to make a quality production - rather than rush everything (Like how I used to in the early 2000's - proves that quality beats quantity). The front end starts with the credits, then it displays the top 6 high scores (with names), followed by the power ups, followed by the animated enemies. The main game itself is exactly like the 16KB version, apart from the additional bug fixing and improvements I have worked on (Suggested by Shaun) and also the new protection feature (for the sheep), in which is activated for every Sheep Shearer collected. I added a routine which would reward the player an extra life for every 5,000 points scored to help the player get a bit further across the game. I also updated the rocket taking off (You'll see after you download the game). There's much more in store the full game, compared to the original title. We also added one or two surprises into Woolly Jumper as well which we will not tell you about. You'll have to play the game to find out what they are.

After finishing the main game it was time for the mastering. You may say that this is probably the biggest headache of them all. WRONG! The tape mastering was plain easy. As I used Visiload to do this (WHAT?!?!?!). Of course I didn't. I used the same IRQ tape loader as I did for the 16KB version, with some minor modifications, such as updating the load error routine, and using LDA $D020 : EOR #$00 : STA $D020 for the boot loader, then for the main IRQ loader I used LDA $02 AND #$0F STA $D020 to make it look like the Rack it Loader stripes scheme. The loader uses a different loader tune, which sounds sort of JCH like :). The loader still looks a bit like the Rack It Loader, but I can assure you - I did not use the original Rack It loader.

Mastering the the disk version of the game was somehow different but still very presentable. I wanted to make the production look like commercial quality program (although the game's going to be free). So I used an IRQ disk loader source which Martin Piper released in Codebase 64 (and his web site). I modified it to display Ste86's awesome picture and play music, while the data was being loaded from disk. I also added an auto-boot loader by using Joe Forster/STA's auto-start installer program. So that instead of having to type in RUN. Type LOAD"*",8,1. Like many commercial C64 disks :) If anyone tries to validate the disk, then they're stupid as the boot loader will not boot once validated or the *PRG file is deleted :)

Over all Sheepoid 2 - Woolly Jumper has been great fun to produce, despite some of the problems I came across during the production stage. It got sorted out at the end. I probably played this game over 1,000 times to make sure things were right, and finally we've made it. I would like to take this opportunity to thank everybody who has been involved with this project, or who's looking forward to seeing the final version of the game released this weekend.

Woolly Jumper is NOW available to download for the Commodore 64