Playing Lazer Force (C64)

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.

How RG Rampage works

RG Rampage is a platform-based collect ’em up which was put together over a couple of weeks for issue 100 of Retro Gamer magazine, where it appeared as a type-in listing. And, at least according to the changelog kept in the game’s original source file, the final build was on the 11th of January 2012 which was a day over six years ago and that doesn’t make me feel old and decrepit in the slightest! So let’s take a look at what’s going on “under the hood” – a more human-readable version of the source code and some work files have been pushed up to GitHub – in order keep the game under 3.9K uncompressed.

Most of the savings come from the graphics which are optimised in a couple of ways to keep the overall size down; the character set is just cloned from the C64’s ROM whilst skipping the third byte of each character to make it look different, whilst the platform tiles – sixteen characters in total with one more for the titles scroller – are copied into that same 2K block of character RAM. Similarly, any object which can point in either direction like the player or some of the drones is actually stored just the once in the sprite data where it’s looking to the right, with the flipped version being generated on starting up.

Another place where things are reasonably compact is the level data; each platform uses five bytes for X and Y start position, character pair, colour and width and an entire screen only needs about a hundred bytes in total when adding the player start position, enemy patrol data – basically just another five bytes per nasty saying which object to use and giving two sets of X and Y positions to track back and forth between – and a stream of coordinates for the pick-up items. The level layouts were rather arduously worked out on printed sheets because getting a bespoke editor done would’ve taken too long.

I couldn’t include music because it would’ve added too much to the program’s length, so my (t)rusty “Roundasound” engine was dragged out of storage and given a bit of a dusting down; this is pretty much the same routine which was used for Quota by Chris Young and, with some modifications from Sean Connolly, in Flair Software’s Turn ‘N’ Burn so if anyone fancies a laugh they can have a prod through the source code for that. The routine is almost painfully primitive looking back and there’s a far better version now which is the base of my Atari 8-bit sound routine too, but it was compact and did the job.

The final “trick” was creating a BASIC listing for publication which, to keep the chance of errors sneaking in to a minimum, was handled by a truly hacky piece of BlitzMax code that yanked the assembled binary file in, generated a simple checksum by adding all the bytes together and then wrote out a text file containing the game as DATA statements and a small BASIC program with a FOR/NEXT loop which the code out to memory. That text file could then be tested by copy/pasting the contents into a freshly-loaded emulator and, when everything was deemed complete, sent off for publishing.

When Darran asked me to produce a type-in for issue 100 it seemed like a fun thing to try programming but I honestly didn’t expect anybody to actually type it in! There were a few brave souls who surprised me though and, judging by the feedback, they seemed to enjoy the experience of playing it as well. Going back to RG Rampage this afternoon for the first time in a couple of years to grab screenshots, I can’t help feeling with the advantage of hindsight that the balancing was a little off – almost certainly due to the dash for the finishing line – but it still feels fun to play.

Workprint – January 2018

I’ve missed my first Friday “deadline” for 2008 2018, that’s a cracking start to the year… having a cold is my excuse and I’m sticking to it, although that might just be the mucus!

The aftermath of the “festive season” means that I didn’t have much of note to write about at the moment anyway, I’m still hacking away in the background at the Hex Files remix when I can find time and have been mulling over a game for C64CD which will no doubt prove to be just another cheap excuse to write a scrolling shoot ’em up, but I’m tempted to throw some of the sillier ideas I’ve had for “features” into the mix for that one.

And before I forget, couple of folks have asked why Blok Copy or DYCP 2018 didn’t appear in last month’s workprint; that’s a simple one really, neither project had been decided upon when the post went live! I like to think of myself as spontaneous, although everyone else seems to feel it’s more “annoyingly erratic”.