Released in 1987 for the Amstrad CPC by budget publishers Mastertronic and written by Peter Wiseman, Killer Cobra is a horizontally scrolling shooter where the player takes control of the titular helicopter to blast their way through well-defended caverns in search of a priceless treasure and early retirement. Ah… the 1980s where video game stories were there to fill a bit of space on the cassette inlay and it really didn’t matter if you actually read them.
Killer Cobra is basically a loose clone of Konami’s coin-op Super Cobra from 1981, but played with the fast forward button permanently held down, so a background hazard can completely cross the screen in under a second. That doesn’t leave much in the way of reaction time so, to begin with at least, most players will have to work through the frustration of repeatedly slamming helicopters into walls as a result. But given some practise and most likely a little memorisation, it’s possible make some progress through the stages.
There aren’t any power-ups to worry about but the Cobra does have a fuel gauge which ticks down at an alarming rate that, for reasons lost in the mists of time or at least Konami’s design documents, can be topped up by bombing fuel dumps on the ground – labelled with the word “oil” in Killer Cobra – which are defended by ground-to-air defences, airborne nasties and other facilities which are worth blasting to smithereens for a few points as well.
The background graphics and sound are primitive especially considering the year of release – a pounding in-game tune really wouldn’t have gone amiss here – but the sprites are reasonable and the package as a whole still has a certain charm.. The perilously steep learning curve aside, it certainly gets the adrenalin going during play – this is one of those games where getting into “the zone” and flying by instict really works – and has that elusive “one more go” factor, although some players will need a bit of a lie down in a dark room with some soothing music after a couple of sorties.
The last couple of days have been all about getting everything packed and ready to go because I’m heading south to visit family and friends. Literally heading south right now because, for the first time since I started doing these journeys, there’s actuallly a working wifi service on the coach! So here I am composing a blog post whilst listening to ProTracker modules, sipping diet Coke and zooming down the M1 – I think we’re coming up on Leicester soon – how pretentious is that?!
Well okay, not particularly because it’s old hat for most people but the coaches on this run haven ‘t previously offered wifi and, although I know there’s a streaming service available so they must be reasonably confident of the bandwidth, I’m quite surprised at how quick the connection actually is. The down side is that its being filtered with OpenDNS/Cisco Umbrella and a few of my regular haunts like Atari Age aren’t available so those poor souls will have to survive without my “wit and wisdom” until later.
I had a quick stab at circumventing the filtering of course, but both Opera’s VPN and TeamViewer won’t connect and forcing the DNS to 18.104.22.168 failed as well; hardly surprising of course because I wouldn’t expect Cisco to miss any of those tricks, but still a pain considering I’m seeing “invalid” certificate errors from WordPress.com and YouTube amongst others. Anyway, I’ve managed to kill most of an hour and about half of the battery on my old Dell D630 with this ramble so I might as well kick it out… there’ll be at least one post this coming week but I’m not sure when and “normal” services will resume after that.
There hasn’t been much time for coding since the start of the new year, apart from spending a while prodding around a little at Vallation, mostly because another member of Cosine is considering a port and I’d forgotten how some of the level data was organised!
Previously I have pondered about coding something under the C64CD label as a practical demonstration of what processes are actually involved when writing a game; as already noted, my first thought is always “let’s do a scrolling shoot ’em up” but the idea of a tile-based version of Co-Axis didn’t really feel right so the project was pushed to the back burner until a recent Facebook post from Karolj Nadj about writing his first Run Length Encoding routine set me thinking; I’ve already got one of those, so could the scrolling background for a game be compressed that way rather than using tiles?
Run length encoding works by tokenising clusters of the same byte, so if there are twelve $64s in a row in the data they’re reduced down to three bytes which are a copy of the byte itself, a flag of some kind to say it’s going to be repeated and the number of times it should repeat; something like the gaps between landscape details on a scrolling background for example can be compressed quite a bit. With that in mind, out came my four year BlitzMax RLE compression code and the messy, self-modifying 6502-flavoured unpacker for a few tests and, after throwing some test data together and adding a couple of loops to convert the incoming map data to columns rather than rows, it seems to be reducing to around a third of its previous length which is sufficient for what I have in mind.
These early trials also found a bug within the RLE compressor code; because the length is a byte and can’t be higher than $FE there’s a sanity check in the code which stops the currently encoding run when it hits that value and forces a new one to start… all very sensible if I hadn’t forgotten to properly finish that first run in the data before moving on. Instead it only wrote the byte and a trigger for the run but no length value, meaning the 6502 end would pick up the next byte and use that instead, completely mangling the data in the process. This went undetected because the only practical use my RLE code had been put to previously was compressing streams of AY register changes for my prototype Apple II Mockingboard music driver where the data there changes too often for the bug to appear.