Back in 1983, Star Wars imagery flooded my life. With the release of Return of the Jedi that year, it only fueled the inspiration of my young teenage self. So, it shouldn’t come as a surprise that I would create games with that look and feel. Star Fight, this month’s program, is one such game.
Slow and stress free.
As a game, things couldn’t get any simpler. The goal is to move the fighter—with a vague resemblance to a Tie Fighter—into the target. You have plenty of time to do so as the fighter starts on the far left of the screen. Once you have it in your sights, you must fire to destroy it and increment your score.
Should you miss, the game will present your score—which is generally low. There is a note in the game to try to get to 100, but I doubt you’ll bother. This is a slow, low stress game. But, I do recommend you die at least once. Doing so will treat you to one of my nicer game over animations.
Foundation for the future.
In many respects, Star Fight was a ground breaking game for me. I was pretty new to graphics, so this game offered an opportunity to try out a few techniques. Many of which I would use extensively in future games.
First off, the two objects are represented by many string variables. The advantage of doing that is two fold. One, it is easy to see what the objects represent. Take a look at lines 20–90 of the listing to see what I mean. The second is that the print routines on lines 170 and 180 are short.
Although it works as is, but I don’t recommend it. Using a variable is best when you are going to change the object later. I don’t in Star Fighter, so it would be more efficient, and faster, to print the objects.
There is also a bug in line 180 that I expect I overlooked due to the array. The bug causes a flicker in the target image. The bug is obvious once you look for it, but I decided to leave it. A reminder that nothing is perfect.
The rest of the game is straight forward. A loop to track the movement of the fighter. I capture what key is pressed, then act on that with a series of IF statements. Although simple, you’ll see that I used similar setups in many other games I wrote.
A fun ending.
A good part of the program is devoted to the end credits. The traditional “game over” was set up as a marquee sign. There is a string of lights that flash around it. I’d complete forgotten about it until I did some test runs. Plus, I was surprised by the effort I’d put into the ending, when the game itself could have used some more love.
That said, it is a nice touch. It is a brute force animation, with each movement a separate line of code. Yet, the effect works well and looks great. I did adjust a small loop used to delay the start of the next animation. Wanting to end the infinite loop as written, I replaced it with a key check. Once pressed, the game starts over.
Ideas and tweaks.
Looking over the code, it is obvious that I had planned more changes. For example, I found unused variables in the code that I suppose I meant for the target. The game, although foundational, is boring. Adding in other game elements would have been nice. Things like laser fire or a dodgy fighter would have improved playability.
So you could play it again, I did tweak the ending as noted earlier. I also added a title screen after load to take the guesswork out of how to play. To improve readability, I made a slight change to the score routine to move it down a bit on the screen. Nothing too major.
To be honest, I had to hold myself back from adding more to the program. In particular, I kept wanting to add in little animations of the star fighter. It is one of the better features of the game. Adding it to the start screen would have strengthened the games identity. Plus, it would have showcased the little fighter more. Alas, I resisted.
With a little more work on the core play mechanics, Star Fight would make a great little game. Instead, I moved on to other programs before finishing this one. But, its legacy lives on in those later games. And, I’m good with that.