26th
Jul 2009 - Introducing the enemy parameters (Richard)
When
it comes to programming games, logic thinking is desirable. We can't
keep moving objects one direction all the same time can we? Therefore
to make this game more interesting and exciting. I have decided to so
something more interesting. You may have discovered already that most
of my games always used the same "Sprite going straight across
the screen in the same direction and wrapping to another place -
going the same direction as beforeā technique. Well, this is rather
a monotonous thing which has happened in many of my games since 1999.
Since this
has
been happening all the time. I have made a big decision to think more
logically about how I would want the enemies to move and also some
interesting things that I could try to get those enemies moving in a
more exciting and accurate manner. So that this game gets a more
positive karma, unlike some of the rubbish I churned up in the past.
What could be the ideal solution to this issue? Labelled variables of
course. So today I generated some labelled variables to get me
started. I didn't feel like doing the main programming for the
enemies today, due to lack of motivation. But later on this week or
maybe next week I could continue with the main programming side of
this project.
2nd August 2009 - Come Fly With Me (Richard)
Well it has been yet another busy afternoon, and still a
lot of work is to be done before I can get a fully working level. Last
week I was working on preparing the labels for the enemy parameters.
Well, today I have done some programming, using parameters and it took
a long time to prepare and program, but it was worth the Sunday
afternoon for 3 or 4 hours or so.
First of all,
I created the data tables (!byte tables) to represent the behaviour of
enemy's movement. The movement tables will later on be put inside a
timed loop, so that we can vary the enemy's directional movements. Each
table will consist with only '0' and '1'. '0' represents the selected
direction the enemy moves is switched off, and the '1' represents the
selected direction the enemy moves is switched on. For example if I
wanted one enemy to move to the left, directions UP, DOWN and RIGHT
will be switched off and LEFT will be switched on. Or if I wanted an
enemy sprite to move upwards and left, UP and LEFT will be switched on
and DOWN and RIGHT will be switched off.
However, I
wanted to get this routine working in a correct possible manner, and it
took lines of code to program. I had to make an enemy direction store
value, so that the directional table that is switched on will make the
active enemy sprite move a specified direction. I had to create a LOT
of routines to get this to work properly. Mainly comparing the value of
the stored direction. If the stored direction label equals 1, the enemy
can move that direction. Otherwise the enemy cannot move the specified
direction. To make sure the enemy could or could not move, I
tested each enemy by setting the first value of the 60 bytes for each
table (according to the direction I wanted the enemies to move) and
then I assembled and test the movement. Fantastic, it worked. Okay, so
it is not ready yet, but it was a good start for enemy movements. My
next task will be to vary the movements of the enemies, and then get
the floating balloons animated.
5th August 2009 - Head on collision - BANG
(Richard)
Feels like a
holiday after being made redundant last week. Yeah, I know. I am still
looking for work, but I also need a break as well :o). So today I
decided to progress onwards (and upwards) on this game project of mine.
A couple of days ago, Andrew sent me another 2 disk images which
contained yet more graphics for the game. I had a quick glimpse at the
new graphics that wayne did, and I was pretty much impressed with the
work that was done, and the commitment he has made with this game
project. Despite me making it a slow start :o) No rush anyway.
Today I have
been working on the software sprite to sprite collision routine. Well,
there is no point in having a game that will not use sprite/sprite
collision otherwise it would not be classed as a game eh? I created
some routines that will allow the player to shoot at the test enemies
and it works okay, still some minor bugs in the routine, but as soon as
I have ironed those out, it should work nicely. At the moment there are
no explosion animation, etc. for when the enemies are hit because I
want to get everything right first. Well, this is still at its earlier
stages.
So then, how
did I do the sprite to sprite collision routine?. Well, very similar to
Sub Hunter. I created a variable called CollisionXY and created a
routine to calculate the XY positions for the sprite to touch before a
collision is made. The routine looked something like this as below
;==============================================================================
;Enemy Sprite/Bullet Sprite collision and Enemy Sprite/Player Sprite
collision
;==============================================================================
.TestCollision
lda objpos+$00
;Player (Sprite unexpanded)
sec
sbc #$06
sta CollisionXY
clc
adc #$0c
sta CollisionXY+1
lda objpos+$01
sec
sbc #$0c
sta CollisionXY+2
clc
adc #$18
sta CollisionXY+3
lda objpos+$02
;Player bullet (Sprite unexpanded)
sec
sbc #$06
sta CollisionXY+4
clc
adc #$0c
sta CollisionXY+5
lda objpos+$03
sec
sbc #$0c
sta CollisionXY+6
clc
adc #$18
sta CollisionXY+7
REST OF PROGRAM
Now to get
the collision I wanted for each enemy. I created six JSR commands so
that I could test the player bullet to enemy at a time. I had to
compare the value of each enemy (X/Y co-ordinates) with
CollisionXY+Value so that I had a positive collision. After setting up
the collision values I added some routines that would take the enemy
off the screen if a bullet hit it. Yes I know, just a simple enemy
disappear routine, no explosion animation quite yet. BWAHAHAHA! When
testing the player bullet to enemy collision. It appears that enemy 2
disappeared, but the player's bullet didn't. Oops! Blame the programmer
(Ha, ha!). Seems I found a small error in the routine. I used BCC twice
when checking for 2 co-oordinates of the X-position for enemy 2. I have
now corrected that problem.
The next task
which I have done was set up the enemy to player collision, but this
time instead of checking one enemy at a time, I made a loop that could
check whether or not the player will collide into any enemy, except for
the balloon object. Because of this being a test routine, I made it
that any enemy that touches the player, will flash the player's
sprite's changeable colour ($d027) to show that a collision has been
made.Also if the player hits a balloon, the balloon disappears :o) Now
that I am happy with the sprite/sprite collision routines. I can now
get to work on making an actual Level 1, which will test the enemy
sprite's behavior later on this week.
8th August 2009 - Flying through pointers
(Richard)
Today I have
been working on the test enemy death pointers. You may have remembered
a few days ago I have been working on the collision detection routine.
Well today, I have decided to add another routine, which can detect
whether or not all of the enemies are dead or have left the screen,
before we can the enemy sprites. At the moment I have made it that no
more enemies on the same come on to screen until all of those are dead.
This does not apply to the balloon sprite, as I will be adding this on
to the screen now and then via a timer. But that will be later on
during the game.
Now that I
successfully got all the enemies reset after all are dead. I decided to
work on the control of the enemies. Where after all enemies are dead,
the enemies will change type, colour, direction and also speed. I have
decided to leave out the changing of enemy types and positions for now,
as I am more concerned about getting the direction control for the
enemies to work how it should. So I created some new labels and some
more tables that will control the speed of the enemies, using a
controlled loop. Well, that wasn't much of a problem. I created some
new variables and a counter variable, which is called SpeedCounter.
Before I put a routine to work on the controlled loop, I zeroed the
SpeedCounter and then added a JSR (Inside the SYNC loop) to perform a
loop and count up to 60 times (As each table for each enemy
control is 60 bytes long) and the table will not go up until
after all the enemies are dead. I had a few problems first, where I
went a bit wrong with the routine. After I fixed the routine, the enemy
behaviour worked correctly with my test values that I added for the
enemy speed, and direction values. This is much easier and shorter,
compared to Sub Hunter, which I just kept on writing the same routine
again, again and again. Thus taking up a lot of memory. And with this
project, I have plenty of memory to use.
Memory start
for
code
Memory finish for code, below. Data table memory.
Thursday 13th August 2009 - Wayne's game
ideas (Wayne)
Things are going well with the Graphics, Am still doing work at Carols house( Am currently painting the attic-this will be my computer room when I move in!!! ). Since last time I have drawn a Gunship as I had intended, also I had a mad rush of late night graphic drawing with loads of new planes and enemies being drawn, in fact the sprite editor now only has 2 frames free. I have added some weather conditions too but I dont want to spoil that for you, lets just say you will be seeing various elements as you progress through the game. I've also gone back ( again ) and tweaked the character set graphics. I've started to work out the final order for the attack waves too, rather than just have stuff thrown at you randomly I thought it might be nice to see you progress through the game as if you are going through the years of aviation progression.
To begin with you will shoot birds but then you come up against hang gliders, basket balloons, etc leading up to more advanced weaponry like STEALTH BOMBERS and TANKS etc., I had a discussion with Gary Sutton again at work and he suggested an idea for the end of the game which I have drawn, and I've also added an idea of my own too! On the music front I am hoping Andrew Fisher could do a ROB HUBBARD ( famous C64 musician, fact fans! ) meets 99 RED BALLOONS type of tune in-game, either that or just have it as a level complete jingle. Also I would love a WE ARE THE CHEEKY GIRLS theme tune on the high score table ( and then I wonder why people think I am camp? Giggle ) (No covers - pleeeeease :oP - Richard). Meanwhile in my real life, I went to Huddersfield a couple of weeks ago, on my way home I called in at Brighouse Computer shop and ended up talking to the guy who programmed McDonald Land for the C64-I kid you not! Am hoping to get his Email address so Andrew Fisher can interview him, I got Nick Pelling's Email for Andrew a couple of years ago so hopefully fingers crossed I can do it again,
might ask him if he wants to do a C64 game with me too! Also I have started working out the colour schemes for the levels, I reckon if I can do this it will save
Richard some
time, have included the
first four colour schemes with this entry for Richard. The plan
for the finished game is to have 20 Levels including Bonus Levels,
Its slowly coming together now it sup to Richard to do all the hard
stuff and make the enemy movements look good-Geez intense stuff-I
love it! :->
Thursday 13th August 2009 - More and more
information to keep in mind
I had an
email on Tuesday, but I did not bother typing anything in this diary,
as it was something very small. Anyway here is what happened on
Tuesday. First of all I had an email back from Andrew about the game
talking about enemy movements. He said that II should take a look at
the
SEUCK game example and try to implement that. Secondly I also had to
remove the ability for the player to shoot the balloons. As in the
game, the player is meant to collect the balloons, not shoot them. So I
removed some routines that I did not need for this part of the game. So
now the player can only collect balloons (Sprite 8) rather than burst
them with its bullets.
Well, I may
as well reveal some stuff about this game project. So far. I was over
curious about the plans of my own about making this game, but Wayne had
his own ideas. So, this project should hopefully be easy enough to
program and put together. The idea is completely different to what I
had in mind with this project. Earlier on when discussing about the
project, Wayne came up with SEUCK examples about how the game should
work. When I was playing the SEUCK example a couple of days ago, I was
surprised to see how easy this project will actually be. Wayne wants
the game to play the same way just like the SEUCK example, but the
player has to collect enough balloons to advance on to the next level.
Should be easy enough.
Wayne also
sent me an email today revealing the colour schemes for the first 4
levels. I have made a note of those and will implement them when I am
ready to put all of the levels together. It is the main game attack
stages I will need to work on first, before I go any further with
implementing more levels.
Some parts of
the game makes me think that I should have a brain wave for some of the
levels. Later levels of the SEUCK example showed enemies shooting on
screen, but I need to think this idea through. Should I reduce the no.
of enemies that come on screen and make them shoot bullets as sprites,
or should I attempt to make a routine that will allow the enemy sprites
fire bullets by using chars instead as I can't do sprite multiplexors?.
Well, anything is possible. Sprites would be better because of the
smooth speed. Chars would be too rough. So if I had to sacrifice one
sprite to become the bullet (after an enemy goes off screen or is shot)
then that probably might be a possible solution. More of this later. I
have to work on the enemy movements before I decide all this shooting
business. :o)
Sunday 16th August 2009 - 99 More Balloons
(Wayne)
Greetings C64 dudes (and ladies of course! )
Last time I forgot to mention so I will do it this time. While drawing in the sprite editor, I decided it would be really cool to allow the player to choose on the title screen if they wanted to play as a plane or a helicopter, a simple thing but its a nice addition that I thought people might like, perhaps Richard might be able to have slightly different control methods for the plane and the helicopter, i.e. the helicopter is a bit slower and hovers up and down when the player does not touch the joystick and maybe it could have slightly different firepower?
I think the best way of choosing between which ship you fly would be by choosing with a joystick on the title screen like on the Sub Hunter title screen when you choose between music and sound effects. I have also tweaked Level 6. On Thursday, the colour scheme was nice but I needed to add some new graphics for the cacti (?) At the moment its just a case of me going through everything I have done and choosing the colours to go in the final game.
When I have sorted that, I will start doing some new levels. I just can't wait! I also need to draw a bitmap screen for the title screen/loader and work out what the title screen is going to look like. Oooooh, also I sent the latest updates of the character set and Sprite Editor and a new version of level 4 ( I think?) to Andrew yesterday.
On a
personal note Richard got back to
me and said I can't have 99 Red Balloons in the game
for the theme tune cos of copyright issues! Lets just say I am a
bit annoyed about that, I never thought about that-DOH! Maybe the
guys could do me a custom version with that music in HA HA HA!
It looks like I will have to settle for something "safe"
for the finished version, although I do like the current music
running in the demo I possess, its an Andrew Fisher composition!
Richard's bit:
16th
August 2009 - Up, Stop, Down, Stop, and away we go! (Richard)
Well,
Wayne
has been working hard on game graphics again. Pretty good job that it
is not me doing the graphics at the moment. I'm not all that good on
that. However, when I emailed Wayne, regarding the music. I did not say
that we can't do a C64 version of 99
Red Balloons. I
said that I did not like the idea about adding a cover tune into a game
if it is going to be a commercial game, due to music licensing and
copyright issues. I am glad he likes the current music in the later
game demo. The music was actually composed by me (Called "Secret Man's
Search for a Star"), not Andrew. But I will look forward to Andrew's
music for this game project.
I
have been
doing some more programming today. Well, after taking a look at Wayne's
SEUCK example, I decided to update the code so that the enemy movements
were similar to Wayne's sideways SEUCK example. I thought that this was
actually going to be really easy to do. Well, the idea was very easy,
but I had a few headaches with the control of the enemy gliders
(Probably change those to birds if Wayne wants me to). The general
feature for the gliders (or hang gliders) was to use a table of values
which are: up, stop, down, stop and constantly move like that. So to do
this I added a new variable/label called MoveTimer.
MoveTimer
is the controlled variable which will calculate the time of the enemy
movement or directions. I added an extra JSR routine, which was to
operate the MoveTimer
variable, and if the clock equals #$32 then reset and add values
from
the data table to update the movement and enemy speed. The routine
looks something like this
.TimeMovement
lda MoveTimer
cmp #$32 ;Count up to 50
beq .ResetTimer
inc MoverTimer
rts
.ResetTimer lda #$00
sta MoveTimer
inc SpeedCounter
inc MoveCounter
rts
Anytime
the counter reaches 50 (or #$32) , the MoveTimer is reset and then adds
the value of the SpeedCounter and MoveCounter (Read from the byte
tables). This made the enemies move up and down. But there was still a
problem. The enemies may have been moving up and down, but I may have
made a typo error somewhere on the byte tables (up, stop, down, stop)
control. I took a look and realized, that the calculation of each table
was not equal. I decided to try and experiment a little with the table
control routines, and reduced the size of the tables being read. So
instead of 55 bytes per table, I reduced it to 4 bytes per table. After
a test, the enemies were going up, then stopping, then going down, then
stopping to the way they should have moved in the first place. Now all
I need to do is change the up/down control table a little for each of
the enemy sprites, so that all of the gliders are not moving the same
direction at the same time. So I tweaked the tables nicely, and now it
works.
Whoa!... Oh, never mind! Well the glider control is working fine, but
I will need to set some routines that will stop the gliders leaving the
Y-positions of the game screen.
So
how can I
stop the gliders going past Y positions and avoid overlapping them
overlapping the status bar? ... Well, simply enough I updated the up
and down positions, to check whether or not the enemy goes behind value
#$32 or goes over #$d2, depending on whether or not the sprites are
moving up or down. If a sprite tries to go over #$d2, it will stop at
position #'$d2 and if the sprite tries to go below #$32 it will stop at
#$32. Now things are looking much better.
Now
that
level 1 is roughly done, (just random positioning for enemies to go,
now and then) I thought that the score in the game should be changed,
so I updated the status bar slightly, so that the player will be able
to score points. So now, I have updated it. So instead of items, it is
changed to balloons. Also, level is 2 digits, and energy has been
changed to damage. Time is at the bottom and is still 4 digits. Where's
the lives counter? Well, at the moment I am not adding this in to the
game. The damage counter will act as the lives counter, but it could
all change later on before the game is finished. There might be newer
ideas, for the status bar below etc.
Tomorrow
evening, I might do a bit more programming on this game project, by
implementing enemy explosion effects and also get the score board
working, and also later on this week, create the enemy Y-position
randomizer routine for any time an enemy moves off screen in any 'X'
position (Depending on the direction that it is moving). Also, I shall
sort out the scoreboard and also the level time and other routines that
should work on the status bar.
17th August 2009 - Relocate, relocate
(Richard)
Today, Andrew passed me another .D64 with the Up in the Air
project graphics. This time yet more great sprites, and a new version
of level 6, which I could implement into the game's code later on this
week. Anyway, I loaded up the sprites. So many of them, in fact too
many of those. It did not put me off though. I decided to relocate the
graphics data and use BANK 2 instead of BANK 1, as that way it would
make things much easier for me, as the sprites overlapped if loaded at
$2000. So now the game source has changed its memory. Here's what we
have so far:
$0800-$1000
- Spare memory (That could possibly be used for extra variables, or
maybe additional code for the title screen.
$1000-$2400 - The music (Although if the music is larger, as some music
editors players like DMC, I could expand it more, otherwise, I
could add the exomizer decrunch code in this place)
$2400-$2800
- Decrunched screen data
$2800-$2c00 - Decrunched screen colour data
$2C00 - $4000 - Spare memory, maybe for crunched screen data and exomizer decruncher
$4000 - $7300 - Game sprites data (Bank #$02). Wayne filled a lot of memory with various sprites. Perhaps he got carried away here. Heheheh. Still not to worry, that's where I have placed them.
$7400-$7800
- That will be for the actual screen used!
$7800-$8000
- Game charset
$8000-$C000
- Game code. I am not too sure how big the game code will be, but I
have switched the Kernal off by setting #$35 at $01. Which hopefully
means I can add further code here. Good eh?
$C800-$CC00
- Title screen logo colour RAM data
$CC00-$D000 - Title screen logo video RAM data
$E000- $FF70 - Title screen bitmap data.
Sadly
I did not get round to doing the randomizing of data, scoring, etc but
I can continue with that later on this week. So stay tuned. :o) Okay.
Now for a can of Foster's lager and a spot of C64 gaming! :o) Oooh,
nice!
20th August 2009 - Random thinking (Richard)
This
weekend I'll be adding some explosion animation and get the
score/damage counters working. :o)
24th
August 2009 - Wayne
Geez, The
last 4 days I have been having toothache I went to the
dentist today on my day off, they said please come back at 2.15pm, the
pain is blinking unbearable, hope they yank the bleeder out! Done
no
work on the game due to toothache, its been hard enough going in to
work, I just want to lie down and cabbage. I might do some
more work
on Friday night! Also I don't mean to be a pain but as regards
the
game story you are supposed to be a world war one fighter pilot like
biggles but not biggles for copyright reasons obviously. (I second that - Richard)
I DO like the
game legend Richard created " Get
ready for the flight of your life"
Sheer genius that, I blinking love it! I wonder if JSL would draw a
title screen for the game like he did for BOMB CHASE, that would be
nice!
(We must get the game finished
first before we decide about the logo. Because it depends on how much
memory would be spare at the end. - Richard)
24th August 2009 - Fatal PC problems
finally solved (Richard)
Bah. Don't
you just hate it when the PC you are working on breaks down and not
power up and you have no other choice but to buy a new unit? Well,
unfortunately, that is what had happened to me. Well, that old PC was
several years old and
to today's standards was pretty crap and slow. Nice to have a faster
one, although it was spent with some of my redundancy money, which I
was saving up for a years supply of Foster's (Just kidding about the
Foster's - honest) . Therefore I was unable to continue with the Up in
the Air
game project. I am very lucky that I did back this project up
beforehand. Maybe I will get somewhere with the project this weekend,
now this new unit is up and running :o)
30th August 2009 - Explosive action -
crash and burn (Richard)
Now that
everything I wanted to install and configure has successfully added on
to my new PC, I am now able to carry on with the Up in the Air project.
Last week I was going to do some more programming on this project, but
because of the PC constantly being slow and unresponsive, then would
not power up and died. I was unable to continue with the project.
However, I feel very lucky that I did backup the latest update from
20th August, otherwise I would have had to start the entire project all
over again.
So what has
been happening this time? Well, I wanted to add some explosion
animation in to the game for whenever the player shoots an enemy and
then place the enemy at a new position offset from the screen. So what
I did was programmed a routine which will check whether or not an enemy
is dead. If the enemy is dead, then the explosion process starts. How
was the death animation made? If the sub routine for the enemy death
trigger is switched on , this turns on the enemy death animation
routine, otherwise the enemy frame stays as it is (Enemy alive).
The death animation routines are controlled by a pointer, which will
increment a value until reached the total number of frames, which you
want the animation routine to stop at. Then zero the pointer and unlock
the enemy death routine as soon as the enemy has been repositioned
offset at it's newer Y-position location. This worked a treat. I wrote
one routine per enemy, but after testing. I noticed that the scrolling
clouds were messed up. It appears that I have used $7FFx instead of
$77Fx for some of the enemies, as the game character set data is
positioned at $7800-$7FFF (Which is where it belongs). After I
corrected the problem, the clouds were right again. Doh, what a clumsy
clot I am :o)
Now although
the enemies are dead whenever shot by the player. The player can still
keep on shooting at the explosion. That makes the game a bit more
stupid. So I should add settings to turn off the Enemy/Bullet collision
if the death trigger is turned on for the particular enemy. That would
make things much fairer. So now, if the enemy death trigger is not
switched on, enemy/bullet collision is turned on, otherwise the
enemy/bullet collision is ignored. Pretty good.
Now that the
enemy to bullet collision has been sorted out, I can now do the same to
the enemy/player collision routine. Now that this is done. My next job
is to get the player damage status working. Rather than make a char of
the status disappear. I think it would be much nicer if each char of
the damage status indicator was green. Then after an enemy hits the
player, a character of the damage status indicator turns from green to
red. After the damage status bar is fully red. The player gets
destroyed. For now (Game Over mode), I just flashed the player's $D027
colour sprite constantly. I didn't like the status bar Wayne did, so I
made one of my own, using Cuneiform. :o). Then
update the enemy reset positions so that enemy Y-Positions are random,
just like they were after they left the screen during movement after
the explosion process has finished.
Blowing enemies up!
So far so good,
but before we have a bit of a game here. There are still parts of the
game that has not been done yet. For example, the score needs to work,
and also the balloons status should be active. So I added a routine to
get the scores and balloons counter working, specially for the game,
and also the time as well. Now that the clock, the balloons counter and
the damage counter is working. We have a game, but the player's bullet
is still too fast. I think I should slow that down a bit. So I have
reduced the bullet speed from 6 down to 4, much more comfortable now.
My next task
will be to update the player death sequence. The basic idea is so that
the player will animate when falling and then explode as soon as the
player hits the bottom of the screen. I added some values that will
lock the game play, so that when the player is dead. It cannot shoot
the enemies that are in sight. After adding the player death sequence,
I added the Game Over sprites on to the game. Looks more like a game
now. That will do for today.
Mayday, mayday, dive, dive, dive ... CRASH!
Quite a lot of
work to be done here in one day. Next time with the project, I'll be
updating the collision registers and also adding a bit more variety to
the first level, so that there are birds as well as hang gliders for
the first level. Also, we introduce a big boss bird the player has to
defeat to complete level 1.