Granny gets some real action now.

28th February 2010

Today I have been working on the tweaking of the IRQ routine. Seems that I was using one that runs on the BASIC kernal, so I decided to switch that off and use the standard non-Kernal interrupt vectors $FFFE & $FFFF and also switch to NMI Lock using $FFFA & $FFFB. Works fine, now what I want to do is get those enemies stopping at a certain Y position, then move an X position, then walk the rest of the way downwards off screen. To get this working, I need to create some loops and some data tables. I will also need to create some triggers to make the characters stop moving Y if they are moving X. Also depending on which X direction each character should move, I should create a table with switches to show whether the characters have to go left or right. In theory this method should hopefully work.

I tested the movement for the first character with the random stopping position movements for just one character and it worked a dream. Next I implemented the same routine to all of the characters (except for the store assistant) to get them moving. This wasn't working properly at first, but after a few tweaks or rewriting of the code, I got all the characters moving through a random basis, to make game play slightly more interesting.

Now was the time to work on the sprite to sprite collision. I used the same collision method as usual as it makes programming much easier for me. I know I have used this collision routine time and time again, but it is something that could be remembered really well, without having to do so much research. I created separate routines corresponding to each character and linked all of the collision routines to the player's fire button press routine. Unfortunately there seems to be a silly error in the code, in which all but one character stops if Granny hits that character with her cane. I found where the problem lies. It seems that I RTS the movement command which causes all enemies to stop. So I made some multiple JMP to next routine commands to make things work correctly. Well, it seems to work now. I also got the coin routines to work nicely as well.

After all the collision routines worked correctly, I worked on some sub routines that will show the death animation sequences for the player, and also for the enemies that have been hit as well. Seems to be working fine. Now to add the scoring and lives counter, then I shall call it a day for today and do some other time.

Granny waits outside the Supermarket

Monday 22nd February 2010 On Saturday I got Bionik Granny to move around and worked on the whacking animation. Today, I did some more programming on this comical game. First of all, before I get the main characters on screen. I decided to program an animation routine, and test each animation on one sprite. Unfortunately the animation never worked. I wonder what went wrong? I did create timers and pointers for the animation and increment those the way I usually do. Apparently there was some strange bug inside the animation routine, which did not allow to cycle. So I decided to reprogram the animation sub routine and was lucky this time round. Unfortunately the animation for each character was a bit of a mess. It seems that I made a few typing errors in the byte tables that represents the animation frame for each character. After correcting those (by testing sprite frames one by one) , I got a better result. Animation's fine.

Now the animation has been updated and the correct animation has been added to each sprite. I programmed some subroutines that will give the bad character some bad behaviour. The supermarket assistant, that hangs around outside doesn't like Granny hanging outside Tezco, so he moves around left and right and throws a supermarket trolley at a random place. I made the supermarket trolleys move downwards. I also got all the other characters to move downwards, but next time I program on this game. I will make random X/Y stopping positions for each shopper character, so that we get more variety and unpredictable X/Y positions for the shoppers. Making it more enjoyable compared to the original Bionic Granny. :o)

Granny is on the loose

20th February 2010

I done some more work on Bionik Granny Returns today. First of all, I drew some more sprites for this game. I created some shoppers, store man, trolley, ghetto blaster, etc. I shall not tell you everything as that would spoil the surprise.

After dealing with the sprites, I went back to do some more game code. I created some data/byte tables to represent frames and colours of the characters, which Bionik Granny will want to whack during her day out. Also I created some frames for the various hazards that hang around during the game. As soon as I got the byte tables sorted out, I programmed routines to initialise all the sprites, positions.

After the initialising of the character sprites I got started working on the game loop, which will expand the sprite position limitations and also I got the player moving, and animating. Now it is time for me to prepare some logic to this game, so that granny is using her cane to whack anything that comes along. Well, after a bit of logic I successfully got granny's cane moving. Whenever the player presses the fire button. She can use her cane. Now my next task will be to get some characters come into the game, but I'll work on this probably some time tomorrow or Monday afternoon. I do also have the Up in the Air project to work on as well. So I might do UITA tomorrow instead.

Bionic Granny travels to the future

19th February 2010

Bionic Granny. Either you would have loved this game, or you would have hated it. Well, I played this Mastertronic classic yesterday for a laugh and decided to create a remix of the original Bionic Granny tune using DMC V4.0. I even did a rubbish SEUCK game based on Granny's antics yesterday as well. Am I terrible or what?

How did I come up with this silly SEUCK made after 1 - 2 hours? Well, basically, I was on an Instant Messenger client and mentioned that BMX NINJA was one of worse games to ever have hit the Commodore 64. But, little did I realise was that there were C64 games worse than that. That was of course Bionic Granny by Mastertonic in 1984. I tested the original Bionic Granny game for myself. It was complete and utter pants. It was one of those games you would have seen made with the Games Creator or Creations game maker tools. (The best game I ever saw made with this probably was Golden Head, an Indiana Jones style game).

As I was discussing with a friend on MSN messenger, I came to a very daft decision to bring back the infamous granny and create a tribute game. That's right fans, Bionic Granny is going to have the Crapcade Games makeover.

For any of you who wants to know what Crapcade Games is: Crapcade Games is a fun label where we give existing game titles a makeover just for fun. And try to make them better, unlike their crap counterparts.

However, although this game is going to be taking a makeover. The concept of the game will be simple, but more fun. For example, we will want some real action involved with this silly game, so the player shall have the opportunity to move Granny left/right (like in the original), but instead of running into the people she wants to whack with her cane. Pressing fire will activate the cane. There will also be a hidden quota. As soon as enough people have been hit by the cantankerous old lady, a coin will move downwards. If the player collects enough coins (by whacking enough people with the cane), they will move on to the next level. Also the speed for each character will depend on the level which you are on. Also planned is a front end with a different piece of music, with flip pages. First showing the credits, then the game instructions, then the high score table.

Anyway, today I got started on working on some in game graphics for this game. I used the Multi Screen Construction Kit utility to design my own screens for the game. It took a while for me to design those screens as I wanted to add some quite nice detail to the actual game's graphics. The result for outside the Mini Mart turned out quite nicely (See pic below).

Other level screens I designed using MSCK were the Park, School and Public Toilets. (I might do a boating port or pub if I get round to designing some more screens. It depends how well the first 4 levels will turn out. There could also be a possibility of some more screens later on if I can think of any more levels for the game. (Huge grin). Then I used the WinVice Monitor to capture all colour and screen data of this game and stored it to the .d64 using:

s "name of file" 8 (source add) (destination add) and that worked out well.

My next step was to make the game sprites. So I dug out the Sprite Editor V1.0 by demo group Faces and drew the characters (sprites) for the game, starting with the Bionic Granny frames (Look much better than the original Bionic Granny), then I drew the kids and lollipop lady and the spinning lollipops. The sprites part is still unfinished, but this will be ongoing for a short period of time. Finally after that, I decided to improve slightly with the Bionic Granny remix, by adding a touch of extra melodies. As soon as the piece of music was finished, I decided to work on the game code. As well as the school stage, I am hoping to add some other characters like, dogs, angry shoppers, drunks, ghetto blasters (blaring notes at you) and some other interesting things.

Unfortunately not much time was spent on the game code for this game, as it was time for tea. So I only programmed in the game screen, IRQ player, etc. But hopefully I should work on the actual game and have something in action some time soon.

As soon as the game is finished and has been tested. It will be released on my web site as a free download and I'll make an authentic tape loader based on the Mastertronic Visiload loader (blue screen and flashing multicolour border) but of course, with loading music.

Oh no ... The aliens are back to invade your loading screen

3rd February 2010

Do any of you remember back in the late 1980's or early 1990's, you inserted a tape and loaded it up to be presented with a little game like Micro Painter, Invade-A-Load, and Load 'N Play. Well, Interceptor Software and Mastertronic may have done this back in the days, but a new kid is in town. Moo-tilation (also known a Moo-tiload) :)

I came up with this little game idea after someone contacted me to ask me if I am able to implement a game into Martin Piper's IRQ Turbo Tape loader source (available from http://codebase64.org) that I always have used to master tapes for Psytronik Software and for my personal collection for the TND web site. After finishing Mutilator on Saturday last week. I originally drew a silly loading picture for the tape loader of this game, but it was complete and utter pants. Well after all I am no artist :o). I thought to myself. Why should I present this game with a duff and stupid loading picture when there could be a possibility of adding something slightly better? So, let's mutilate some cows :)

1st February 2010

I decided that I should give making a loader game a try and also attempt to link it through to the IRQ Turbo Tape loader. So I got designing (using the Multi Screen Construction Kit) to get the game background design. As soon as I was very happy with the final screen design, I captured the screen data, colour data and char set data by using the WinVice Monitor and also Action Replay cartridge. I saved each part separately and then composed some music for the game, using Music Assembler V1.1. I fancied composing something in a sort of Italo disco remix style and ended up with a pretty neat, which the main beat reminds me of the introduction bass line to Around the Planet by Laserdance although the tune isn't like the original cover. I know that FCS of Finnish Gold did a really good C64 remix of the tune using Future Composer. Because I really liked the tune that I composed. I used Goat Tracker V2.26 to do a remix of the same tune I did, but because the instruments were example instruments. I decided to stick to the version which I used.

After finishing the music, it was time for me to head off to the programming stage. So I got started with the main code. Unlike how I normally program games (by SYNCing outside of the IRQ interrupt) I had a simple theory in which is to put the main game subroutines inside the interrupt of a tape loader (Where music usually plays). Because I wasn't that ready for importing this work into the tape loader. I programmed the usual IRQ raster interrupt routine. You know which one I mean? The JMP $EA31 type of thing? :) Yes that's right.

The first thing I did to programming the game was to get the graphics to display, and then get those enemies moving around the screen. My first idea was to have the player as a cross hair, but sadly it did not work out. So the player became a tank instead. Now although the main part of the game was finished, I had some problems, which I will have to resolve tomorrow, as it is getting late now. Night, night.

2nd February 2010

Man, what a blasted annoying morning I had. I was pestered too much by the family dog, and I have been rather poorly as well. Still I was able to continue with this loader game project. The main body of the game was finished, I just had a problem - The Mutilation. It took me a few hours to work out and correct, as what I wanted was an alien to charge down and mutilate a cow. So I programmed a routine which will use a timer to pick an alien (from the mutilation table ) to charge down and mutilate a cow. Well, that sort of worked, but my major problem was collision. When a sprite was moving down and it was shot. The sprite still moves downwards or upwards during the explosion process. I managed to fix this problem, by comparing whether or not the alien was hit during movement. Well, seems that the alien stops when dying, so that worked fine. Now the final part of programming the game. To check if both cows on the ground have been mutilated. If so, then bring back the credits text.

Finalising the data was quite a challenge. Well, it wasn't much of one. I created a routine to initialise the the game data, so that the background, etc is shown. Then afterwards removed the standard JMP $EA31 irq routine, and used the game loop as a JSR play routine. I estimated the initialise and play addresses of the game data and then linked it to the loader source. Oh dear, too many blocks to count (50 something odd blocks of data, included wasted memory). After I linked this and altered the IRQ tape source, it sort of worked, but the long loading time would not be worth it for a loader game. So I decided to try and use Exomizer's level packing method and then link the decruncher at the end of the packed data. Then I put the packed data into the IRQ turbo tape source. Altered the INIT/PLAY routine again and I successfully got a loading game. Bloomin' fantastic, 21 blocks instead :) Time to show this loader off to some of my contacts, who might be interested to see it running.

3rd Februrary 2010

I had some emails back from my contacts/friends about the loader. They thought it was pretty cool. I'm very happy with the overall result, however I really could do with updating the source, so that the loader looks more professional. So I decided to remove the annoying loading noise, alter the colour bars to make them a black border with thin lines. After each block counted, the loader cycles backwards through the colours of the thin lines. You might have also noticed that when I use the Turbo tape routine. And below, specially for you is the Moo-tilation video. Expect to see this loader game appear some time in the near future on C64 productions by The New Dimension :)



Mootilation (Moo-tiload final version of loader, tested on Mutilator)

At the moment, the loader will not yet be available from the TND web site, until after the release of Mutilator (Which will be shortly after Digital Talk #90 has been released). There may be a chance that I might create a little tool which will master Moo-tilation on to a tape along with your game in the near future.

Tips on making a tape loading game:

If you are a C64 programmer and feel like tape mastering your own games, demos or other work and you are unsure how you could make a loading game? Well, there's a simple theory to it. If you take a look at the IRQ Tape loader source by Martin Piper (published in www.codebase64.com) then you will notice that an IRQ tape loader uses INIT and PLAY addresses for music. What you need to do is set up the correct raster positions (as we don't want bugged sprites during a loader game do we?) and also change INIT and PLAY address to initialise the game (not music) and then play the game (not music). The whole of your in game routines MUST be inside the PLAY address inside the IRQ's interrupt of the tape loader. Both INIT and PLAY must use RTS as the end/loop for your game. That's how it worked for me. :)