Playing Starforce Fighter (C64)

Since it’s Star Wars day and I’m pretending that I need an excuse, here’s another shooty game… Starforce Fighter was released on the C64 in 1987 by budget stalwarts Mastertronic for the princely sum of two quid and I handed over my cash for a copy because I recognised the game from its screen shots (although we’ll come to how that happened later). The term “cheap and cheerful” springs to mind for this one and Mastertronic probably looked at it that way too since they didn’t bother commissioning new cover artwork, instead recycling the picture from a previous release called Space Scramble which came out for the VIC 20. Presumably they thought nobody would notice?

The instructions talk about Earth losing a galactic war and the player, as one of “the few”, being on the front line against an onslaught of drones, but basically it’s another horizontally scrolling shoot ’em up so there’s a joystick-controlled spaceship, chains of enemies to shoot and in this case the occasional power-up item which temporarily does things like disable enemy firing or beefs up the weapons. Each stage is large and topped off with an asteroid field – the guns are powered down at this point – and, once that’s safely traversed, a bonus stage with pods to gather for score plays out before the next level starts.

I remember spending quite a bit of time trying to wring my money’s worth out of this game back in the day despite some pretty bad issues; for a start it’s brutal and, despite being quite generous with the lives, will throw the player back to the beginning of the current, very long stage on death. This means that making any significant progress is frustratingly difficult and, whilst the early stages are set in open space, landscapes the player can collide with begin appearing as the game progresses to make things harder still. The cassette inlay claims that “the enemy ships generate shields by joining together” but, while this is an amusing attempt to paper over a programming issue in part caused by the C64’s hardware-based collisions, it means that many of the players shots will land but be ignored.

Usually I finish up by recommending a game like this with caveats, but in this case even my enthusiasm for the genre doesn’t quite stretch to that; yes I enjoyed going back to it – although rooting through half a dozen storage boxes this morning to find my original tape to check the instructions was probably just as entertaining – I wouldn’t consider it fair to inflict something this sadistic on unwary players. So whilst a few people might be able to drag some enjoyment or more likely nostalgia out of Starforce Fighter, I’m showcasing it more as a lesson in bad shoot ’em up design with a footnote about how important it is to get the bloody collision detection right!

As I mentioned earlier, I recognised this game from the screenshots because Mastertronic were the final publishers of Starforce Fighter but it was offered around to at least one other firm before that; I know this because, when one of the developers took the game along to a computer show in London and it was loaded on one of Audiogenic’s display machines for evaluation, I was stood nearby and snuck in to spend about five minutes playing it. Although Audiogenic didn’t take it, the coder Kevin Oxland also handled the C64 conversion of their bouncy BBC blaster Ransack, again with Wally Beben handling the sound.

4 thoughts on “Playing Starforce Fighter (C64)

  1. Great music by Wally Beben (although the SEUCK like effects grate frequently) and I quite like some of the ‘swooping’ paths traced by the enemies. It seems fairly solidly coded for a budget game of the time (no flicker or other oddities) but, other than that, not a lot to raise it above the million of other shooters around at the time.

  2. The inlay’s hyperbole reckoned that it was “destined to become the new classic shoot-em-up”… =-)

    I’ve used the hardware collisions a couple of times and always played it safe, so if my code wasn’t sure which sprites had been shot it just blew ’em all up ; that’s an equally cheap solution technically but a little fairer on the player.

  3. Well, regarding sprite collisions, I may have some questions soon regarding a little project I’m working on where 1 player sprite (sprite 0) needs to detect 1 collectible sprite (sprite 1), while the rest of the sprites ‘kill’ the player. I’m hoping that’s not going to cause much issue!

  4. The hardware collisions would struggle in the vast majority of situations, so the safest method is to go with software-based collisions; they’re far less accurate but, for most game programming purposes, that’s actually a positive! =-)

Leave a Reply

Your email address will not be published. Required fields are marked *