 |
Lesson
SuckShoot1 - Suck Shoot on the Vectrex SuckShoot is a simple little shooter game, designed as a test for a minimal 8 bit game. Lets take a look at the Vectrex code. |
 |
 VTX_SuckShoot.asm
|
 |
|
Lesson
SuckShoot1 - Suck Shoot on the Vectrex SuckShoot is a simple little shooter game, designed as a test for a minimal 8 bit game. Lets take a look at the Vectrex code. |
|
VTX_SuckShoot.asm
|
|
You can play Suck Shoot!
| Suck Shoot is a 'miniature' version of my larger "Suck Hunt'
game... Gameplay is simple, you have to shoot bats flying towards the screen... the more you shoot, the faster they get! SuckShoot uses the BCD, Range Checking and Random number code covered in the Multiplatform series |
 |
The SuckShoot code on Vectrex
| SuckShoot on the vectrex uses just 3 graphics images... one for
the player crosshair, and two for the two frames of bat animation. The zoom effect is handled by the firmware, as are fonts. |
 |
| We need to get ready to show the title screen. To show the highscore on the title screen ,we build up a text string in ram. We copy the 'template string' then patch in the current highscore into txtScoreRam at $C880 |
 |
| The title screen needs to be drawn every frame on the vectrex, We draw the "Suck Shoot title", the "High score and the bat! We wait for the fire button to be pressed before we start the game, otherwise we repeat the title screen draw. |
 |
| The Text strings are held in the ROM |  |
| We have two versions of the sprite routine, one for the player
crosshair, and one for the enemy bat. Every time we draw the enemy bat, we toggle between the two possible frames. |
 |
Game Loop
| When the game starts, we first need to set up all the gameplay variables to their default state. |  |
| During the main loop, we first make any sound, show the text
and sprites. |
 |
| We process each possible direction - this is based on the simple
series example. We check each direction button, and the X,Y range to ensure the cursor doesn't go offscreen We also use Fire 2 as a 'fast move speed' - we'll need it for the later levels. |
 |
| If the player pressed fire, we test the cursor position, and see
if it's in range of the enemy. If it is, we make a sound, speed up the enemy, and reset the enemy to a new random position. We also give the player some points. If they missed, they get nothing! |
 |
| Next we update the bat... We speed up the bat gradually, and check to see if the bat is now at 'maximum size' If the bat is in the foreground, the player was bitten, so we take a life away, and end the game if the player has no more lives. We jump back up to the start of the main game loop. |
 |
GameOver
| The game over sequence checks if the highscore lower than the
current score. If the player has a highscore, we transfer the current score to the highscore, show a congratulations message, and wait until fire is pressed. We show a different text message if the player does not have a highscore. |
 |
 |
Suck Shoot...
well, err... kind of sucks!... it's not really built up enough to
be a proper game. But it is at least a simple example of all the concepts you need for a 'Real game'... Title screen, game over, moving objects with collision detection, and increasing difficulty! |
You can play Suck Shoot!
| Suck Shoot is a 'miniature' version of my larger "Suck Hunt'
game... Gameplay is simple, you have to shoot bats flying towards the screen... the more you shoot, the faster they get! SuckShoot uses the BCD, Range Checking and Random number code covered in the Multiplatform series |
 |
| The Dragon palette isn't so great for vampire bat
games!... maybe having a blue bakcground would have been better, but
the that's not the 'choice'*** that was made **** It was a rush job made in two days |
 |
The SuckShoot code on Dragon
| SuckShoot on the Dragon uses 7 sprites, One crosshair, and 3 sizes
of bat with 2 frames each We switch between the sprite sizes depending on the bat position. Each sprite has a pointer to the bitmap, and a width and height in pixels. |
 |
| We show the Title screen, It has a title, highscore, and animated
bat. |
 |
| We update the bat animation until fire is pressed. |  |
Sprite code
| To show a sprite to the
screen, we point Y at the "SpriteData" table entry for the sprite,
this allows us to load the Width and Height and memory address for
the sprite. We convert the pixel width to bytes by shifting right twice. The main bitmap draw routine is basically the same as the simple series. |
 |
| for the enemy sprite, we need centre the sprite so it 'zooms' in
correctly. We also need to switch to the correct pair of sprites depending n the scale (1/2, 3/4 or 5/6) Each entry in the SpriteData table is 4 bytes, so we multiply the offset by 4 to get the pointer for the SpriteInfo |
 |
Game Loop
| When the game starts, we first need to set up all the gameplay variables to their default state. |  |
| During the main loop, we first make any sound, show the text
and sprites. |
 |
| We process each possible direction - this is based on the simple
series example. We check each direction button, and the X,Y range to ensure the cursor doesn't go offscreen |
 |
| If the player pressed fire, we test the cursor position, and see
if it's in range of the enemy. If it is, we make a sound, speed up the enemy, and reset the enemy to a new random position. We also give the player some points. If they missed, they get nothing! |
 |
| Next we update the bat... We speed up the bat gradually, and check to see if the bat is now at 'maximum size' If the bat is in the foreground, the player was bitten, so we take a life away, and end the game if the player has no more lives. We jump back up to the start of the main game loop. |
 |
GameOver
| The game over sequence checks if the highscore lower than the
current score. If the player has a highscore, we transfer the current score to the highscore, show a congratulations message, and wait until fire is pressed. We show a different text message if the player does not have a highscore. |
 |
 |
Lesson
SuckShoot3 - Suck Shoot on the FM7 SuckShoot is a simple little shooter game, designed as a test for a minimal 8 bit game. Lets take a look at the FM7 version of the code. |
|
VTX_SuckShoot.asm
|
|
You can play Suck Shoot!
| Suck Shoot is a 'miniature' version of my larger "Suck Hunt'
game... Gameplay is simple, you have to shoot bats flying towards the screen... the more you shoot, the faster they get! SuckShoot uses the BCD, Range Checking and Random number code covered in the Multiplatform series |
 |
| The FM7 has a weird screen!... it's 640x 200 We'll have to alter our code to compensate for the wider screen... though we haven't stretched our sprites! |
|
The SuckShoot code on FM7
| SuckShoot on the FM7 uses 7 sprites, One crosshair, and 3 sizes of
bat with 2 frames each. We switch between the sprite sizes depending on the bat position. Each sprite has a pointer to the bitmap, and a width and height in pixels. On the FM7, each sprite uses 3 bitplanes for 8 colors. |
 |
| We show the Title screen, It has a title, highscore, and animated
bat. |
 |
| We update the bat animation until fire is pressed. | |
Sprite code
| We need to send our sprite command to the sub CPU, We'll patch in the final X and Y position (and end position) We also send the bitmap data of the sprite itself. See the "Simple series" or Platform Specific series for more details on transferring commands to the sub CPU. |
 |
| To show a sprite to the
screen, we point Y at the "SpriteData" table entry for the sprite,
this allows us to load the Width and Height and memory address for
the sprite. We use these to calculate the start and end range for each axis, and patch them in to the SendCmdPut definition. The X co-ordinate is quadrupled, converting our 0-160 to 0-640... we have to do this because we only use a single byte for our X/Y pos. We then send the bitmap data... but we can only send 96 bytes at a time. We send an additional 3x 96 byte blocks (4 in total)... this is enough for a 32x32 sprite... If our sprite is smaller, we'll send some unneeded data, but the sub CPU ignores it. |
 |
| for the enemy sprite, we need centre the sprite so it 'zooms' in
correctly. We also need to switch to the correct pair of sprites depending n the scale (1/2, 3/4 or 5/6) Each entry in the SpriteData table is 4 bytes, so we multiply the offset by 4 to get the pointer for the SpriteInfo |
|
Game Loop
| When the game starts, we first need to set up all the gameplay variables to their default state. |  |
| During the main loop, we first make any sound, show the text
and sprites. |
|
| We process each possible direction - this is based on the simple
series example. We check each direction button, and the X,Y range to ensure the cursor doesn't go offscreen |
 |
| If the player pressed fire, we test the cursor position, and see
if it's in range of the enemy. If it is, we make a sound, speed up the enemy, and reset the enemy to a new random position. We also give the player some points. If they missed, they get nothing! |
|
| Next we update the bat... We speed up the bat gradually, and check to see if the bat is now at 'maximum size' If the bat is in the foreground, the player was bitten, so we take a life away, and end the game if the player has no more lives. We jump back up to the start of the main game loop. |
|
GameOver
| The game over sequence checks if the highscore lower than the
current score. If the player has a highscore, we transfer the current score to the highscore, show a congratulations message, and wait until fire is pressed. We show a different text message if the player does not have a highscore. |
 |
