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
BNE (CONTINUE PROCESS, WHERE PLAYER IS STILL ALIVE)
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
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
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
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.
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.
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. :)
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
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
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.
+ 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
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.
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.
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)
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
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.