SUB HUNTER
page 5 of 6
Page 1 / Page 2 / Page 3 / Page 4
/ Page 5 / Page 6


Note: This game project has finally been finished and is now avaiable to download. Either visit the games page
 or download the full game, directly from this page.

To support, Psytronik Software, we have included an extra demo disk, which features playable previews of various games. Or if you wish to buy the game for your real C64 on tape or disk, visit the Psytronik Software web site.



8th May 2007: Level 11 - Crab Attack

It is my week's holiday from work this week, so I decided to do a bit more work on Sub Hunter before I have my lunch at 2 PM. This time it is level 11. I wanted to do another version of the Jellyfish attack stage, and luckily for me, I ended up doing something more tougher and interesting. How did I go about it?

First thing is first. I will be using level 4's background (The cave with stalagmites) and I'll alter the colour scheme. What colour shall I use for this round? Well, blue has been used too many times. It is time for a newer colour to be used. So I decided to use a nice greenish scheme. Looks nice for this level's background. Now for the attack waves. What shall I do for those?



Basically I want to create a stage, based on level 4, but to make enemies to attack from both sides, while they are moving up and down constantly, so I altered the settings from level 4 and implemented these settings to level 11. Instead of having to attack the onslaught of deadly jellyfish, I thought it would be cool to attack the onslaught of crabs, as I only used those once, and there are not really any sprites that never been used. Now I test the level. Damn, it is down right too hard to play. I need to make one or two alterations to it. That is better. However, I should reposition the player's sub to the middle as default position. Especially when crabs come from both directions, ready to attack you. This stage is moderately hard. Just about right for me :o)

10th May 2007 - ?Out of memory + Problem solving, before the programmer even thinks about feeding himself to the sharks (:oP)

After successfully finishing level 7 of this game, I got to work on level 12. This is another shark attack stage. I set the counter for this level to be 50 seconds instead of 30 seconds, and I have also added some speed to one of the big sharks for this round, but when I test it, the game crashed. The code had gone over $8000, which was where the music lies. So I had to do a lot of work to get this project in place. For now I removed the music and routines that played the music (I can put those back into the game when I have finished the whole game code). I also deleted several unwanted routines, to increase the size of the memory. Generally I kept repeating the IRQ code routines, when there was no need for this. So I remove those and add a little routine that changes the colour scheme depending on level That should give me a positive result. In fact it has. :o)



Now I tested the game The only trouble is that this stage's colour scheme looked exactly the same, compared to the previous shark attack stage. So I think I'll change the colour of the sharks from light grey, to blue. Looks much better. The sub is turned back to grey and this stage is harder compared to the first shark attack stage. Especially when the player has 50 seconds to survive the onslaught of sharks and one or two faster sharks are on the loose. So for this stage my job is done and this stage should be frantic enough :o))

19th May 2007 - Another level. It's level 13.

Well, we seem to be getting there with this project. I need to work on level 13 of the game. This is going to be yet another bonus stage that uses the gravity mode. The idea of this level is to collect enough gold bars, but avoid collision with the large black mines that go across the screen. Just like the jellyfish, those mines move up and down, which probably is slightly scary stuff :o). If the player gets hit by a mine or the time runs out, the bonus stage is over and the player will move on to the next level.



However, just as I thought all was done, another problem occurred. There seems to be a case where the player is collecting baby sharks instead of gold bars. A bit stupid I think. I don't seem to know how this problem came by, but I am sure I can fix this problem one day. Tomorrow perhaps.

20th May 2007 - Fishy fix ups

Yesterday, I had a problem with the gold bar issue. (Where the gold bar that the player had to collect, was a fish). I have now corrected this problem and all is looking good. I think now the bonus stage is now complete.

23rd May 2007 - More fixes

Well the bonus stage did not really go according to plan, so I had to try something else, which eventually worked for me. I implemented level 6's code into this level. Well, it is a bonus stage, and I ran out of ideas for this level. This weekend it will be level 14 (If I get round to it).

2nd June 2007 - A video
No programming of Sub Hunter this time. This time round, I worked on a video of the game in action, and uploaded it on to youtube.com. The game coding will continue later on this week. Making this video was a right pain in the ass because the PC kept on crashing frequently. Ah well, at least I got it all sorted at the end.

And now, the video. Music by PVCF/Reflex


18th July 2007 - The boss stage
I got back to the programming of Sub Hunter. This time I worked on the big boss stage. The idea of this stage is that the player has to face the great orange mutant shark, and must blast it 50 times, but the trouble is that it can also fight back at you by spitting out invincible baby sharks (Those fish from level 1 of course). Therefore the player must avoid. I programmed the shark to move up and down, to make things interesting, and I programmed a routine to make the great mutant shark spit out the fish. Simple. However, to get the player slightly racked off, I decided to increase the speed of the baby sharks. Also when the player's bullet hits the great shark, it will flash. I also used the lighting up diver status routine to show the progress before the enemy shark is dead. Anyway, enough talk, just take a look at the pic below. Maybe this will surprise you. Especially that I never done a boss stage before. Never realized how easy it is  :o)



25th August 2007 - Bigger and nastier fish

I wasn't sure what to do today. It was just too hot to go out for a walk, so I decided (despite the heat) to concentrate with the game project slightly more. So now I followed an email I had back from Frank about how the end boss could look better. Because I could only use two sprites for the shark, he suggested that I should expand both X and Y axis of the shark, to make it enormous. And how scary and cool the boss looks right now. One hell of a big fish to battle against.



Secondly, my next step was to fix all of the multiple IRQ raster interrupts to make sure that sprites don't look so broken after they touch a raster line, which eventually worked out nicely. The way for me to fix this problem was to move the LDA #$01:STA SYNC to the very first IRQ raster position, else the sprites would have looked mucked up, and you don't really want a game that is not working properly do you?

After the raster fix ups to all IRQ interrupts, I encountered another problem. Level 3's IRQ had jammed to C64's CPU. So it was up to me to fix this problem. Luckily the problem was fixed after 10 to 15 minutes or so. Now all works fine.

Still more work to be done, but generally getting there. Maybe later on this week I should make a new bonus stage, before I move on to removing the MSCK source and the compression phase.

8th September 2007 - Compression, decompression and music installation

Well once again I continued with the Sub Hunter project. Now that the main game engine has finally finished (Except for the bonus stage) it is time for me to work on the compression phase. Now how am I to do the screen packing? Simple. The first thing I need to do is code a little routine that will display the MSCK library level and then add a routine to extract screen data from $0400-$07e8 to $1400 and then extract colour data from $D800-$DBE8 to $1800 then save it all together and then compress all the screens with the Exomizer cruncher just like the way I compressed music for my DMC albums 4-7 :o).

Once the level screens were compressed with the exomizer I installed the exomizer decruncher routine  to $1000 and added an extra routine of mine that will decrunch the screen data and colour data to the destination address, then display the graphics screen and colour data to the default screen and colour RAM on the C64 ($0400 and $D800).

My next step was to remove the unwanted source and code. So I removed the MSCK library file from the compiler, because I don't need it in the game, plus it takes up too much memory as well. So after deleting the MSCK data and adding routines to get the decruncher working it was time for me to try it all out. First I had decompression problems and CPU jams in Win Vice at first, but after compressing files properly, all the code to decompress and display levels seem to work fine and displayed the correct level screens for me. I was happy with the result.

Now that compression and decompression depression stage is over, it is now time to add the music to the source code. So I loaded up the Vibrants Deluxe Driver V5.1 JCH packed music player, and loaded up the Sub Hunter music. Seems there are problems with the Get Ready and Game Over tunes, as they loop after finishing. Still that does not really matter to me, as I have a trick up my sleeve to avoid this happening, instead of the press fire to start (when Get Ready or Game Over appears) I'll add a routine where the player has to wait, before the game starts or ends back to the title screen.



After testing the music, I exit the music player to relocate it all using the splitter. At first I thought about relocating the music to $E000-$FFFF, but it seemed to have been a bit of a pain in the ass. So I decided to relocate it to $8600-$9FFF, as I believe the title logo wont be all that big to fit on to the screen. Plus I will need some memory for title screen text and scroll text as well. Would be cool :o)  Anyway, I added routines to play music into the game code. Test it all. Fixed all bugs that crashed the game and now I'm happy with the result of the game with music playing. I am nearly finished with the project which is a good thing. All to do now is title screen, end sequence, increase speed for the last 14 levels and final bug fixing. All should hopefully be ready in time for Christmas 2007. :o)

9th September 2007 - Putting the game all together

I have been doing a lot of work on Sub Hunter today. This time it is putting more or less the levels from 1 - 14 levels into the next level. After this, I worked on the get ready, well done and game over delay routines. (But this time the levels are faster and much harder). The other thing which I have been working on is the bug fixing. There are still some more bug fixing to be done before I can actually do something for the new bonus stage. Ah well. :o)

16th September 2007 - Fix up time

Now is the worst part of the game project - The bug fixing. I have not fixed much today, because I felt unhappy, due to being a victim of cyber abuse the previous day. Ah, well at least I did do something to the project. I tested the game and noted down the possible bugs in each level, and noticed one or two things that need to be fixed. Those of which are the Get Ready, Well Done and Game Over sprite displays when the player is playing the luna lander style levels . This is due to the IRQ routines using sprite y-positions on each raster line. So that is one thing that I certainly have to fix. Another is the last level wont work, it just crashes the game. So that is something else that I will have to look at. Level 28 is supposed to be the giant shark, but much harder.

17th September 2007 - More bug fixing

After yesterday's poor attempt at bug fixing (Where I hardly done any), I checked out level 3's sprite bug problem and finally fixed it. Ah, sweet :o) Because level 6 is the bonus stage, I decided to make a quick change to the screen and use the shark cave scroll because later on this week I will be working on a new bonus stage to replace all bonus stages. Basically it is a stage where the player has to travel and avoid the mines as they float past. Nice huh :o) I even made the last shark attack stage one of the hardest, before the player completes the game. This time the player must survive the cave of sharks, that all move fast in 99 seconds. Tough going huh?.

Second thing is that I received some graphics (still under development) for the loading screen and title logo. Frank is still drawing the graphics for the title screen, but I still have the game to try and finish off before I do anything else, but seriously enough I am getting there. :o))

23rd September 2007 - More bug fixing a new bonus round and a title screen

Back in action, I have been busy practically all day with this Sub Hunter project. Man, so much hard work done today. First of all, I had to work out why the well done sprites were displaying on the top part of the screen for level 2. Well thankfully the problem has been solved. I sort of called a wrong routine, which did not position the well done sprites 100%.

Secondly I worked on the bonus stage for levels 6,13, etc. This stage is test your reflexes. While you are scoring points the ship has to avoid the mines. After a certain amount of time the mines go faster, and faster. One problem was to randomly position the mines as they moved off the screen. Well, there was a bit of a position bug in the code, so I had to alter it slightly. Now those mines can be randomly positioned. Next thing that I have done is added a timer routine, for where the speed of the mines increase, until the timer reaches the eighth bit, where the level is complete. If the player loses, they will move on to the next level.




Another job which I thought about doing is working on the title screen. Unfortunately for me, there was hardly any room to put stuff. So I done some serious thinking, and decided to move Drax's tune to $E000-$FFFF to make way for the logo video and colour memory, and also to position the title screen and colour data. I took one of Frank's old character set from the game Zariaros, and tidied up the character set memory using Dunex's Char Editor V2.1 and drew some missing chars and bubble animation frames. Because we want to use animated bubbles. I also made a temporary bit map logo, by converting Frank's quick mock-up and installed it into the possible memories. Then coded the title screen in DASM, and linked everything together to the game.



24th September 2007 + 25th September 2007 - 2 nights of extra jobs

I had a couple of extra jobs to do for this game project, took a while but was kind of compulsory. I received new graphics for the game's scoreboard and status. All were drawn by Frank Gasking. This was a horrible job to do, but most of the job was done. I was required to import Frank's new chars into the game. Replacing the char set was no problem whatsoever, but unfortunately for me, replacing the new screen data for the status bar and the score/high score was a pain in the backside. Still, all it required were a few tweaks.

After doing some of this job, I had noticed more bugs were made, which cause the game to occasionally crash, and also messed up some of the sprite frames. What was causing this problem? Well, I realized five minutes, just before it was bed time, that during the linking process with the CBMCombine, the byte tables were being replaced by the title screen's video RAM data. Thankfully I managed to fix this problem, by adding some routines that will copy and paste the byte sinus tables, etc. and the title screen logo video RAM. So now, seems fine. I also altered the colour of the new status bars to a mix of Brown, Light Grey and white. Looks perfect. I wont show you the screen shot of the new status bar. I want to keep this secret :o))

I still have some more bug fixing to attend to with the game. Things like the flickering rasters (Should be fixed) and also the Boss shark, firing mode (Which seems mucked up at the moment). Then come the end screen, followed by final testing. Beginning of November 2007 should hopefully be the testing month.

30th September 2007 - Off goes the KERNAL

Now that most of the game project is out the way, I decided to expand  the code to make a much better IRQ. This time I replaced all $0314+$0315 IRQs into the non kernal $FFFE and $FFFF, and I placed an NMI at $FFFA + $FFFB so that when restore is pushed, the C64 will not crash the game. At first I had a few difficulties with handling the interrupts and turning those off an back on. After a couple of hours wondering what the hell was going on with my source code, I fixed  the routines to work nicely. Now my next step is the raster debugging phase. Something I hate doing the most, when it comes to writing games and demos :o)

6th October 2007 - Wobble that screen and mines

I have attempted a little more work on the Sub Hunter project. First of all, I added Frank's new bitmap logo into the source files. Then I worked on the $D016 wave routine to add some rippling effect where the Sub Hunter logo's reflection lies. The main reason for this was to make the logo look as if it is stands by water, although in a black screen. :) Seems to look pretty cool. Secondly I altered the bonus stage according to Frank's new ideas. I added some extra routines  and sinus tables to make the mines bob up and down while moving across the screen,. Not only did I alter the mine moment. I also added an extra routine to make a gold bar appear on screen after a certain amount of time. So not only does the player have to survive 8 deadly waves of the bonus stage, but has to collect gold bars for extra points. Looks and plays pretty good :) Tomorrow I'll fix the Boss Shark stage :o))

7th October 2007 - More fishy business for the shark and end screen

I returned to the boss shark shooting. Seems to me as if that boss shark had problems with the way it was shooting. Therefore I had to add a routine to make the shark shoot stuff, according to a value of the clock and to check whether or not the baby shark (Which gets shot out of the giant shark) is offset or not, before the shark can be shot out. This timing was crucial for this game, because without it the sharks would occasionally overlap each other. Now this problem was fixed. I worked on the end screen, which unfortunately does not look all that good to me. In fact I felt rather unhappy with it. I just did not have enough memory to code a cool demo style ending for the game, which I was hoping to do. Some hard thinking is required for this :(

13th October 2007 - Fishy bug fixing

Well, I got up with a slight hangover from last night where I was at my local pub, so I got up pretty late. Now I got to work on the bug fixing phase. Well, I had a few problems related to raster timing. I kept trying to fix this problem, and kept failing. I posted a message on to the CSDB to try and get some help to finding out the problem with the IRQ routine source. It appeared that I added some routines that were not required in the IRQ and also I was using bad raster lines as well. So I was originally wasting my time getting nowhere with the fixing until after the post on CSDB, which helped me out (Thanks guys). Now I removed unwanted PHA:TXA:PHA:TYA:PHA and PLA:TAY:PLA:TAX:PLA:RTI and replaced with only PHA and PLA. Then I got rid of the bad lines and used #x2 #xA for each raster line position for each IRQ. Thankfully this fixed my problem.

After watching Ant and Dec's Saturday Night Takeaway on television. I done the some more raster bug fixing for level 4. Originally some crashes had occurred, because I mucked up the IRQs slightly. After those were fixed nicely the outcome for level 4 was good as well. I also altered level 5's IRQ which seem to be more stable now. Still quite a bit more bug fixing to do later on tomorrow, but I should get through it soon before I consider tweaking levels and colour schemes.

I received an email from Frank with the finalized sprites for the game. One of the fish I used in level 2 looked rather tacky. I viewed the sprites and saw some new sprites that are really cool. Some new subs. One or two new fish and also by special request from me, an octopus. Hmm, I'll add this octopus to the Sea Wolf stage when all bug fixing is finished. I also had an email from Frank about colour schemes for each level. The graphic colour schemes looked nice. Even better than some of my colour schemes. :o)

14th October 2007 - Change of plan and tired

Instead of doing some more bug fixing, I took a look at Frank's designs and I implemented those into the project's source. The end screen looked a bit ugly but wasn't finished. I had to add a few raster splits to make the colours match the way Frank showed me with his final mock up picture. Secondly I come across a problem with the source code. A new char set was made. Frank created 39 frames for the chariest animation. Unfortunately the size is way too big and takes up a lot of raster time. So I come across an idea solution which was to cut down the number of frames, so that I can code a simple chariest animation routine. Well, it worked. I also copied Frank's title screen design, but I added some more animated chars on screen. Once imported into the project source and linked together the title looks really nice. More cooler with more animated chars. It sure was something that made me happy today.

Tomorrow or maybe later on this week. I'll work on more of the game bug fixing stages.

15th October 2007 - Flaming' soapy rubbish, fixing in session

Because I really hate TV soaps, and Monday night is the worst of them all.  I decided to read my email and make some alterations to the title screen. Yep, I had to bring the scroll text back. I also altered the screen and got rid of those purple animated bubble things. I thought the title looked better with purple bubbles included, but it was just too distracting :o)

16th October 2007 - End fix and title fix up

There were still some bugs in the end screen, so I changed the colour scheme of the ending to the way Frank was hoping to see it. I also made a few alterations to the title screen. One of the things which I also done for this stage is slow down the char set animation so that the bubble effect looks even more cooler at a slower speed. Nice result. I sort of mucked around with the Exomizer and added a decruncher text before the crunched program decruncher. Ah the memories of the Cruel Cruncher V2.5+ coming back again. :o))

17th October 2007 - Fix as much as you can

Yet another boring TV night. Just as well I am going up the pub Friday this week. So I worked on a bit more fixing. Frank emailed me back that there was a problem with the end screen. The Well Done sprites were still on screen at the time. All I had to do here is turn off the sprites and the end screen is 100% finished. Now it is time for the thorough test. So I tested through each level to find out what the bugs are and I wrote a bug report in Notepad, to let me know what the problems are and the possibilities to fix those. Bug fixing starts this weekend.

20th October 2007 - Struggling with bug fixing

My first attempt at bug fixing IRQs in level 1. Seems I had flickering rasters after a sprite rode over it. Unfortunately I did not get very far. In fact during the weekend I have struggled badly and could not get the damn things fixed.

25th October 2007 - More bug fixing - yeuch

Level 1's IRQ rasters were still unstable and I still had flickering hell. I needed some help. Thankfully someone had stepped in to advise me how I should fix the first level's raster bugs. It was something which is something I should have done in the first place. I should have timed the values of $D016 correctly so that the sprites would not cause any problems when going over the raster line. Now the bugged IRQs are working the way I wanted them to :o)

27th October 2007 - Clean up operation and a bit of level 4 fixing

After successfully fixing up level 1's IRQ, it was time for me to fix up level 4. There was still a bug in level 4 that caused the player sprite to disappear or go offset when at a certain position. What a strange bug that was. Now where was my problem? I kept searching through the code to find out what the problem was. Seems that the routine I used for the cheat key had no RTS at the end, so I added an RTS, tested level 4's game play and all works nicely. The only problem in level 4 is the IRQ routine. It cannot seem to handle so many sprites hitting line #$C2 causing the line to raster line to flicker. I will need to time level 4's IRQ routine correctly to get it to work the way the routine should work.

28th October 2007 - Raster bug fixing failure

Spent most of the day getting nowhere with the bug fixing for level 4. This job has been doing my head in. No matter how hard I tried to fix the sprite over raster IRQ bug, I just keep failing miserably. I tried reading through various resources but they are just to technical to understand. I just cannot understand very technical things whatsoever. I also asked someone to try and put me in the right direction, regarding the sprite over raster problem, but although he was helping me out, I still could not get the grasp of handling my code properly. So all in all, a very bad day it has been for this project. :o(

29th October 2007 - Colour schemes

TV was crap as usual. I had nobody to meet down the pub either, so I decided to continue work on my Sub Hunter project. I decided to leave the bug fixing until the very last time. So instead, I took a look at Frank's colour schemes for Sub Hunter, and put those to the test. The colour schemes worked out very nicely. I tested the schemes on the first few levels and when satisfied I implemented those on to the later levels and restored the default level colours for the first few. However, I also altered the colour schemes of the first few levels, which included the Luna Lander stage, where the floor uses a red scheme (Brown was impossible, because the outline was painted in the actual char set colour not $D021 and $D022 and the Shark Attack stage caves were green. Looked really nice for the first Shark attack stage. I tested the whole set of levels for their colour schemes. There were still some bugs in the colour schemes, but those were easily fixed. Now the game is looking much nicer with the new colours, compared to my old mock ups. Frank should hopefully be pleased.



Later on, because I have some memory space left, I should hopefully be able to add one more enemy attack wave, which would have to be limited. This stage will be for level 14. I'll save the giant shark until the final battle (Level 28). Not sure which day I'll do this. Probably tomorrow.

4th November 2007 - Another new level and my last new level for the game

Today I have been concentrating on a new level, because I want the boss shark stage to be the last level in the game. So I worked on a new stage, using level 7's background. This time the player has to fight against enemy subs, rescue divers and also enemy fish. To make this level more interesting, I made enemy fish attack from behind the player's sub so that this stage is not all that easy. After finishing this stage, I tested the whole game through. Fixed all the game engine bugs and all I need to do now is fix the raster split bugs. Then the game is finished and ready for beta testing.


9th November 2007 - Double IRQ time - Whohoo!

Probably one of my most stressful days. I have decided to change the interrupt using Fungus' double IRQ interrupt, on Codebase 64, and implement my multiple routines. The double IRQ routine kept failing. It kept crashing, so I had to type the thing all over again. The routine worked slightly, but the raster lines are still not perfectly timed. Most of the day I been trying to get that routine to work 100%. Unfortunately I failed. Maybe tomorrow :o)

10th November 2007 - Wasting cycles

Well, seems I still can't get the IRQ routines to work 100%. I tried various methods to get the timing correct, but unsurprisingly, I kept failing. So I looked around on the Internet for any useful resources about raster timing and missing cycles. Unfortunately, too much theory, but there are one or two examples, which I will need to experiment with before I can actually add it into the game.

24th November 2007 - Colour corrections

I have been going through the updated Sub Hunter level colour specifications documents which Frank had emailed me. Seems that most of the colours were correct, but I was still required to alter and fix the colour bugs for each Shark Attack stage. There appeared to have been some odd colour bug, for the bottom layer of the scrolling cave, but thankfully I fixed this typically silly bug, and now the colour scheme is perfect.

I also had a bit of a problem with the colour scheme for level 23 sea wolf stage, but I decided to make this level look more dark, by only using black and blue scheme. I'll have to wait and see what Frank thinks of it, else I can easily alter the colour scheme for this level. To me the other colours look fantastic :) Hopefully the colouring is finished :o)

1st January 2008 - Fixing

I have been working on some of the bug fixes for Sub Hunter. Starting with the Player shield. In the game the player's shield is on for too long. The shield flashes in 20 iterations, so to reduce the speed of the shield I halved the number of iterations (10 flashes before shield is turned off). So now the player should hopefully be more happier when playing the game.

Secondly (and finally for today) another fix up has been made, which is the Get Ready, Game Over and Well Done sprites. Originally I was thinking about making the player wait a short time before the game comes on, instead of having to press the fire button to start the game, but Frank thinks that it would be better for the player to press the fire button when this kind of event occurs. I have to agree. So I removed the routines that caused a delay when Get Ready and Game Over messages, etc. were turned on. Then I changed the routine to a simple press fire routine. So that when the player wants to press fire to continue playing the game, they can do so. Much better than waiting for the game to continue. :o)

12th January 2008 - More fixing

I have been doing some more fixing of various problems, which are involved with the game. First of all the Get Ready sprites should have appeared after the fade out and fade in is complete. So I fixed this routine by
turning off all the sprites and then after setting the correct sprite values, etc. Turn those back on again. That way there is less of a mess involved.

Secondly during the rescue mission stages, the player ship moves too fast, so now the sub has to be slowed down slightly. So I removed the INX and DEX routines to slow the sub slightly.

Another issue was the level complete routine, where the player ship moves to the top of the surface and then flies off the screen. Well, seems that level 2 and level 3 had some silly problem for where the player's position is not correct enough. This problem has now been resolved. On all levels, the player will move to the correct position (the surface) and will fly off the screen in the correct place.

On level 3 when the game is over, a bug has occurred where the background turns light blue when sprites are shown. I have fixed this problem by adding an extra IRQ to deal with this kind of problem. Now the game over stage is fixed.

Level 4's game speed is too fast for this current level, so I have slowed it down to make this stage easy enough. Secondly, there was a case where the enemy jellyfish are facing the incorrect direction for this level. So I had to resolve this problem by updating the sprites in SpritePad by flipping the Jellyfish the right way round.

24th February 2008 - More testing and fixing

This morning has been hell of a fun morning. Well, I have been playing the game more, but not only to get through the whole game, but to fix various bugs, which I'd find to be a high priority. I noted down in notepad what problems have been found and possibilities of fixing those. Here's what I have found and what I have done to fix the problems:

Level 1

When enemy subs are shot, after the explosion sequence one of the enemy subs appeared on the screen as light green instead of cyan. This was not meant to have happened. So I searched through the game code to find the LDA #$0D using the search option on Relaunch64 and I replaced it with LDA #$03. Then tested the routine and had no problems here.

Level 3

Some strange happenings on this stage. First of all, something which Frank had pointed out to me. The player could still collect the diver, even when hit by an enemy (and during the explosion sequence). This is one issue I had to find a way to fix. The second issue was that when the oxygen counter hits 0000 and the player is at the top of the screen, a diver, collected is saved. This should not have happened. The player could even move when exploding. I have fixed this problem by adding in routine in each JSR statement to check whether or not the player is dead. If the player is dead, then ignore process else continue. For example

LDA PLAYER_IS_DEAD
CMP #$01
BNE (CONTINUE PROCESS, WHERE PLAYER IS STILL ALIVE)
RTS

Level 4

There was only a very small mishap which I found in this level. During the death sequence, the player could still rescue a diver. At times during this process the diver status bar increased to all divers rescued and automatically ends the level. This is one thing that should not have happened. So yet again,  I added the tiny routine (from level 3) to disable all collisions on this level, and problems like this were resolved.

Level 5

There seems to be a case where the player was able to press fire during the Shark Attack stages. This automatically turned off the player's shield. This was a bad idea so I had to add a routine that would disable the fire button, by comparing the value of the stage that the player is currently playing.

Secondly, there were some unfair collisions. During player explosion if an enemy went over the player (even when exploding) a collision has been made. This problem would have meant that the player would have lost more than one life at the same time. So I had to add a routine to check for the player whether it is dead or not. If dead, then ignore collision processes.

Level 6

Only a couple of bugs were found in this stage. Some of the mines bob right in front of the status panel, when it should not happen. This is to be fixed later. The second bug (which is now fixed). The shade of one of the mines was coloured light red where the rest of the mines were yellow, so I changed the default colours for this stage.

Level 7

Once again there was a colour bug in this stage. When an octopus is shot, for some reason a green baby octopus appears on to the screen. I fixed this problem to make sure that after the enemy death sequence, the octopus is cyan. I also added the bobbing sinus to the baby octopus instead of the sea creature moving straight across the screen.

Level 12

There was only one problem with this level. The status bar was incorrect. I fixed this problem by adding the clock copy routine from level 5. :)

Level 14

Just a colour bug needed to be fixed here. Grey subs turning into blue subs. Not a good idea. So now all subs are grey after explosion.


That's all that was done today. I have been checking through my google document more which contain more suggestions from Frank to tweak the levels to gain more good results as well as final scores for enemies killed, etc. Hell of a lot of work to be done there, such a very long process. So I'll be taking my time with the fixing and improvements of this game. Even if it does take another year or so (Hopefully it will not take that long).

16th March 2008 - Even more fixing and testing

Over 3-4 years of hard work with this game project, but I still have to fix those dreadful bugs and make improvements on this game. Anyway I have been doing more on this project today. Starting with some level fix ups.

Level 2 seems to be fine to me, but according to Frank, this stage is way too easy, so the clock should be knocked down by 10 seconds. So now during game play, the clock has been set to 20 seconds instead of 30. Level 2 is still easy to play, but thankfully it is not too easy. :o) Now when I try to play level 9. The 20 seconds clock appears in this section. That should be set to 30 seconds for level 9. So after a quick tweal or so, it works.

Level 4 was my main suspect. The level seems to be too hard, so I had to slow down the X-movement for the first Jellyfish fighting round. Another problem that I had come across was that the jellyfish did not reach the top of the surface correctly. Therefore that was making it way too easy for the player to avoid the enemies. So I altered the finish Y position before the enemies change their Y-direction, accordingly. Looks and plays much better now. All I have to do now is do exactly the same positions for the enemies of level 11 and all should be fine. Actually those are fixed.


Title + end Tweaks
I was going to leave those until last, but I decided to do those now. Not much has been altered, just the title scroll text and the end text. The end text now has the correct text added. Looks much better.

13th April 2008 - Meet the Doc.
I did not really do anything as I was unsure what to do next for the fixing/improvements stage. I took a look at the google docs which Frank and myself were filling to make things more improved for the game. Sadly I did nothing apart from answering various questions. I think some of my responses may have been a bit silly at some parts. Ah well.

15th April 2008 - Getting a bit late
I was originally intending to do some more Sub Hunter fixing today, but unfortunately time has got me. Pretty tired as well. Maybe tomorrow. The way I plan to fix Sub Hunter will be by going through each problem for each level slowly. It may take time, but it should be worth the effort. I am seriously sure about this.

16th April 2008 - Higher scoring, and some other bits
I was following the google document which Frank processed to help me fix more things in the game. The first thing for me to update and fix was the routine where a diver is saved. Originally the scores was 200 points per diver collected. Frank suggested that I should make it 1000 points per swimmer saved. So I changed the routine. So I tested the new scoring routine and it did good :) 1000 points was scored for a diver rescued and no other problems there.

The second thing which I had to do was update the punishment routine (Where the player loses oxygen per swimmer shot). Originally this was 100 points from the oxygen counter deducted per swimmer shot, but Frank asked me to make the routine subtract 200 points from the oxygen, to make the game slightly harder and fun.

Thirdly comes a problem with the Get Ready display routine. Seems that after pressing fire to exit the Get Ready prompt, a bunch of messed up sprites appear for a few milliseconds. There was a solution to this problem and I successfully solved the problem by adding a routine that will put all the sprites at X and Y position of 0 and then the game comes on. Worked a treat :) Certainly much tidier.

Next, Frank asked if the player ship could move back further than the current position in the save the diver, shark attack and bonus stages. I fixed this routine to make the sprite move slightly further to the right, which is probably more comfortable for the game player.

3rd May 2008 - Get ready to move, oxygen and time concepts
Looking at the Sub Hunter google docs I have read through one problem which was where fire button was pressed. If the player pushed fire on level 3, the player sub automatically starts moving down. Well, this problem needed to be resolved. Seems that when the fire button routine is used, it is very sensitive therefore a delay is needed for each part. So I come across a cool idea, for the player. After pressing fire to play the level, the get ready sprites move across the screen to the right. Once the sprites are offset, the level which the player starts begins. This also fixed another of my problems as well. The exploding player (after fire pressed) bug.

My next step is to reduce the oxygen counter for the levels. The counter must be set as 4000, to make the levels more challenging. Actually various levels should really have a varied set of oxygen. So I have created an extra routine to store the default value of oxygen for the various levels that are being played. Hopefully this will enhance the game play a bit. I also followed the Sub Hunter docs to set the oxygen to a specific amount through the documents that Frank gave me. I have implemented this in all of the levels.

Now this problem has been sorted out, the next job is to sort the clock for each Sea Wolf and Shark Attack stage out. Which should hopefully be no problem. Just as I thought it would not be a problem, I come across another major problem. When the game comes to level 5, a CPU jam occurs. Could this be my problem with memory? I'll have to take a look at this problem right now. I hate it when THAT happens!

The problem is solved. I figured out what it was. The game code was overlapping the title screen data, and when I was building the file, the title screen data moved over the game code. Now the main game code is working, I need to figure out where to move the title screen data. I scanned through the whole memory in the action replay cartridge and I noticed some wasted memory in the game code. I deleted the wasted memory. Also I trimmed the screen and colour data for the title screen and moved it to a smaller area. Now my memory problems have been solved. Good job I wasn't in a stressful mood doing this.

Now I test the game to see if the clock works. Eureka it does.

More tomorrow :o)

4th May 2008 - Making more fish bait
There seems to have been some problems with various stages in the "Save the diver" levels. On some of those stages, the enemies cannot seem to kill the divers if they touch it. However, I was wondering to myself, hmm. How was this problem caused? I browsed through the code and found where the problem lied in the check diver to enemy collision routine. I forgotten to compare the stages 8, 11, and 14 so that was why there was a problem where there was no collision. So I added the levels to the compare routine, tested the game and it seems to work. Great ;o)

Level 14's subs moved too fast, so it was suggested that I should slow those subs down for this level.  Now I shall read the googledocs from scratch (Only the things I missed out and should be possible to do)

First thing I needed to do for level 5 is set the two giant sharks (of level 5) at the same speed and slow the baby sharks down. This is so that this level is easy enough to complete. Well, the idea for this stage is to survive the onslaught of giant and baby sharks in 45 seconds. :o) There is also another problem with this stage. We need one or two baby sharks to go the opposite direction.
At first I thought it would be impossible because there were no baby shark sprites facing the opposite direction. So I took a look at the sprites in the Action Replay sprite viewer and I noticed that there were some unused sprites that I did not need. So I dug out the sprite pad and copied the baby shark sprite frames, flipped them horizontally. Now we have baby sharks coming the other direction. Neat!

There is one major problem or flaw in the game which I will need to look into some time later on this week or maybe next week. Making tables to randomize positions of the enemies so that they do not appear on the same line where one enemy was already placed.