August’s game is a somewhat deceiving. On the surface, it is a simple direction shooter. Be careful, though, as those asteroids speed up. It may start out easy, but Asteroid £ Metor will frustrate you—as it did me. After you give the game the retro try, let’d dig deeper into it.
Making it playable.
The game, as designed, is more frustrating than the version I present here. My testing regimen wasn’t that great back then. In part, it was due to the long save and load times incurred by the ZX81. Cassette tapes are not the best way to save programs, even tiny ones.
Coming back to the frustrating part, the game had a major bug in it. To understand it, let’s review how the game worked. First, two asteroids are generated at random. Then, I use a loop to move them. To make the game speed up, I leverage another loop that acts as a delay. It is here that problems start.
I use that second loop for a few different thing, including input and collision detection. Once you fire, the program prints the bullet using this routine. This makes the game feel responsive, and you can even fire a different direction. This is especially helpful given you can do that before the asteroids have moved.
The problem arises when the game loop needs to move the asteroids. If the timing is right, the asteroid will jump past the bullet causing the collision routine to fail. It is fortuitous that there is an easy fix by checking if the bullet is past the asteroid. Although this fixed the biggest issue with the game, it is still frustrating.
Darn that input.
A defining part of Asteroid £ Metor is that it allows you to interrupt a bullet’s flight. Shoot the wrong direction, and all you need is to shoot again in the right one. The only problem is that the input routine doesn’t record the initial button. So, when I do call the subroutine, it is possible the bullet won’t shoot the direction you want.
The problem is the initial key press only kicks off the check. That subroutine then does three more checks of the
INKEY$ variable. If you aren’t pressing the 6, 7 or 8 keys at the time of the check, it will shoot to the left which corresponds to 5. The logic is fine in theory, but flawed.
You see, it each of those checks take time and, in that time, you may have stopped pressing a key. Timing, especially when the delay is very small, is key to shooting the asteroids. But, if you let off the key too early you’ll shoot left by accident. That can be frustrating when you that fast moving asteroid hit you from the right.
I decided not to fix this flaw as it is an inherent part of the original game. That isn’t to say it can’t or shouldn’t be. I can think of a few different ways to solve that problem, but I’d need to test to see if any severity impact the flow of the game. As is, you can work around the problem. Plus, the finickiness requires some skill to overcome, making the game more rewarding.
In fact, once you get into a groove, it isn’t too hard to rack up points. My best attempt, once I got my timing down, pushed my score to 2400. I’d love to see others do better, especially with a real ZX81.
Optimizations and other tweaks.
The code for Asteroid £ Metor is straight forward, but not well optimized. I actually moved one of the print routines out of the delay loop. It was a big improvement, but saving a few milliseconds is still worth it.
In the original code, for some reason I set the bullet variable twice. Once, to -1. Then, in the next line, I set it the direction you fire. I removed the first
LET statement. It doesn’t change the game any, so I decided it was worth removing.
Besides the issues above, there are some graphic oddities that could be better. For one, the asteroids all look the same. Since I use a string array to hold their images, it would have been easy to create different versions of them.
The other problem was the bullets. In certain occasions, they won’t erase the asteroids, instead leaving a ghost image. The other problem is the bullet itself doesn’t erase, causing them to float in space. Polishing this up would add to the game’s look, but I actually like the game as is. There’s a certain charm to it.
What’s with that name?
That name itself is, well, wrong. The ZX81 doesn’t have an ampersand so I used the pound sign instead. To be honest, Metor is bad spelling—a common theme for me. I thought about fixing it, but as I typed in the program I realized I don’t use it.
In the game, I only talk to the asteroids. Plus, shooting meteors is silly—its already in the atmosphere which is a bit late. So, in my lazy mind, I thought about creating a back story. And here it is:
You are the pilot of the space station Metor, a long range research station in the asteroid belt. A passing comet slammed into one of the larger, nearby asteroids, causing it to fragment and rain debris on your station. But not before a fragment from the comet hits your station and disabled the stabilization routines.
Rotating in space, you now have to contend with asteroids that seem to fly at you from every direction. As you attempt to survive, the asteroids continue their bombardment at ever increasing speeds. How long can you hold out?
Of course, to make this backstory work I’d need to actually have a goal for you to reach. In this version, you are doomed. A high score is all you can hope for. let’s hope that is enough to keep you busy until I release next month’s game.