Playing Matta Blatta (Atari 8-bit)

Published by Firebird’s Silverbird label for a couple of quid, Matta Blatta is a horizontally scrolling blaster for the Atari 8-bit from developer Shahid Ahmad who previously coded Chimera on a range of platforms. It was released in 1988, which was quite late in the day for the Atari’s market here in the UK so quite a few fans of the machine or indeed shoot ’em ups may not be aware of it; I missed out personally because most of the local shops had already stopped selling Atari 8-bit games by that point and the lack of new releases meant I’d already been enticed away by the C64, copious amounts of new releases and a larger library of software overall.

Matta Blatta is also a surprisingly simple game as well, each level is populated by just one type of enemy with a fixed movement pattern and the player merely has to survive through each onslaught to progress to the next, although actually making it through a wave is tricky though, since the speed of enemy movement doesn’t leave much in the way of reaction time. The collision detection is definitely on the side of the invading forces as well with little mercy being shown to the player’s craft when it gets too close to the enemies or their bullets, something that other games in the genre tend to be far more generous about.

That stinginess means Matta Blatta can often be irritatingly tough, but at the same time it’s not ridiculously difficult in the way that something like Firefleet is. There isn’t much variety to the gameplay – not necessarily a problem to my mind, but that can sometimes be off-putting for others – but, along with existing games already doing the same sort of thing better, Zeppelin’s Zybex came out the same year and offers far more meat on the bone for just a quid extra. Matta Blatta probably won’t be anybody’s first choice when thinking of something to destroy on the Atari 8-bit, but there is still some fun to be had from the frantic manoeuvring and wanton, sometimes desperate blasting it offers.

Hyperzap 2018 (C64)

Before I start with the history – this is about Hyperzap in its myriad forms rather than just the new 2018 edition just released under the C64CD banner because why not – a quick disclaimer is probably required, my memory is shocking at the best of times and my recollection of dates may well be off by a considerable amount; usually I rely on friends who have a far better recollection of events, but in this particular case there’s nobody I can really ask. This is… frustrating to say the least and means I’ll be a little vague about specific dates, but I’ve tried to at least nail things down to the correct year and will update things should the facts turn out to be different.

I’ve mentioned Hyperzap in the past when talking about Co-Axis, it was the first “complete” assembly language game I ever wrote and started at some point in late 1986; the actual development process took several months because I was literally learning about the C64 as I went, working out features I wanted and then trying to understand the documentation to implement them. The code was written with the venerable Zeus 64 Assembler, the sprites drawn with an editor I was given but can’t remember the name of – the player ship is just a tweak I did of a default sprite included with it but the enemy was drawn from scratch by my friend Simon Probert – and the titles page is a Yak Society demo that was “repurposed” because I had no idea at the time how to rip the music myself.

There was also a Hyperzap 2 which improved on the original a little – some bugs were sorted out, it had a custom character set and there were multicolour sprites this time with the enemies being my own interpretation of the “licker ships” from Jeff Minter’s Iridis Alpha – but, during a coding session at a friend’s house on his C128, the source code was lost when the 1571 disk drive ate it – that was completely my fault and, although a valuable lesson about backing up regularly should have been learnt that day, it sadly wasn’t and came back to bite me on the posterior when working on Co-Axis,

And then there was another incomplete but at least partially preserved attempt to resurrect the original design, done for the sheer hell of it in the early 1990s around the time coding for what would eventually become Warflame was started; it was called Hyperzap ’91 and was essentially a from scratch re-write of the original even down to the hardware-based collisions – Warflame in its original form uses the hardware registers as well – which also added simple Pirates In Hyperspace style movement patterns since that game, along with Kernal’s Chaos, Galax-I-Birds and a few others, was originally an inspiration for Hyperzap.

Fast forward over thirty years from the original to an annoyingly warm bank holiday weekend and yours truly was pondering the mysteries of the universe, the meaning of life and C64 hardware-based sprite collisions. We’ll just have a quick primer for anyone who hasn’t dealt with the collision registers in the past; sprite to sprite and sprite to background collisions are handled by a video register each which both use the bits in their byte to represent the eight sprites. Bits are are set when a collision occurs and, whilst that’s fine for background collisions bar a few caveats, it doesn’t tell the entire story for sprite to sprite impacts. For example, if the lower four bits of the register are set there’s no way to tell from that if there are two separate collisions (and which pair sprites are involved) or if all four are clustered together somewhere.

So what Hyperzap 2018 does is split things in two. It checks the sprite to sprite collisions to see if the player is in trouble and, because the bullet is a software sprite, background collisions can be used to check when nasties have been shot. False positives don’t occur with the starfield because one of the multicolours doesn’t actually trigger sprite to background collisions and the registers are cleared at the top of the frame and checked just before the status bar so that doesn’t accidentally “shoot” enemies either. Being a software sprite also means the bullet can be coloured independently to the hardware sprites and the spaceship uses a second sprite as an overlay so it doesn’t share dark grey with the enemies.

I’ve also added a simpler version of the enemy movement patterns from Pirates In Hyperspace where only the vertical speeds are changed and two enemies will update every five and a bit seconds. It is almost painfully simple stuff for sure, there aren’t many bells or whistles past having a titles page and there’s a fairly obvious fault in the game design which survives almost completely intact from the 1987 original but, considering the bulk of the code took around four hours, I’m quite pleased with the results and it was nice to finally use that Marc Francois tune in something too. The source code is available through good old Github for anyone wanting a prod around and a download is over at the CSDb.

Playing X-Dazedly-Ray (Mega Drive)

1990 was a superb year for Mega Drive owning shoot ’em up fans and is pretty much when I personally jumped aboard that particular bandwagon with an imported Japanese unit. Games like Sagaia, Thunderforce 3 and Whip Rush were released for example, all being highly playable and demonstrating just how good Sega’s hardware was for this genre whilst hinting at what was yet to come. Sadly, X-Dazedly-Ray from UNIPACC really doesn’t fall into that camp and, when thinking back, there was for the longest time a small part of me which wondered why I handed over £24.99 for it back in the day.

The first games in the Gradius and Darius series seem to have been an inspiration for XDR‘s developers both from a gameplay standpoint and the visuals – the shield is very Darius-like with the options being more similar to Gradius except they can soak up bullets – although it’s nowhere near the standard of either Konami or Taito’s game. It does suffer badly from “Gradius syndrome” as well so, while it takes the entire first level to get some decent firepower together from the icons left behind by blasting certain enemies, everything is lost on dying and recovering from that situation with the now painfully underpowered ship ranks somewhere between frustratingly difficult and simply impossible.

XDR isn’t exactly a popular game, there’s a scathing GameFAQs user review which pretty much rips it to shreds and I’ve previously seen it described it as one of the worst Mega Drive games ever released during forum discussions. That’s being rather harsh on something that is essentially just mediocre though, and it’s not even the worst shoot ’em up for the platform either with titles like Curse, Xenon 2: Megablast or Divine Sealing being more aesthetically distinctive but, to my mind at least, less enjoyable to play.

So it’s not a great game by any stretch of the imagination, but still offers some entertainment; if the cost of cartridge publishing hadn’t meant there couldn’t be a home computer style budget range for Mega Drive games that’s where X-Dazedly-Ray would have fit in perfectly, not quite keeping up with the full-pricers for spectacle but still reasonably solid. For those wanting to give it a blast, go into the start menu to enable auto firing – because trying to constantly hammer two buttons for the main guns and missiles at a decent rate is something of an ask – and perhaps dial the difficulty down to “easy” before starting.