Lazer Force is one of the myriad budget shooters which materialised in the mid 1980s on the C64, hailing from Codemasters and programmed by Gavin Raeburn who already had a couple of shoot ’em up previously distributed by Alpha Omega and the bi-directional, horizontal blaster Thunderbolt, which was distributed by Codies.
The levels are divided into four parts; a very busy vertically scrolling shooter with tons of character bullets and fast moving nasties leads into a Centipede-inspired affair which is overlaid by more of the chaotic sprite-based enemies. These high octane battles are followed by a significantly more sedate refuelling sequence where the player’s ship must be precisely placed on the docking bay of a mothership as it drifts back and forth across the screen and, regardless of if that sequence is completed successfully, there’s also one of those tunnel navigation games where the terrain is randomly generated; the player earns more points for going faster but risks losing control and mashing the craft into a wall before the timer runs out.
Whilst the first couple of phases are simple but often frustratingly difficult fun, the latter two feel as though they were just tacked on as an afterthought. Suddenly transitioning from thumb blistering action to the slow-paced docking stage and back breaks the flow of the game up. There are going to be players who enjoy that calm between each main assault’s storm, but I’ve always felt that the long break between action sequences dragged me out of “the zone”, which is problematic in a game where fast reactions are so important to survival.
The sound is probably best described as okay – it certainly isn’t one of David Whittaker’s more memorable tracks and too “jolly” for a shoot ’em up – and, although the graphics are reasonable throughout, some of the levels are a little sparse presumably to keep the character set use down to a minimum. But, despite having some flaws, Lazer Force is still a fun budget blaster; I got my money’s worth from the couple of quid handed over all those years ago and still enjoy playing it occasionally but, as old age sets in, that high difficulty seems far harsher now than it ever did to my teenage self.
Battle Eagle is finished and sent off a day before the ABBUC competition deadline! For those who haven’t read the previous posts, Battle Eagle is a vertically scrolling shoot ’em up that uses the Atari 8-bit’s 80×192 pixel sixteen shades of one hue graphics mode and hardware sprites which are horizontally expanded to make them fit in a bit more cleanly. Here’s a short video of the title page (with some of the music composed by Sascha “Der Luchs” Lubenow) and some of the first level:
Here are some “interesting” facts about Battle Eagle just because I’ve remembered how to do bullet points today:
- It has 50FPS smooth scrolling using a character-based screen mode.
- There are 60 screens of scrolling background constructed from 3,620 4×4 character tiles.
- Up to four independently controlled enemies, all generated with just two hardware sprites.
- There’s 106 frames of animation for the explosion, player ship and enemies in there.
At some point I’ll try to do another post mortem like the one written for Callisto last year but for the moment here are a couple of screenshots and the game itself will be released onto the Cosine website as soon as the nice ABBUC people give the okay.
A bit more work has been done to Battle Eagle so there are three level maps installed and pretty much populated now and a handful of enemy animations have also been added so here’s a picture of one in it’s natural environment:
The four enemies currently handled by the engine are managed on an object-by-object basis so each can be a different base colour and definition. At this point the idea is that there will be about six stages which alternate between two graphical styles and, hopefully, have a bespoke enemy definition as well as access to a general pool for things like the now grey space mines but the final numbers pretty much depend on available RAM.
Part of me wants to keep everything to a single 48K load because it wants to write for a stock, tape-based machine (which for the Atari 8-bit would be a 48K GTIA-equipped 800 since that’s what most 1980s budget games wanted) but there’s another area of my psyche insisting on unrolling loops for speed and the two really don’t get on and if the latter wins the three of us will be aiming for 64K. As it stands the entire project takes a smidgeon over 40K when executing but there’s a generous gap where the music will be going, some work spaces that can be moved or optimised and the sprite and tile data have some “dead air” at the end which will be clawed back soon.