This week, has been quite an active week. Especially after wondering what to do for a small future game project. During my childhood, through to now. I always enjoyed Retro Games, and 'Space Invaders' was one of my all time favourite games in the arcades. Well, that's it. I'll code my own 'Space Invaders' type of game. ... BUT WITH A DIFFERENCE. :).
Many C64 Space invaders games used either 1X2 or 2X2 char sets. There were some great classic remakes of this game. Take for example 'Invaders 64' by LiveWire, for example. It used 1x2 char sets for the invaders, but the game was pretty much slow and too easy. There was also Firebird Software's "Arcade Classics". Another stunning collection of simple arcade classics, by Ubik. The Space Invaders game was great. It used 3x2 charsets (if I worked that out right). What about my Space Invaders? ... I always hated coding charset movements and got into loads of scrapes with it. So, as an alternative. I decided to go with SPRITES.
Behold the beginning of a new C64 project called:
LET'S INVADE
First steps: Sprites
For the first part of the little project, I booted up Sprite Pad. I drew some sprites for the player ship, the player's bullet, 2 frames for the aliens and also the player and alien explosion sprites. I also created the GAME OVER text using sprites as well. I generated .PRG files for the game project.
Next step: Charsets
For the main game, I want to be able to use a 2x2 charset for the text and scoring panel. So, I loaded up Cuneiform, and designed a hires-character set.
Big leap: Coding
The next step was to program the game. For this little project, I decided to use Notepad++ with KickAssembler and Exomizer plugins. This would make my game development a whole lot easier. The user of MACRO commands inside KickAssembler, also makes my C64 coding life a whole lot better as well. I programmed the game by generating multiple interrupts that can display 1 sprite for the player, bullet and alien bullets. As you know the Commodore 64 can limit itself to 8 sprites by default. If I had just 8 sprites in this game, it would have been too boring :). I wanted 25 sprites for the aliens. In order to do this, I had to use multiple rasters through an interrupt. Basically the so-called 'Fake-Multiplexor'.
After getting all of the sprites to display, the next task was to get the aliens moving. In order to get the aliens moving, I created a timer in which controls a delay of the alien movement. Then after the delay timer has reached a set interval, a subroutine is called to flip the alien sprite animation. Once an alien reaches the end of the screen area, a raster position moves down 8 pixels, forcing the aliens to move down. Then alien movement swaps direction.
Now aliens were able to move left/right and drop down a row, etc. The next step was to have an active player and bullet moving. The player gets controlled using a joystick plugged into port 2. Eventually, I might also add a keyboard control for player controls. Pressing fire tests the player's bullet. If the player bullet is still active, then another bullet cannot be shot until after the bullet has left the screen.
The tricky bit was setting up the collision for aliens to player bullet. I needed to set the sprite/alien collision, according to the sprite position, raster position, and check whether or not the alien is dead or not. I didn't want to type in the same code for collision checks 25 times (1 listing per object). So in order to solve this problem, I generated a macro command. After assembling, and running the collision code, it did sort of work, but for some strange reason I had two rows of aliens hit at the same time. It turned out to be a problem with the raster position, and wrong rows set. This problem eventually got solved and the bullets hit the aliens respectively.
The next step was to set the alien bullet drop. For the aliens to be able to drop the bullets, we don't want the aliens to be dead. That would be silly. To solve this problem a small routine was generated in order to check whether or not the alien on a certain raster line is dead. If it is, then keep on randomizing the timer until an active alien is available to drop a bullet.
Nearly getting the main engine of the game sorted out. The aliens need to be able to hit the player ship. Should the aliens hit the player, a life should be lost. At the moment, I just set an infinite loop to completely flash the border while destroying the aliens. There's a bit more work to be done, but here's the first video of the work done so far on this little summer game project.
Other things intended for the game and ideas how it could be implemented?
-The player death sequence needs to be implemented into the code.
-Alien death (Remove visible alien sprite). Use bullet sprite for the SPLAT animation, to destroy the alien
- Active scoring and lives system. Aliens should give out different scores, according to the type. (Ranging from 100 - 500 points). Lives should be lost per player hit by alien or bullet
- Levels and variety. Each level will use the standard alien formations, but each level should differ. The concept will be quite different to a standard Space Invaders game. I intend to have aliens use colours in order from LIGHT (Strong aliens) to DARK (Weak Aliens). If an alien turns into a darker colour, it will get destroyed.
- A nice backdrop or animation. It would be nice to add some in game graphics, which could represent a city or maybe some cool effects behind the aliens (2x2 moving tile background animation).
- New music and SFX. Could be trance music. Who knows?
Watch this space for more progress updates and videos.
When is the final game intended to be release?
Since KickAssembler really helps me well with a lot of the code (Generating macros, etc) then it could be possible that this game could be finished BEFORE the end of August. It will be available FREE from the TND web site as soon as the program is finished.
